“Google ile devam et”, “Apple ile giriş yap”, “Microsoft hesabınızla oturum açın.” İnternetin en sıradan düğmeleri arasında yer alan bu seçenekler, dijital kimliğimizi yönetme biçimimizi köklü şekilde değiştirdi. Peki kolaylaşan şey yalnızca giriş işlemi mi, yoksa üçüncü taraflara duyduğumuz güvenin kapsamı da sessizce genişliyor mu?
Bugün yeni bir uygulamaya kaydolmak için kullanıcı adı seçmek, parola üretmek ve doğrulama e-postası beklemek zorunda değiliz. Bir düğmeye tıklamak, bazen birkaç saniye içinde yeni bir hizmete erişmek için yeterli. Bu kolaylık gerçek bir fayda sağlıyor: Daha az parola ezberliyoruz, daha az parola tekrar kullanıyoruz ve hizmet sağlayıcılar kendi parola veritabanlarını yönetmek zorunda kalmıyor. Ancak kullanıcı açısından sürtünmesiz görünen bu işlem, arka planda bir kimlik sağlayıcısına, bir uygulamaya, çeşitli izinlere ve zaman zaman uzun ömürlü erişim ilişkilerine dayanıyor.
Buradaki temel sorun, tek tıkla girişin doğası gereği güvensiz olması değil; kimliğimizin, kullandığımız uygulamaların ve verdiğimiz erişim izinlerinin bütününü çoğu zaman göremememiz. Bireysel kullanıcı açısından bu bir gizlilik ve hesap kurtarma meselesi olabilir. Kurum açısından ise aynı durum, kimlik yönetişimi ve veri güvenliği sorununun merkezine yerleşebilir.
Proton’un “Google ile giriş yapmayın” uyarısı ne söylüyor?
Gizlilik odaklı hizmetleriyle tanınan Proton, Ekim 2026’da sosyal medyada yeniden dikkat çeken bir uyarı paylaştı: Google hesabının ele geçirilmesi, Google ile giriş yapılan hizmetlerin güvenliğini etkileyebilir; ayrıca tek bir sağlayıcı üzerinden çok sayıda hizmete erişmek, o sağlayıcının dijital faaliyetlerimiz hakkında daha fazla ilişki kurabilmesine imkân verebilir. Paylaşımda alternatif olarak gerçek e-posta adresimizi her hizmete vermek yerine benzersiz e-posta takma adresleri (alias) kullanmak öneriliyor.
Bu uyarıyı ciddiye almak gerekir, ancak kelimesi kelimesine “Google ile giriş yapılan bütün hesaplar otomatik olarak ele geçirilir” şeklinde okumak teknik açıdan doğru olmaz. Bir kimlik sağlayıcısındaki yetkisiz erişimin etkisi, saldırganın mevcut oturumlara erişip erişemediğine, uygulamaların federasyon tasarımına, yeniden kimlik doğrulama kurallarına, ek güvenlik kontrollerine ve verilen erişim izinlerine göre değişir. Benzer şekilde Google ile giriş yapılması, kullanıcının Google parolasının üçüncü taraf uygulamaya aktarıldığı anlamına gelmez. Google’ın kendi açıklamasına göre standart giriş akışında ad, e-posta adresi ve profil fotoğrafı paylaşılır; ek verilere erişim ayrıca izin gerektirebilir.
Proton’un dikkat çektiği daha geniş problem ise yerinde: Çok sayıda hesabı tek bir dijital kimliğe bağladığımızda, güvenlik ve erişilebilirlik açısından ortak bir bağımlılık oluştururuz. Aynı zamanda tek bir e-posta adresinin onlarca hizmette kullanılması, farklı veri kümelerinin eşleştirilmesini kolaylaştırabilir. Proton’un e-posta alias yaklaşımı da esas olarak bu ikinci soruna cevap vermeyi amaçlar.
SSO, OAuth ve OpenID Connect: Aynı şeyden mi söz ediyoruz?
Önce kavramları birbirinden ayırmak gerekiyor. SSO (Single Sign-On / Tek Oturum Açma), kullanıcının tek bir kimlik doğrulama süreciyle birden fazla uygulamaya erişebilmesini sağlayan genel yaklaşımdır. OAuth 2.0, bir uygulamanın başka bir sistemdeki kaynaklara belirli yetkilerle erişmesine yönelik bir yetkilendirme çerçevesidir. OpenID Connect (OIDC) ise OAuth 2.0 üzerine kurulmuş, kullanıcının kimliğinin doğrulanmasını ve kimlik bilgilerinin standart biçimde iletilmesini sağlayan protokoldür. Kurumsal dünyada SAML gibi başka federasyon protokolleri de kullanılır.
Örneğin bir haber uygulamasında “Google ile giriş” düğmesine bastığımızı düşünelim. Uygulama bizi Google’ın oturum açma ekranına yönlendirir; kimlik doğrulama işlemi Google tarafında gerçekleşir; ardından uygulama, protokolün izin verdiği kimlik bilgisini doğrulayarak kendi kullanıcı oturumunu oluşturur. Bu süreç doğru uygulanmışsa uygulamaya Google parolamızı vermeyiz. Dolayısıyla federasyonun, zayıf parolaların ve parola tekrarının oluşturduğu saldırı yüzeyini azaltma gibi gerçek bir avantajı vardır.
Ancak başka bir ekranda “Bu uygulama dosyalarınızı görüntülemek istiyor” veya “Takviminize erişim istiyor” ifadesiyle karşılaştığımızda konu artık yalnızca oturum açma değildir. Uygulamanın hangi kaynağa, hangi kapsamda ve ne kadar süreyle erişebileceği konuşulmaktadır. OpenID Foundation’ın açıklaması, kimlik doğrulama ile uygulama erişimi arasındaki teknik ayrımı anlamak için iyi bir başlangıç noktasıdır.
Tek tıkla girişin görünmeyen beş risk alanı
1. Merkezi kimlik hesabı kritik bir bağımlılığa dönüşür
Birincil Google, Apple veya Microsoft hesabımız artık yalnızca e-postalarımıza eriştiğimiz bir hesap olmayabilir. Aynı hesapla alışveriş sitelerine, eğitim platformlarına, dosya paylaşım araçlarına, bulut servislerine veya iş uygulamalarına giriyor olabiliriz. Böyle bir durumda kimlik sağlayıcısının hesabına erişim kaybı, yanlışlıkla hesap kilitlenmesi, hizmet kesintisi ya da hesap ele geçirilmesi birden fazla hizmeti etkileyebilir. Bu etki otomatik ve sınırsız değildir; her uygulamanın oturum ve kurtarma tasarımı farklıdır. Yine de bağımlılık gerçek bir mimari özelliktir.
Risk yönetimi açısından kritik soru şudur: Ana kimlik sağlayıcısına yarın erişemezsem hangi hizmetlerde oturum açamam, hangi hesaplarımda alternatif giriş veya kurtarma yöntemi bulunur? Bu sorunun cevabını bilmemek, çoğu zaman giriş yönteminin kendisinden daha büyük bir sorundur.
2. Giriş bilgisi ile veri erişim izni karıştırılır
Üçüncü taraf hizmetlerin tamamı aynı izinleri istemez. Bazı uygulamalar yalnızca temel profil bilgileriyle hesap oluştururken bazıları Gmail, Google Drive, Microsoft Graph, takvim veya kişi listesine erişim talep edebilir. Kullanıcı izin ekranını hızla onayladığında uygulamanın yalnızca kimliğini doğruladığını sanabilir. Oysa arka planda erişim belirteçleri ve gerektiğinde yenileme mekanizmaları üzerinden farklı veri akışları kurulabilir.
Bir uygulamaya giriş yapılabilmesi için istenen izin ile uygulamanın temel işlevinin gerektirdiği izin aynı şey değildir. Örneğin basit bir toplantı notu aracının bütün posta kutusuna yazma erişimi istemesi sorgulanmalıdır. Onaylanan kapsamı bilmeden verilen izin, kurumsal veri güvenliğinde de bireysel gizlilikte de ciddi bir kör nokta oluşturur.
3. Dijital faaliyetlerin ilişkilendirilmesi kolaylaşabilir
Tek bir e-posta adresini farklı platformlarda tekrar tekrar kullanmak, bu adresin birden fazla veri setinde ortak tanımlayıcı olarak görünmesine neden olur. Bu durum yalnızca kimlik sağlayıcısıyla ilgili değildir: Üçüncü taraf uygulamalar, veri aracılık ekosistemi veya bir güvenlik ihlali sonrasında sızan veri kümeleri de aynı adres üzerinden eşleştirilebilir. Paylaşılan adresin görünürlüğü, uygulamaların gizlilik politikaları, çerezler ve diğer takip yöntemleri değerlendirmeyi etkiler.
Buna karşılık “Google ile giriş yaptığınız her uygulamanın içindeki bütün etkinlikler Google’a aktarılır” demek doğru bir genelleme değildir. Kimlik sağlayıcısının gördüğü oturum açma işlemi ile üçüncü taraf uygulamanın kendi içinde işlediği veriler birbirinden ayrılmalıdır. Gizlilik değerlendirmesi varsayımlara değil, açıklanan veri akışlarına ve izinlere dayanmalıdır.
4. Hesap kurtarma ve sağlayıcı değiştirme zorlaşır
Yıllardır aynı kimlik sağlayıcısıyla giriş yapılan onlarca uygulamayı başka bir hesaba taşımak çoğu zaman tek tıklık bir işlem değildir. Bazı uygulamalar ikinci bir giriş yöntemi eklemeye izin verirken bazıları hesap birleştirmeyi desteklemez. Kimlik sağlayıcısındaki e-posta adresinin değiştirilmesi veya hesabın kapanması, üçüncü taraf üyeliklerin geri alınmasını zorlaştırabilir. Bu nedenle kritik hizmetlerde kurtarma kodlarını saklamak, alternatif girişleri önceden tanımlamak ve giriş yöntemlerini periyodik olarak test etmek gerekir.
5. “Bir kez izin ver” kalıcı bir güven ilişkisine dönüşebilir
Bir uygulamayı bir ay kullanıp sonra kaldırmak, o uygulamaya verilmiş bütün erişim izinlerinin mutlaka sona erdiği anlamına gelmez. Mobil uygulamayı silmek, uygulamadaki oturumu kapatmak ve kimlik sağlayıcısında verilmiş erişim iznini geri almak farklı işlemlerdir. Erişim belirteçlerinin ve uygulama tarafındaki verilerin akıbeti de servislerin tasarımına bağlıdır. Bu nedenle denetimin konusu yalnızca hâlen kullanılan uygulamalar değil, geçmişte yetki verilmiş bağlantılar olmalıdır.
Gerçek e-posta adresinizi her yerde kullanmak zorunda mısınız?
Proton’un önerisindeki en uygulanabilir noktalardan biri e-posta alias kullanımıdır. Alias, gerçek posta kutusuna iletilen veya aynı hesap üzerinden yönetilen farklı bir e-posta adresidir. Bir alışveriş sitesine ayrı, bir forum üyeliğine ayrı, bir bültene ayrı adres verebilirsiniz. Böylece bu adreslerden biri spam kaynağı hâline geldiğinde kapatılması veya değiştirilmesi kolaylaşır; hangi hizmet üzerinden adresinizin yayılmış olabileceğine ilişkin ipucu elde edersiniz.
Burada teknik bir ayrım önemlidir. [email protected] gibi “artı adresleme” yöntemleri e-postaları sınıflandırmak için kullanışlıdır; fakat gerçek adresi etkin biçimde gizlemez. Çünkü temel adres kolayca tahmin edilebilir. Buna karşılık rastgele oluşturulmuş, bağımsız görünen yönlendirme alias’ları ana adresin doğrudan paylaşılmasını sınırlandırır. Proton’un alias açıklaması da bu farkı vurgular.
Bu yöntemin sınırları da vardır. Alias sağlayıcısı, yönlendirme yapabilmek için asıl posta kutusuyla bir ilişki tutar. Bir alias’ın kapatılması, o adresle kayıtlı hesaba ulaşmayı veya parola sıfırlama mesajı almayı engelleyebilir. Üstelik uygulama telefon numarası, ödeme bilgisi, cihaz bilgisi ya da başka tanımlayıcılar topluyorsa tek başına alias anonimlik sağlamaz. Bu yüzden alias yönetimi, kalıcı erişim gerektiren hesaplarda planlı yapılmalıdır.
Alternatifler arasında Proton Pass, SimpleLogin ve Apple’ın Hide My Email yaklaşımı bulunur. Araç seçerken yalnızca kaç alias oluşturulabildiğine değil; özel alan adı desteğine, veri işleme yaklaşımına, hesap kurtarma yöntemlerine, dışa aktarılabilirliğe ve servis kapanırsa izlenecek plana da bakılmalıdır.
Bireysel kullanıcılar için uygulanabilir güvenlik yaklaşımı
Tek bir sihirli ayar bütün riskleri çözmez. Daha makul yaklaşım; kimlik doğrulama, hesap ayrıştırma, izin denetimi ve kurtarma hazırlığını bir arada yönetmektir. Aşağıdaki adımlar, teknik uzmanlık gerektirmeden önemli ölçüde kontrol sağlayabilir.
- Bağlı uygulamaları envantere alın. Google hesabınızda Üçüncü taraf bağlantıları sayfasını açın. Microsoft ve Apple hesaplarınız için de hesap güvenliği ve bağlı uygulama ayarlarını gözden geçirin. Tanımadığınız uygulamaları ayrı değerlendirin.
- Giriş bağlantısıyla veri erişimini ayırın. Yalnızca oturum açmak için kullanılan bağlantılarla dosya, posta veya takvim erişimi verilen bağlantıları farklı öncelikte inceleyin. Kullanılmayan ve gereksiz izinleri iptal edin.
- Ana kimlik hesabını güçlü koruyun. Mümkünse FIDO2 tabanlı passkey veya fiziksel güvenlik anahtarı kullanın. Desteklenmediğinde güçlü MFA yöntemlerinden yararlanın. SMS tabanlı doğrulamayı daha güçlü seçeneklerin otomatik eşdeğeri saymayın.
- Parola yöneticisi ve benzersiz parolalar kullanın. SSO sunmayan hesaplarınız için uzun, rastgele ve her servise özgü parola oluşturun. Parola tekrarından kaçınmak, sadece kimlik sağlayıcısını korumaktan daha kapsamlı bir savunma sağlar.
- Düşük önemdeki kayıtlarda alias kullanın. Bültenler, forumlar ve alışveriş hesapları için ayrı alias tanımlamak faydalı olabilir. Bankacılık ve kamu hizmetleri gibi kritik hesaplarda ise hizmetin kimlik doğrulama ve hesap kurtarma koşullarını dikkate alın.
- Hesap kurtarmayı test edin. Kurtarma adresinizi, ikinci cihazınızı, güvenlik anahtarınızı ve yedek kodlarınızı kontrol edin. Tek bir telefona, tek bir posta kutusuna veya tek bir kimlik sağlayıcısına bağımlı kalmamaya çalışın.
- İzni kaldırmanın sınırını bilin. Kimlik sağlayıcısındaki erişimi iptal etmek, üçüncü taraf hizmetin daha önce elde etmiş olduğu verileri otomatik olarak silmeyebilir. Gerektiğinde uygulamanın kendi ayarlarından hesap ve veri silme taleplerini ayrıca yönetin.
Bu listenin neden önemli olduğunu anlamak için NIST’in SP 800-63-4 Dijital Kimlik Rehberi iyi bir çerçeve sunar. Rehber, kimlik doğrulama yöntemlerini, federasyon güvenliğini ve oltalama saldırılarına dirençli mekanizmaları ayrı katmanlarda ele alır. Özellikle passkey ve güvenlik anahtarı tercihleri, saldırganın sahte bir giriş ekranıyla kimlik bilgisi toplamasını zorlaştırdığı için değerlidir.
Kurumsal açıdan mesele neden daha karmaşık?
Ev kullanıcısı açısından çok sayıda hizmetin tek kimliğe bağlanması tartışmalı olabilirken, kurumlarda merkezi SSO genellikle arzu edilen bir güvenlik mimarisidir. Bunun temel nedeni, kurumsal kimlikleri merkezi olarak koruyabilmek, ayrılan personelin erişimini kesebilmek, MFA ve koşullu erişim ilkelerini uygulayabilmek ve erişim olaylarını kaydedebilmektir. Merkezi yönetim olmadan farklı SaaS uygulamalarına dağılan bağımsız hesapların güvenliğini izlemek çok daha zorlaşabilir.
Dolayısıyla kurumsal öneri “Google veya Microsoft ile giriş yapmayın” olamaz. Doğru öneri, onaylı kurumsal uygulamalarda yönetilen federasyonu kullanmak; onaysız hizmetlere kontrolsüz kimlik ve veri yetkisi verilmesini önlemektir. Kurumsal Google Workspace veya Microsoft Entra ID hesabıyla giriş yapılabilmesi, ilgili uygulamanın kurum tarafından güvenlik değerlendirmesinden geçirildiği anlamına gelmez.
Özellikle Microsoft Entra ID ortamlarında kullanıcıların uygulamalara erişim izni vermesi (user consent) ile yöneticinin kurum adına izin vermesi (admin consent) farklı etkilere sahiptir. İzinlerin kapsamı, uygulamanın yayıncısı ve erişebildiği kaynaklar önemlidir. Microsoft’un kullanıcı izin politikası ve uygulama izinlerinin gözden geçirilmesi belgeleri bu yönetim alanını somutlaştırır.
Shadow IT’den Shadow AI’a: Tek tıkla giriş yeni bir kapı açıyor
Bir çalışan, onaylı kurumsal hesabını kullanarak yapay zekâ destekli bir toplantı botuna, kod asistanına veya içerik üretim aracına giriş yapabilir. İlk bakışta bu yalnızca yeni bir SaaS üyeliğidir. Fakat araç takvimi okumaya, toplantıları kaydetmeye, e-posta içeriğine erişmeye ya da dosyaları analiz etmeye başladığında kurumsal veri akışı değişir. Bir AI agent’a işlem yapma yetkisi verildiğinde konu artık yalnızca hangi verinin görüldüğü değil, kurum adına hangi eylemlerin gerçekleştirilebildiğidir.
Bu ilişkiyi daha önce yayımladığım “Shadow IT’den Shadow AI’a: Kurumların Yeni Kontrol Problemi” yazısında daha geniş bir çerçevede ele almıştım. Burada aynı problemin kimlik tarafını görüyoruz: Çalışanın tanıdığı kurumsal giriş ekranı, üçüncü taraf hizmetin güvenilir olduğu izlenimini verebilir. Oysa kimlik doğrulama sağlayıcısının güvenilirliği ile giriş yapılan uygulamanın ve talep ettiği izinlerin güvenilirliği farklı değerlendirmelerdir.
Bir başka deyişle, bir hizmete kurumsal hesapla sorunsuz giriş yapılması o hizmetin kurum tarafından onaylandığına dair kanıt değildir. Kurumsal güvenlik ekibi bu ayrımı kullanıcılara açıkça anlatmalı ve çalışanların gerçekten ihtiyaç duydukları araçlar için hızlı, güvenilir bir onay yolu oluşturmalıdır. Yalnızca yasaklara dayanan yaklaşım, kontrolsüz kullanımın kişisel hesaplara kaymasına yol açabilir.
Kurumlar hangi teknik ve yönetsel kontrolleri uygulamalı?
Kurumsal yapıların ilk ihtiyacı görünürlüktür. Hangi çalışan hangi üçüncü taraf uygulamaya hangi kurumsal kimlikle erişiyor? Uygulamaya hangi OAuth kapsamları verilmiş? Yönetici onayı mevcut mu? Kullanıcı ayrıldığında yetki nasıl sona eriyor? Bu soruların cevaplarını üreten envanter, güvenlik politikasının başlangıç noktası olmalıdır.
Birinci kontrol, uygulama keşfi ve sınıflandırmadır. Kurumun onaylı SaaS envanteri ile kimlik sağlayıcısında görünen üçüncü taraf uygulamaların karşılaştırılması gerekir. Yüksek riskli izinler, bilinmeyen yayıncılar, kullanılmayan bağlantılar ve aşırı yetkilendirilmiş uygulamalar öncelikli incelenmelidir. Sadece alan adı veya web trafiği listesi üzerinden çalışmak yeterli değildir; OAuth izinleri ve uygulama kimlikleri ayrıca ele alınmalıdır.
İkinci kontrol, kullanıcı onayı politikasıdır. Kurumsal veriye erişen uygulamalarda hangi izinlerin kullanıcı tarafından verilebileceği, hangilerinin yönetici incelemesi gerektireceği belirlenmelidir. Bu karar servis sağlayıcısının varsayılan ayarlarına bırakılmamalıdır. Gerektiğinde güvenilir yayıncı ve düşük riskli izinler için kontrollü self-servis akış sağlanabilir. İş ihtiyacını tamamen kilitlemeyen, fakat hassas yetkileri değerlendirmeden geçiren bir politika daha sürdürülebilirdir.
Üçüncü kontrol, güçlü kimlik doğrulama ve koşullu erişimdir. Kimlik avına dirençli yöntemler, riskli oturumların ek doğrulamaya yönlendirilmesi, yönetilen cihaz şartları, oturum sınırlandırmaları ve ayrıcalıklı kullanıcılar için daha sıkı kurallar, merkezi SSO mimarisinin önemli parçalarıdır. Ancak bunlar üçüncü taraf uygulamaya verilen gereğinden geniş veri erişimini tek başına düzeltmez.
Dördüncü kontrol, erişim yaşam döngüsüdür. Yeni başlayan, görev değiştiren veya işten ayrılan çalışanın uygulama yetkileri kimlik yaşam döngüsüyle ilişkili yönetilmelidir. Mümkün olan uygulamalarda SCIM gibi otomatik kullanıcı sağlama ve sonlandırma mekanizmalarından yararlanılabilir. İşten ayrılan çalışanın merkezi oturumu kapatılsa da uygulamaya özgü hesaplar, servis kimlikleri ve erişim belirteçleri ayrıca doğrulanmalıdır.
Beşinci kontrol, sürekli izleme ve olay müdahalesidir. Yeni uygulama onayı, olağan dışı izin kapsamları, riskli oturum açma olayları, yönetici rızası değişiklikleri ve şüpheli uygulama davranışları izlenmelidir. Log kayıtları ve alarm senaryoları SIEM/SOC süreçlerine uygun biçimde aktarılabilir. Burada amaç kullanıcıların bütün faaliyetlerini gereksiz yere gözetlemek değil, tanımlı riskler için ölçülü ve hukuka uygun kontroller oluşturmaktır.
Altıncı kontrol, veri koruma ve tedarikçi değerlendirmesidir. SSO ile bağlanan her uygulamanın veri işleme şartları, saklama süreleri, alt işleyenleri, uluslararası aktarım koşulları, silme yöntemi ve olay bildirimi süreçleri değerlendirilmelidir. Türkiye’de kişisel veriler söz konusu olduğunda KVKK yükümlülükleri ve ilgili sektörel düzenlemeler de kararın parçasıdır. Kimlik güvenliği politikası ile veri koruma politikasının ayrı dünyalarda çalışması yeterli değildir.
SSO, alias, passkey ve parola yöneticisi: Hangisi hangi problemi çözer?
Bu yöntemler birbirinin doğrudan alternatifi değildir. Farklı tehditleri azaltan ve birlikte kullanılabilen araçlardır. Bu yüzden “Google ile giriş mi, yoksa alias mı?” sorusunun tek bir cevabı yoktur. Daha yararlı yaklaşım, hangi güvenlik ihtiyacının öncelikli olduğunu belirlemektir.
| Yöntem | Başlıca fayda | Tek başına çözmediği risk |
|---|---|---|
| SSO / Federasyon | Parola çoğalmasını azaltır, merkezi yönetimi mümkün kılar. | Kimlik sağlayıcısına bağımlılığı veya aşırı uygulama izinlerini ortadan kaldırmaz. |
| Benzersiz e-posta alias’ı | Gerçek kayıt adresinin paylaşımını ve hesaplar arası basit eşleştirmeyi sınırlar. | SSO bağımlılığını, izlemeyi veya kimlik avını tek başına engellemez. |
| Parola yöneticisi | Her hizmet için güçlü, benzersiz parola kullanımını kolaylaştırır. | Parolasız federasyon veya uygulama izinleri için yönetişim sağlamaz. |
| Passkey / FIDO2 | Kimlik avına dirençli kimlik doğrulama sağlar. | Üçüncü taraf hizmetin veri işleme davranışını kontrol etmez. |
| Kurumsal IAM / IGA | Kimlik, roller, erişim onayı ve yaşam döngüsünü yönetir. | Hatalı izin politikası ve denetlenmeyen SaaS kullanımını otomatik olarak ortadan kaldırmaz. |
Örneğin bireysel kullanıcı, az kullandığı bir forum için rastgele alias ve parola yöneticisini bir arada tercih edebilir. Uzun yıllardır kullandığı güvenilir bir hizmette, iyi korunan bir kimlik sağlayıcısıyla SSO daha uygun olabilir. Kurumsal kullanıcı ise onaylı uygulamalarda merkezi SSO kullanırken üçüncü taraf OAuth izinlerini ayrıca kısıtlamalıdır. Tercih bir marka sadakati değil, tehdit modeli ve kullanım bağlamı meselesidir.
Google hesabınıza bağlı uygulamaları beş dakikada gözden geçirin
Yazıyı yalnızca kavramsal bir tartışma olarak bırakmamak için hemen uygulanabilecek kısa bir denetimle tamamlayalım. Google hesabınızda myaccount.google.com/connections adresini açın. Hesabınıza bağlı üçüncü taraf uygulamaları inceleyin; “Google ile oturum aç” bağlantıları ile hesabınızdaki verilere erişimi bulunan uygulamaları mümkünse ayrı ayrı değerlendirin. Artık kullanmadığınız bir uygulamayı seçerek bağlantı ve yetki kaldırma seçeneklerini kontrol edin.
Bir bağlantıyı kaldırmadan önce o hizmete tekrar nasıl giriş yapacağınızı doğrulayın. Özellikle önemli dosyalarınız, ücretli abonelikleriniz veya tek giriş seçeneği SSO olan üyelikleriniz varsa, bağlantıyı koparmak erişim sorunu doğurabilir. Google’ın üçüncü taraf bağlantıları yönetimi açıklaması güncel seçenekleri takip etmek için kullanılabilir. İşlemleri tamamladıktan sonra ana hesapta passkey/MFA ayarlarını, kurtarma yöntemlerini ve kayıtlı cihazları da gözden geçirin.
Microsoft hesabı veya kurumsal Entra ID kullanan kişiler için benzer inceleme, hesap türüne göre değişen uygulama izinleri ve kuruluş ayarları üzerinden yapılır. Kurum tarafından yönetilen hesaplarda bazı bağlantıları kullanıcı tek başına kaldıramayabilir. Böyle durumlarda güvenlik veya BT ekibiyle birlikte ilerlemek gerekir. Buradaki amaç rastgele bütün bağlantıları silmek değil; hangi güven ilişkisinin neden var olduğunu anlayıp gereksiz olanları azaltmaktır.
Sonuç: Kolaylıktan vazgeçmek değil, kontrolü geri kazanmak
Proton’un sert uyarısı, dijital kimlik güvenliğinde kolayca gözden kaçan bir soruyu yeniden gündeme getiriyor: Başka bir hizmete giriş yapmak için her seferinde aynı kimliğe güvendiğimizde, bunun uzun vadeli güvenlik ve gizlilik sonuçlarını gerçekten biliyor muyuz? Bu soruyu sormak değerli. Ancak bundan bütün SSO yöntemlerinin terk edilmesi gerektiği sonucu çıkmıyor. Doğru yapılandırılmış federasyon, hem bireylerin hem kurumların güvenliğine önemli katkı sağlayabilir.
Bireysel düzeyde yapılması gereken, ana kimlik hesaplarını güçlü biçimde korumak; bağlı uygulamaları düzenli gözden geçirmek; e-posta adresini gereksiz yere yaymamak; uygun yerlerde alias kullanmak ve hesap kurtarma seçeneklerini önceden hazırlamaktır. Kurumsal düzeyde ise yönetilen SSO, minimum yetki, uygulama envanteri, izin politikaları, koşullu erişim, sürekli denetim ve veri yönetişimi birlikte ele alınmalıdır. Özellikle Shadow AI ve agent tabanlı araçların yaygınlaştığı dönemde OAuth izni yalnızca bir giriş kolaylığı değil, potansiyel bir veri ve işlem yetkisidir.
Asıl soru “Google ile giriş yapmak güvenli mi?” değil; “Hangi uygulamaya, hangi kimlikle, hangi bilgileri ve hangi yetkileri verdiğimi biliyor muyum?” olmalı.
Tek tıkla girişin yerini bütünüyle daha zahmetli yöntemlerle değiştirmek zorunda değiliz. Fakat bir tıklamanın neye onay verdiğimizi anlamak için yeterli süre olmadığını kabul etmeliyiz. Güvenli dijital kimlik yönetimi, giriş ekranında değil; verilen izinlerin anlaşılması, izlenmesi ve gerektiğinde geri alınmasıyla başlar.
Şunlara bakmak isteyebilirsiniz;
- Proton – Hide-my-email aliases ve gizlilik.
- Proton – E-posta alias türleri ve sınırlılıkları.
- Google – Sign in with Google ile paylaşılan bilgiler.
- Google – Üçüncü taraf uygulama bağlantılarının yönetimi.
- OpenID Foundation – OpenID Connect nasıl çalışır?
- NIST SP 800-63-4 – Digital Identity Guidelines.
- Microsoft Learn – Uygulamalar için kullanıcı onayı ilkeleri.
- Microsoft Learn – Kurumsal uygulama izinlerinin denetlenmesi.
- Yunus Emre Uğur – Shadow IT’den Shadow AI’a: Kurumların Yeni Kontrol Problemi.