Bir mimari özellik olarak güvenlik

Güvenlik çoğu zaman bir listedeki fonksiyon gibi ele alınır: planlanan, uygulanan ve işaretlenip geçilen bir şey; tercihen sonlara doğru, sistemin geri kalanı bittiğinde. Bu anlayış, kimse güvenliği unutmamış olmasına rağmen bu kadar çok sistemin güvensiz olmasının nedenidir. Çünkü güvenlik bir fonksiyon değildir; bütünün bir özelliğidir — parçaların birbirine nasıl bağlandığının, kime güvendiklerinin, neye izinli olduklarının özelliği. Bütünün bir özelliğini, bütüne dokunmadan sona eklemek mümkün değildir.

Bu doküman güvenliği bir mimari özellik olarak ele alıyor: sonda eklenen değil, en baştan birlikte tasarlanan bir şey olarak. Bilinçli olarak framework'ten bağımsız ve bilinçli olarak savunma odaklı tutuldu — sistemlere nasıl saldırılacağını değil, hatalı ve kötü niyetli davranışa dayanan sistemlerin nasıl inşa edileceğini anlatıyor. Hiçbir araç ve hiçbir rakam vermiyor. İlkeler her teknolojiden bağımsız olarak geçerlidir, çünkü bir üründen değil, yapıdan bahsederler.

1. Güvenlik neden bir feature değildir

Fonksiyon, eklediğiniz bir şeydir: bir alan, bir akış, daha önce eksik olan bir yetenek. Güvenlik bu şekilde eklenemez, çünkü tek bir yerde durmaz; tüm yerlerin birbiriyle ilişkisinde yer alır. Bir parçanın kime güvendiğinden, hangi yetkilere sahip olduğundan, neyi kabul ettiğinden, neyi dışarı verdiğinden doğar. Bir sistem, bu ilişkilerin en zayıfı kadar güvenlidir — ve sonradan eklenen hiçbir fonksiyon bunu değiştirmez, çünkü zayıflık eksik bir yetenekte değil, yapının kendisindedir.

Temel tutum buradan çıkar: Güvenlik başa, tasarıma aittir, çünkü onu belirleyen kararlar — sınırlar, yetkiler, güven — tasarım kararlarıdır. Güvenliği sonda "eklemek" isteyen, onun her yerde aynı anda bulunması gerektiğini ve bu yüzden hiçbir yere temiz şekilde eklenemeyeceğini fark eder. Güvenliği geç düşünmek, onu pahalı ve eksik şekilde sonradan donatmak demektir; erken düşünmek ise onu neredeyse kendiliğinden birlikte inşa etmek demektir.

Şema: Sonradan eklendiğinde güvenlik boşluklu bir kabuktur; bir özellik olarak tasarlandığında tüm sisteme yayılır. Yalnızca ikincisi dayanır.

Avantajlar ve sınırlamalar. Güvenliği tasarım aşamasında ele almak, ilk işlevler ortaya çıkmadan emek gerektirir. Karşılığında sonradan düzeltilmesi zor eksiklerin riski azaltılır.

Maliyet. Tasarım daha özenli ve daha yavaş hâle gelir, çünkü güvenlik sorusunu ertelemek yerine her sınırda ve her yetkide birlikte sorarsınız.

Ne zaman farklı karar veririz. Gerçek veri içermeyen ve dış dünyaya erişimi olmayan, atılacak bir prototipte tam güvenlik tasarımı abartılı olur; sistem gerçek verilere ya da gerçek kullanıcılara dokunduğu anda vazgeçilmezdir.

2. Bir tasarım faaliyeti olarak tehdit modellemesi

Bir sistemi hatalı ve kötü niyetli davranışa karşı koruyabilmek için önce neyin ters gidebileceğini bilmeniz gerekir — ve bu, ilk olaydan sonra değil, tasarım sırasında sorulan bir sorudur. Tehdit modellemesi gizemli bir şey değildir: Sistemin her parçası için ona kimin zarar verebileceğini, neyi koruması gerektiğini ve bir varsayım tutmadığında ne olacağını sorma alışkanlığıdır. Bir kez bilinçli olarak sisteme iyi niyetle yaklaşmayan biri gibi düşünürsünüz — saldırmak için değil, zayıflıkları bir başkası bulmadan önce bulmak için.

Bu faaliyetin değeri, görünmeyeni görünür kılmasındadır. Pek çok güvenlik açığı koddaki hatalar değil, tasarımda gözden kaçmış varsayımlardır: bir girdinin zaten doğru olacağı, bir çağıranın zaten yetkili olduğu, sistemin bir parçasının zaten güvenilir olduğu. Tehdit modellemesi bu varsayımları, değiştirilmeleri hâlâ ucuzken gün yüzüne çıkarır. Dolayısıyla bir aşama ya da bir doküman değil, tasarıma yerleştirdiğiniz bir düşünme biçimidir.

Avantajlar ve sınırlamalar. Tehdit modellemesi zaman ve olası hata senaryolarının açıkça tartışılmasını gerektirir. Bu çalışma, geliştirme planında yer bulmalıdır.

Maliyet. Bu alıştırma deneyim ve disiplin ister; bir onay kutusu gibi geçiştirilemez, bir şey kazandırması için samimiyetle yapılması gerekir.

Ne zaman farklı karar veririz. Bir parçanın korunmaya değer verisi ve dışarıdan erişimi açıkça yoksa, derin incelemeden vazgeçilir; dikkat, yabancı olanın kendinize ait olanla buluştuğu sınırlara yöneltilir.

3. En az yetki ilkesi

Güvenli tasarımın tek başına en etkili ilkesi basittir: Bir sistemin her parçası, görevi için ihtiyaç duyduğu yetkileri tam olarak alır — fazlasını değil. Yalnızca okuması gereken bir servis yazamaz. Verilerin yalnızca bir kesitine ihtiyaç duyan bir parça yalnızca o kesiti görür. Bir görev için verilen erişim, o görevle birlikte sona erer. Gerekçe yalındır: Bir parçanın izni olmayan şeyi, o parça ele geçirilmiş ya da hatalı olsa bile yapamaz. En az yetki, hasarı oluşmadan önce sınırlar.

İlke işe yarar, çünkü hatayı önlemek zorunda kalmadan hatanın sonuçlarını sınırlar. Her açığı kapatamazsınız, ancak tek bir açığın tüm sistemi açmamasını sağlayabilirsiniz. Her parçanın her yerde yetkili olduğu bir sistem, en savunmasız parçası kadar güvenlidir; en az yetki ilkesine dayanan bir sistem ise hasarı oluştuğu yerde tutar. Bu yüzden en az yetki bir yapılandırma ayrıntısı değil, bir tasarım tutumudur: Gücü tutumlu dağıtırsınız, çünkü dağıtmadığınız güç kötüye kullanılamaz.

Avantajlar ve sınırlamalar. En az yetki ilkesi, her bileşenin gerçek ihtiyacını belirlemeyi gerektirir. Başlangıçta daha fazla değerlendirme yapılır; karşılığında gereksiz erişimler sınırlandırılır.

Maliyet. Daha ince kademelendirilmiş yetkileri tasarlamak ve bakımını yapmak, toptan yetkilere göre daha fazla iş gerektirir; rahatlık yerini kesinliğe bırakır.

Ne zaman farklı karar veririz. Parçalarının zaten birbirine tamamen güvendiği ve dış sınırı olmayan küçük, kapalı bir sistemde ince kademelendirme abartılı olur; değeri, parça sayısı ve dış dünyaya yakınlıkla birlikte artar.

4. Derinlemesine savunma

Hiçbir koruma önlemi tek başına her zaman dayanmaz. Bir kontrol gözden kaçabilir, bir varsayım çökebilir, bir parça başarısız olabilir. Derinlemesine savunma, asla tek bir savunma hattına güvenmeme, birden fazla hattı arka arkaya dizme tutumudur; böylece birinin başarısızlığını bir sonraki yakalar. Dış kontrol geçirgen hâle gelirse iç kontrol dayanır; çağırana dair bir varsayım doğru çıkmazsa en az yetki hasarı sınırlar. Güvenlik kusursuz tek bir duvardan değil, birlikte dayanan birden fazla kusurlu duvardan doğar.

Şema: Tek bir duvar değil, birden fazla duvar. Dış katman düşerse bir sonraki dayanır — kusursuzluktan değil, yedeklilikten doğan güvenlik.

Avantajlar ve sınırlamalar. Birden fazla savunma katmanı daha dayanıklı koruma sağlar. Karşılığında ek tasarım, bakım ve bir miktar tekrar gerekir.

Maliyet. Her katman, kendi başına tasarlanması, anlaşılması ve bakımı yapılması gereken bir şeydir; çok fazla ya da kötü seçilmiş katman, güvenliği artırmadan karmaşıklığı artırır.

Ne zaman farklı karar veririz. Korunacak şey az ve olası hasar küçükse, iyi seçilmiş tek bir savunma hattı yeterlidir; derinlik, bir başarısızlığın ciddi hasar verdiği yerde karşılığını verir.

5. Güvenli varsayılanlar

Çoğu sistem, en iyi durumda nasıl yapılandırılabileceğine göre değil, varsayılan olarak nasıl ayarlandıysa öyle kullanılır. Bu yüzden varsayılan ayar, en sonuç doğurucu güvenlik kararlarından biridir: Güvenli durum, hiçbir şey yapmadan ulaşılan standart mıdır, yoksa önce aktif olarak oluşturulması mı gerekir? Güvenli varsayılanlar, sistemin şüphe durumunda açmak yerine kapatması demektir — riski bilinçli olarak devre dışı bırakmak zorunda kalmak yerine, ona bilinçli olarak karar vermeniz gerekir. Varsayılan olarak kapalı olan, çoğu kullanıcıda kapalı kalır.

Yapılandırma adımları unutulabilir, ertelenebilir veya yanlış anlaşılabilir. Güvenli varsayılanlar, güvenliğin her kullanıcı tarafından ayrıca yapılandırılmasına olan bağımlılığı azaltır. Amaç, sistemin normal kullanım yolunun aynı zamanda güvenli yol olmasıdır.

Avantajlar ve sınırlamalar. Güvenli varsayılanlar, çoğu kullanıcı için riski azaltır. Özel durumlarda daha geniş yetkiye ihtiyaç duyan kullanıcıların bunu bilinçli olarak etkinleştirmesi gerekebilir.

Maliyet. Güvenli standardı belirlemek ve ona bağlı kalmak, tasarımda çoğu zaman daha açık olan rahat seçeneğin cazibesine karşı karar vermeyi gerektirir.

Ne zaman farklı karar veririz. Kısıtlayıcı varsayılanın yalnızca yavaşlattığı, uzmanlar tarafından işletilen kapalı bir ortamda standart daha açık olabilir; kullanıcı kitlesi ne kadar geniş ve tanımadık olursa, standart o kadar katı olmalıdır.

6. Sınırlarda güven

Güvenlik sınırlarda belirlenir — yabancı olanın kendinize ait olanla buluştuğu yerde. En önemli kural şudur: Dışarıdan gelen hiçbir şey kendiliğinden güvenilir değildir. Kendi sınırınızın ötesinden gelen her girdi, her çağrı, her mesaj, etki etmesine izin verilmeden önce doğrulanır — tek tek göndericilere duyulan güvensizlikten değil, tüm göndericileri tanımadığınız ve aralarından birinin iyi niyetli olmayabileceği için. Bir sınırın içinde güvenli sayılan şey, sınırda önce güvenli hâle gelmelidir.

Bu, sınırlarınızı her şeyden önce bilmenizi gerektirir: Kontrol ettiğiniz şey nerede bitiyor ve yalnızca gözlemleyebildiğiniz şey nerede başlıyor? Bu tür her çizgi bir güven sınırıdır ve her birinde, açık bir arayüzün tasarımındaki özen geçerlidir — içeri neyin girebileceğinin doğrulanması sözleşmenin bir parçasıdır. Sınırlarını bilmeyen bir sistem, tanımadığı şeylere farkında olmadan güvenir; sınırlarını bilen bir sistem ise her birinde içeri neyi aldığına bilinçli olarak karar verir.

Dört temel güvenlik ilkesinin özeti. Her biri tek bir yapılandırma ayarından ziyade bir tasarım yaklaşımıdır:

Avantajlar ve sınırlamalar. Her sınırda doğrulama yapmak ek işlem yükü ve gecikme yaratabilir. Bu maliyet, sağlanan korumayla birlikte değerlendirilmelidir.

Maliyet. Sınırları bilmek ve her birinde tutarlı şekilde doğrulamak, günlük işte "çağıran zaten tanıdık" diye kolayca rahatlığa feda edilen bir disiplin gerektirir.

Ne zaman farklı karar veririz. Tüm parçaların aynı güvene tabi olduğu ve birlikte işletildiği, açıkça kapalı bir sınırın içinde her iç çizgide doğrulama yapmanız gerekmez; tam özen dışa açılan sınırlar için geçerlidir.

7. İnsani ve operasyonel taraf

Güvenlik, tasarımın yanı sıra işletim süreçlerine de bağlıdır. Gizli bilgilerin güvenli saklanması, yamaların uygulanması ve bağımlılıklardaki açıkların takibi gerekir. Güvenli süreçlerin anlaşılır ve uygulanabilir olması da önemlidir; aşırı iş yükü veya zaman baskısı kontrollerin atlanma riskini artırabilir.

Bu taraf dehadan çok istikrar gerektirir. Gizli bilgiler korunmalı ve kodun içine konmamalıdır; bağımlılıklar izlenmeli ve bilinen açıkları zamanında kapatılmalıdır; erişimler artık gerekmediğinde geri alınır; süreçler de güvenli yol aynı zamanda kolay yol olacak şekilde tasarlanmalıdır ki kimse baskı altında onu atlamasın. Bu yüzden güvenlik tek seferlik bir başarı değil, süregelen bir bakımdır — bir sistem, bir zamanlar nasıl tasarlandığı kadar değil, bugün nasıl işletildiği kadar güvenlidir.

Avantajlar ve sınırlamalar. Operasyonel güvenlik, sürekli izleme, güncelleme ve bakım gerektirir. Korumanın sürmesi için bu işe düzenli kaynak ayrılmalıdır.

Maliyet. Bu emek görünür hiçbir şey üretmez ve bu yüzden dikkat ve zaman için sürekli olarak bir sonraki feature ile rekabet eder.

Ne zaman farklı karar veririz. Burada da geçerlidir: Ne korunmaya değer veri ne de dışarıdan erişim varsa bakım daha yalın olabilir; ikisi de devreye girdiği anda pazarlık konusu değildir.

8. Dürüst sınırlar

Güvenlik üzerine dürüst bir doküman, güvenliğin ne olmadığını da söyler: bir garanti. Mutlak güvenlik yoktur ve bunu vaat eden kişi bir sistem değil, bir his satar. Güvenlik bir risk yönetimidir — hatalı ve kötü niyetli davranışın olasılığını ve sonuçlarını, bir kalıntının her zaman kalacağını bilerek, kabul edilebilir bir düzeye bilinçli olarak indirmek. Bu dürüstlük bir zayıflık itirafı değil, akıllıca kararların ön koşuludur: Ancak güvenliğin hiçbir zaman bitmediğini ve hiçbir zaman eksiksiz olmadığını bilen kişi, onu en çok koruma sağladığı yere yatırır.

Güvenlik kontrolleri kullanım kolaylığını etkileyebilir. Doğrulama adımları, yetki sınırları ve ek kontroller kullanıcıya iş yükü getirebilir. Amaç, kontrolleri somut riske göre seçmektir: yüksek zarar olasılığında daha sıkı koruma, düşük riskli alanlarda daha yalın süreçler. Güvenlik, kalan riskin açıkça değerlendirildiği bir yönetim sürecidir.

Avantajlar ve sınırlamalar. Güvenliği risk yönetimi olarak ele almak, tamamen giderilemeyen riskleri açıkça kabul etmeyi gerektirir. Mutlak güvenlik beklentisi yerine gerçekçi önlemler ve sorumluluklar belirlenir.

Maliyet. Doğru ölçüyü bulmak, bir kurala devredilemeyecek şekilde olasılık ve hasar hakkında muhakeme gerektirir.

Ne zaman farklı karar veririz. Olası hasarın varoluşsal olduğu yerde değerlendirme, rahatlık pahasına da olsa güçlü biçimde güvenlik yönüne kayar; hasar küçükse rahatlık ağır basabilir.

9. Tipik hatalar

Güvenli sistemlerin başarısız olduğu tekrarlayan kalıplar — neredeyse hepsi, güvenliği bir özellik yerine bir fonksiyon olarak ele almanın varyasyonlarıdır:

• Güvenliği sona ertelemek ve onu, her yerde aynı anda bulunması gereken bitmiş sisteme "eklemek" istemek.
• Varsayımları doğrulamak yerine gerçek saymak — bir girdinin doğru, bir çağıranın yetkili, bir parçanın güvenilir olduğunu.
• Yetkileri cömertçe dağıtmak; böylece hasarı sınırlamak yerine tek bir açığın tüm sistemi açmasına izin vermek.
• Başarısız olduğunda arkasında hiçbir şey olmayan tek bir savunma hattına güvenmek.
• Güvensiz olanı varsayılan yapmak ve birinin onu daha sonra doğru yapılandıracağını ummak.
• Sınırlarını bilmediği için dışarıdan gelene farkında olmadan güvenmek.
• Gizli bilgileri açık metin olarak saklamak ve bağımlılıklardaki bilinen açıkları açık bırakmak.
• Güvenli süreçleri, insanların baskı altında onları atlayacağı kadar zahmetli tasarlamak.
• Mutlak güvenlik vaat etmek ve böylece dürüst değerlendirmenin yerine yanlış bir vaat koymak.

10. Karar kontrol listesi

Bir sistemin tasarımından önce ve tasarımı sırasında sırasıyla netleştirilmesi gerekenler:

• Fonksiyon değil, özellik mi? Güvenlik en baştan birlikte düşünüldü mü — yoksa sonradan eklenecek bir parça olarak mı planlandı?
• Tehditler düşünüldü mü? Her parça için ona kimin zarar verebileceği ve neyi koruması gerektiği soruldu mu?
• En az yetki? Her parça yalnızca görevi için ihtiyaç duyduğunu mu alıyor — fazlasını değil?
• Derinlemesine savunma? Her savunma hattının arkasında, onun başarısızlığını yakalayacak bir başkası var mı?
• Güvenli varsayılan? Güvenli durum, hiçbir şey yapmadan ulaşılan standart mı?
• Sınırlar biliniyor ve doğrulanıyor mu? Güven sınırları adlandırıldı mı ve her birinde içeri neyin girebileceği doğrulanıyor mu?
• Gizli bilgiler ve bağımlılıklar? Gizli bilgiler korunuyor, bağımlılıklar izleniyor, bilinen açıklar zamanında kapatılıyor mu?
• Güvenli yol kolay yol mu? Süreçler, kimsenin baskı altında güvenli yolu atlamayacağı şekilde mi tasarlandı?
• Mutlaklık yerine ölçü mü? Güvenlik riske uygun mu — hasarın büyük olacağı yerde katı, küçük olacağı yerde hoşgörülü mü?

Bu soruların tasarım sırasında yanıtlanması, güvenliğin sisteme sonradan eklenmek yerine mimarinin parçası olmasını sağlar.

Sıkça Sorulan Sorular

Güvenlik sonradan eklenemez mi? Ancak eksik ve pahalı şekilde. Güvenlik tek bir yerde değil, tüm parçaların ilişkisinde — sınırlarda, yetkilerde, güvende — yer alır. Bunlar tasarım kararlarıdır; onları sonda değiştirmek, tüm sisteme dokunmak demektir. Erken düşünüldüğünde güvenlik neredeyse kendiliğinden birlikte inşa edilir; geç düşünüldüğünde zahmetli ve boşluklu şekilde sonradan donatılır.

Tek başına en etkili ilke hangisidir? En az yetki. Her parça yalnızca görevi için ihtiyaç duyduğunu alırsa, tek bir açık tüm sistemi açamaz — hasar oluştuğu yerde kalır. Bu ilke her hatayı önlemez, ancak her hatanın sonuçlarını sınırlar ve bu çoğu zaman daha değerlidir.

Tehdit modellemesi saldırgan gibi düşünmemiz gerektiği anlamına mı gelir? Yalnızca zayıflıkları bir başkası bulmadan önce bulacak kadar. Mesele saldırı teknikleri değil, her parça için şunu sorma alışkanlığıdır: Burada ne ters gidebilir, bunu kim tetikleyebilir, sonucu ne olur? Bu sorular, gözden kaçmış varsayımları değiştirilmeleri hâlâ ucuzken gün yüzüne çıkarır.

Mutlak güvenlik var mıdır? Hayır. Güvenlik bir garanti değil, risk yönetimidir — olasılığı ve sonuçları, bir kalıntının her zaman kalacağını bilerek kabul edilebilir bir düzeye bilinçli olarak indirmek. Mutlaklık vaat eden kişi bir his satar. Bu dürüstlük, güvenliği eşit şekilde dağıtmak yerine en çok koruma sağladığı yerde kullanmanın ön koşuludur.

Ne kadar güvenlik yeterlidir? Riskin gerektirdiği kadar — olası hasarın büyük olduğu yerde katı, küçük olduğu yerde hoşgörülü. Azami güvenlik kullanılamaz olurdu, çünkü güvenlik ve rahatlık çoğu zaman farklı yönlere çeker. Mesele, her yerde akla gelebilecek en yüksek korumayı değil, bilinçli olarak ve hasara göre farklı seçilen uygun ölçüyü bulmaktır.

Güvenlik bir tasarım konusu mu, yoksa işletim konusu mu? İkisi birden, birbirinden ayrılmaz şekilde. Özellik tasarımda doğar — sınırlar, yetkiler, varsayılanlar —, ancak işletimde korunur ya da kaybedilir: gizli bilgilerin yönetimiyle, bilinen açıkların zamanında kapatılmasıyla, bağımlılıkların bakımıyla. İyi tasarlanmış ama kötü işletilen bir sistem güvensizdir; bu yüzden güvenlik hem mimarinin masasına hem de işletimin rutinine aittir.

İleri okuma

• Uzun ömürlü sistemler için API tasarımı — girdilerin doğrulandığı bir güven sınırı olarak sözleşme yüzeyi.
• Tahminden önce geri alınabilirlik — derinlemesine savunmanın bir biçimi olarak hasarı sınırlamak ve kararları geri alınabilir tutmak.
• Observability bir mimari meselesidir — yalnızca fark ettiğinizi savuşturabilirsiniz; gözlemlenebilirlik, hatalı ve kötü niyetli davranışı görmenin ön koşuludur.
• OIDC — sınırda erişim ve kimliğin somut bir yapı taşı.

Temelini Batunet Engineering Method oluşturur: hata durumuna göre tasarlamak, güvensiz olanı küçük tutmak, sınırları bilinçli çizmek, varsayılan olarak güvenli olmak.

Temel mühendislik ilkesi

Güvenlik, tasarım ve işletim boyunca korunması gereken bir sistem özelliğidir. Erişim sınırları, güvenli varsayılanlar ve hata senaryoları ilk günden ele alınmalıdır. Sonradan eklenen kontroller, mimarideki temel eksikleri her zaman gideremez. Bu nedenle güvenlik değerlendirmesini ilk olaydan sonraya bırakmıyoruz.

Güvenliği bitmiş bir sisteme vidalamazsınız — böyle düşünüldüğü için güvenli olan bir sistem inşa edersiniz. Geri kalan her şey, boşluklarını ancak gerçek bir olay anında gördüğünüz bir duvardır.