Vazgeçmek mümkünken parolayı neden koruyalım?

Normal kabul etmeye alıştığımız sorun

Hemen hemen her web uygulamasının bir yönetim paneli vardır. Yönetim panelinin de genellikle bir giriş adresi, kimlik doğrulama formu, kullanıcı adı ve parolası bulunur.

Bu yapıya o kadar alıştık ki her şeyin gerçekten böyle çalışmasının şart olup olmadığını neredeyse hiç sorgulamıyoruz.

Tek bir siteniz olduğunda bu sorun önemli görünmez. Güçlü bir parola oluşturur, iki faktörlü kimlik doğrulamayı etkinleştirir, giriş denemelerini sınırlandırır ve işinize devam edersiniz.

Peki proje sayısı on, yirmi ya da otuz olduğunda ne olur?

Benim durumumda, otuzdan fazla bağımsız yazılım projesini bir araya getiren DigiMeld ekosisteminden söz ediyoruz. Her projenin kendine özgü bir mimarisi, sunucu mantığı ve yönetim arayüzü var.

Dolayısıyla her biri için bir yönetici erişimi mekanizması gerekiyor.

Uzun süre oldukça alışıldık bir yöntem kullandım: ayrı yönetici hesap bilgileri, güçlü parolalar ve bunları tarayıcıya kaydetmek.

İşe yarıyordu.

Ama bir noktada şunu düşünmeye başladım: Neden bu kadar çok yönetici parolasını saklamak zorundayım? Neden yalnızca sunucuları değil, onlara erişmemi sağlayan araçları da korumam gerekiyor?

Peki bu zorunluluktan vazgeçmek mümkün değil mi?

Sonunda, çözümümün temelini oluşturacak şu düşünceye ulaştım:

Belki de sürekli açık olan bir girişi değil, geçici olarak erişim elde etme hakkını korumak gerekir.

Ya alışılmış giriş sayfası hiç olmasaydı?

Projelerimde geleneksel yönetici kimlik doğrulama modelinden vazgeçmeye karar verdim.

Yalnızca giriş formunu gizlemekten değil.

Adresi değiştirmekten değil.

Parolayı daha karmaşık bir parolayla değiştirmekten de değil.

Sürekli var olan parola tabanlı bir girişe duyulan ihtiyacı tamamen ortadan kaldırmaktan söz ediyorum.

Elbette yönetim arayüzleri ortadan kalkmadı. Uygulamaları yönetmek için hâlâ gerekli.

Değişen şey, bu arayüzlere erişim elde etme yöntemi oldu.

Artık bağlı projelerin yönetim panellerine girmek için kayıtlı bir kullanıcı adı ve parola girmek gerekmiyor.

Bunun yerine kendi kimlik ve erişim yönetimi sistemim MeldID'yi kullanıyorum.

Temel fikir oldukça basit: Yönetici erişimi yalnızca gerçekten gerektiğinde, belirli bir kullanıcıya ve belirli bir projeye verilir.

Üstelik bir hesabın bulunması, yönetim panelini açma hakkına sahip olunduğu anlamına gelmez.

Bu hakkın ayrıca verilmesi gerekir.

Bir dakika önce var olmayan erişim

Bu, konseptin belki de en ilginç kısmı.

Geleneksel modelde yöneticinin elinde sürekli giriş araçları bulunur. Bu araçlar geçerliliğini koruduğu sürece bugün, yarın ya da bir ay sonra kullanılabilir.

Bu ilkeyi değiştirmeye karar verdim.

Sürekli geçerli yönetici hesap bilgileri yerine, girişi başlatmaya yarayan geçici bir imkân kullanılıyor.

Bu imkân, güvenilir bir mobil cihaz üzerinden talep üzerine oluşturulur; kriptografik olarak güçlü, rastgele bir bileşene ve sınırlı bir geçerlilik süresine sahiptir.

Ancak bu geçici bağlantıya sahip olmak bile tek başına erişim elde edildiği anlamına gelmez.

Bu, temel bir nokta.

Diyelim ki birisi bağlantıyı bir şekilde ele geçirdi. Yalnızca adresin gizliliğine dayanan sıradan bir sistemde böyle bir sızıntı ciddi bir soruna yol açabilirdi.

Benim modelimde bağlantı yalnızca doğrulama sürecini başlatmaya yarar.

Devam edebilmek için MeldID yüklü, güvenilir bir mobil cihaz üzerinden ayrıca izin verilmesi gerekir.

Gerekli onay olmadan yönetici oturumu oluşturulmaz.

Bu nedenle geçici bağlantıyı parolanın yerine geçen bir unsur olarak değil, erişim sağlama sürecinin bileşenlerinden biri olarak görüyorum.

Nereye başvuracağını bilmekle giriş yapma hakkına sahip olmak tamamen farklı şeylerdir.

Telefon erişim yönetimi aracına dönüşüyor

Bu modelde mobil cihaz, sıradan bir tek kullanımlık kod üreticisinden çok daha önemli bir rol oynuyor.

Yönetici erişimiyle ilgili işlemleri onaylamak için kullanılıyor.

Yönetim panelini açmak istediğimde sistem, MeldID üzerinden onay istiyor.

İlgili isteği güvenilir cihazımda görüyor ve işlemi onaylıyorum.

Sistem ancak doğrulama başarıyla tamamlandıktan sonra giriş sürecine devam edilmesine izin veriyor.

Onay, telefonun kilidinin açılmış olmasına değil, belirli bir işleme bağlı.

Mobil biyometri kullanıcıyı cihaz üzerinde doğrularken sunucu tarafı da kayıtlı cihazdan gelen kriptografik onayı doğruluyor.

Bu yaklaşım, yalnızca bir parolaya ya da kullanıcının girişi onayladığını iddia eden bir mesaja güvenmek zorunda kalmamayı sağlıyor.

Bir başka avantaj da güvenilir cihazların yönetilebilmesi.

Bir cihazın artık erişim onaylamak için kullanılmaması gerekiyorsa güvenilir durumu iptal edilebilir.

Bundan sonra ilgili işlemler için geçerli bir kimlik doğrulama aracı olmaktan çıkar.

Tek bir sistem, birbirinden bağımsız birçok proje

Bu mekanizmayı geliştirmeye başladığımda temel hedeflerimden biri, her projenin bağımsızlığını korumaktı.

Tüm yönetim panellerini devasa tek bir uygulamada birleştirmek istemiyordum.

Her DigiMeld hizmeti kendi mantığını, ayarlarını, kullanıcılarını ve verilerini yönetmeye devam etmeliydi.

Bu yüzden iki işi birbirinden ayırdım.

MeldID, kimlik doğrulama ve yönetici erişim izni verme işlerinden sorumlu.

Projenin kendisi ise kendi yönetim işlevlerinden ve geçerli yetkilerin doğrulanmasından sorumlu.

Böylece uygulamaları merkezîleştirmeden, erişimi merkezî olarak yönetebilen bir model ortaya çıktı.

Ayrıca erişim hakları ayrı ayrı veriliyor.

Bir projenin yöneticisi, MeldID hesabı olduğu için diğer projelere otomatik olarak erişim kazanmaz.

Her yönetim alanı için erişim izni olan kullanıcı grubu ayrı ayrı belirlenebilir.

Bu sırada sıradan kullanıcıların hakları ile yönetici yetkileri birbirinden bağımsız kalır.

Onlarca hizmetten oluşan bir ekosistem için bu yaklaşım özellikle kullanışlı oldu.

Geçici erişimi neden sürekli erişime tercih ediyorum?

Sisteme bilinçli olarak eklediğim bir ilke daha var.

Yönetici erişimi sonsuza kadar sürmemeli.

İzin sınırlı bir süre geçerli olur ve kullanıcının tarayıcıda çalışmaya devam edip etmemesinden bağımsız olarak sona erer.

Süre dolduktan sonra çalışmaya devam etmek için yeni bir onay süreci gerekir.

Böylece bir kez yapılan kimlik doğrulamanın sürekli geçerli bir hakka dönüşmesi önlenir.

Ancak süreyi sınırlamak tek başına yeterli değil.

Verilmiş erişimi süresi dolmadan sonlandırabilmek de önemli.

Bu nedenle MeldID'de yönetici izinlerini merkezî olarak iptal etme özelliği bulunuyor.

Bir izin iptal edildiğinde bağlı projeler ilgili olayı alır ve bu izinle ilişkili yönetici oturumlarını geçersiz kılar.

Böylece erişim yönetimi, kullanıcı başarıyla giriş yaptığında sona ermez.

Yetkileri iptal edebilme imkânı, benim için onları verebilme imkânı kadar önemli.

Öte yandan dağıtık bir sistem; olayların iletilmesindeki gecikmeleri, bazı bileşenlerin geçici olarak erişilemez olmasını ve diğer operasyonel koşulları hesaba katmalıdır. Oturumların geçerlilik süresini sınırlamak ek bir güvenlik sınırı oluşturur.

Günlük işleyişte neler değişti?

Her şeyden önce, kayıtlı yönetici parolalarına sürekli başvurma ihtiyacı ortadan kalktı.

Bağlı her yönetim paneline giriş için bir dizi hesap bilgisini tarayıcıda tutmam gerekmiyor.

Bunun yerine izinleri tek bir mekanizma üzerinden yönetiyorum.

Gerekli projeyi seçiyor, erişimi onaylıyor ve çalışmaya başlıyorum.

Yönetici erişimi artık gerekmediğinde iptal edilebiliyor.

Yeni bir proje eklendiğinde yönetici kimlik doğrulama sisteminin tamamını baştan tasarlamak gerekmemesi özellikle kullanışlı.

Projeyi mevcut modele bağlamak ve gerekli izinleri belirlemek yeterli.

Elbette bu, tüm güvenlik risklerinin ortadan kalktığı anlamına gelmiyor.

Geçici izinler, güvenilir cihazlar, sunucu oturumları ve merkezî altyapı da korunmalı.

Ancak artık her uygulama için yönetici parolalarını yönetme sorununu ayrı ayrı çözmem gerekmiyor.

Bu da başlangıçtaki hedeflerimden biriydi.

Bu tür teknolojiler zaten yok mu?

Elbette var.

Parolasız kimlik doğrulama, ayrıcalıklı erişim yönetimi, geçici izinler ve güvenilir cihazlar üzerinden onay, bilgi güvenliği sektöründe uzun zamandır biliniyor.

Bu yaklaşımlara Identity and Access Management, Privileged Access Management sistemlerinde ve Zero Trust konseptlerinde rastlanıyor.

Bu ilkeleri benim icat ettiğimi iddia etmiyorum.

Benim görevim başkaydı.

DigiMeld altyapısının belirli sorunlarını çözen ve birbirinden bağımsız birçok projeye yönetici erişimini yönetmeyi sağlayan, entegre ve kendime ait bir sistem oluşturmam gerekiyordu.

Sonuçta, ihtiyaçlarıma uygun tek bir mimaride bilinen birkaç yaklaşımı bir araya getirdim.

Mühendislik çalışmasının değerinin mutlaka tamamen yeni bir teknoloji icat etmekte yattığını düşünmüyorum.

Bazen önemli olan, sorunu doğru tanımlamak ve ona uygun bir çözüm bulmaktır.

MeldID yalnızca yönetim panelleri için değil

Burada ayrıca açıklığa kavuşturulması gereken bir nokta var.

MeldID yalnızca kendi yönetici erişimim için bir araç olarak oluşturulmadı.

Geliştiricilere, kimlik doğrulama ve giriş onayı mekanizmalarını kendi uygulamalarına entegre etmeleri için bir SDK da sunuyor.

Üstelik bu SDK ücretsiz olarak kullanılabiliyor.

Örneğin, üçüncü taraf bir geliştirici MeldID'yi kullanıcı kimlik doğrulamasına ek bir onay katmanı olarak kullanabilir.

Uygulamada geleneksel kullanıcı adı ve parola girişi bulunsa bile bu bilgilerin doğru girilmesi, kimlik doğrulamayı tamamlamak için yeterli olmayabilir.

Kullanıcıya güvenilir mobil cihazına bir istek gönderilir; kullanıcı bu cihazda giriş denemesini onaylar ya da reddeder.

Bu, hesap bilgilerinin ele geçirilmesi durumunda yetkisiz erişim riskini azaltmaya yardımcı olur.

MeldID'nin herkese açık bu olanağıyla DigiMeld projeleri için geliştirdiğim yönetici erişimi modelini birbirinden ayırmak önemlidir.

Bu iki çözüm ortak güven ve işlem onayı ilkelerini kullanıyor, ancak farklı sorunları ele alıyor.

Güvenlik, var olanı korumaktan ibaret değil

Bu sistem üzerinde çalışmak, alışılmış kimlik doğrulama mekanizmalarına farklı gözle bakmamı sağladı.

Çoğu zaman tarihsel nedenlerle varlığını sürdüren şeyleri korumaya çalışıyoruz.

Yeni kontroller, kısıtlamalar, ek parolalar ve güvenlik katmanları ekliyoruz.

Bazen bu gerçekten gerekli.

Ama bazen başka bir soru sormak daha yararlı:

Koruduğumuz mekanizmanın kendisi, eskisi gibi var olmak zorunda mı?

Benim durumumda yanıt hayır oldu.

Sürekli erişilebilir bir yönetici giriş formuna ihtiyacım yoktu.

Yönetici yetkilerini yalnızca gerektiğinde güvenli bir şekilde elde edebilmem gerekiyordu.

Bunlar iki farklı görev.

İlkinden ikincisine geçiş, yalnızca teknik mimariyi değil, projelerle günlük çalışma biçimimi de değiştirdi.

Son nokta değil, seçilmiş bir yön

Bugün bu mimari, DigiMeld ekosisteminin önemli bir bölümünde çalışıyor.

Geriye kalan projeler de aşamalı olarak yeni yönetici erişimi modeline geçiriliyor.

Her uygulamanın çalışmasını kontrol ederek geçişi sırayla gerçekleştiriyorum. Geçiş tamamlandıktan sonra tüm sistem için ek bir denetim yapmayı planlıyorum.

Arayüzün bazı bölümleri ve oturum yönetimi kuralları hâlâ değişebilir.

Ancak temel fikir artık belli.

Kendi onlarca projemi yönetmek için onlarca yönetici parolasını sürekli saklamam ve kullanmam gereken modele geri dönmek istemiyorum.

Öte yandan kendi uygulamamı herkes için evrensel bir çözüm olarak görmüyorum.

Farklı kuruluşların ihtiyaçları, altyapıları, tehdit modelleri ve yönetim biçimleri birbirinden farklı.

DigiMeld ekosistemi için kullanışlı ve uygun olan bir yaklaşım, başka bir geliştirici için en iyi seçenek olmayabilir.

Ancak yetkileri geçici olarak verme ilkesi dikkate değer.

Sonuç yerine

Bu deneyimi paylaşmaya karar verdim; çünkü kendimi yeni bir kimlik doğrulama yöntemi icat etmiş biri olarak görmüyorum.

Bir sistemi mutlak anlamda güvenliymiş gibi tanıtmak istediğim için de değil.

Mutlak güvenlik diye bir şey yok.

Bana yalnızca sorunun kendisini ele alış biçimi ilginç geliyor.

Sürekli açık olan yönetici girişini durmadan korumaya çalışmak yerine, böyle bir girişe gerçekten ihtiyaç olup olmadığını yeniden değerlendirebiliriz.

Bir sürü parola saklamak yerine geçici izinler kullanabiliriz.

İlk kimlik doğrulamadan sonra otomatik olarak güvenmek yerine, belirli yetkilerin verilmesini onaylayabiliriz.

Oturumun sona ermesini beklemek yerine erişimi merkezî olarak iptal etme imkânı sunabiliriz.

Son olarak, her proje için ayrı bir giriş mekanizması kullanmak yerine uygulamaların bağımsızlığını koruyarak yönetici erişimini tek bir sistem üzerinden yönetebiliriz.

Bu yaklaşımın ele geçirilme ihtimalini ortadan kaldırdığını iddia etmiyorum.

Yalnızca odağı, sürekli var olan hesap bilgilerini korumaktan yetkileri kontrollü bir şekilde verip sonlandırmaya kaydırıyor.

Belki de bazen saldırı yüzeyini küçültmenin en etkili yolu, bir koruma mekanizması daha eklemek değil, sistemin onsuz da çalışabileceği bir şeyden vazgeçmektir.

MeldID Admin Gateway'in hikâyesi benim için tam da bu düşünceyle başladı.