Son sürat yazı dizimize devam ediyoruz. Yazı dizimizin birinci bölümünde ana başlığımız olan Security Desing Principles’ı açıkladıktan sonra onun alt başlıklarından Risk, Frame Risk, Treat Risk ve Information Systems’ Controls konularına değindik. Eğer o yazıyı okumadıysanız bu yazıyı okumadan önce onu okumanızı tavsiye ederim. Aşağıdaki linke tıklayarak yazının ilk ölümüne ulaşabilirsiniz.
Bu bölümde yine Security Design Principles (Güvenlik Dizayn Prensipleri) içerisinde yer alan şu başlıkları inceleyeceğiz:
- Need to Know
- Least Privilege
- Access Control
- Seperation of Duties
- Defense in-depth
Konsept, prensip, kural, kanun vs. Sürekli bunları konuştuğumuzun farkındayım. Anca bunlara hakim olmadan gelecekteki konuları inşa etmemiz mümkün olmayacak. O yüzden sıkın dişinizi :)
Çayınız veya kahveniz hazırsa sıcakken bir yudum alın ve başlayalım.
Need to Know
Need to Know’dan daha önce kısaca bahsetmiştik. Şimdi ise detaylandırma zamanımız geldi. Bu kavram bize hem confidentiality (gizlilik) hem accountability (hesap verebilirlik) sağlamayı hedefler. Sadece gerekli kişilerin sadece gerekli durumlarda veriye erişmesi demektir.
Need to Know genellikle üç aşamaya ayrılır:
- Classification (sınıflandırma)
- Ownership (sahiplik)
- Clearance (açıklık)
Need to know konsepti güvenlik için harika bir adım olsa da bazı dezavantajları da mevcuttur. Bu prensibin uygulanması zaman zaman aynı şeyin defalarca yapılmasına, yanlış kararlar verilmesine, performansın düşmesine veya çalışan mutluluğunun azalmasına sebep olabilir. O yüzden uygulamanın şirketin ve yapılan işin dinamiklerine göre organize edilmesi şarttır.
Least Privilege
Kavram olarak Türkçeye çevirmemiz gerekirse “en az ayrıcalık ilkesi” diyebiliriz. Amacımız bir kişiye veya prosese yalnızca o kişi veya prosese atanmış bir işlemi tamamlaması için gerekli olan minimum düzeyde erişim haklarının (ayrıcalıklar) verilmesidir. Aynı zamanda bu ayrıcalık, yalnızca işlemi tamamlamak için gereken minimum süre için verilmelidir.
Bir kişi veya assetin ayrıcalıklarının sınırlandırılması, neden olunabilecek zarar miktarını sınırlandırarak, bir sistemin hasara maruz kalma olasılığını azaltır. Ancak bu durum ekstra iş yükü ve takip zorunluluğu oluşturacaktır. Bunun için de farklı tasklar için farklı güvenlik seviyeleri gerektiğinde, o işlemi yapacak olan assete en yüksek ayrıcalığı vermek yerine, ona özgü zamanı kısıtlı ve sadece ihtiyacı olacak kadar ayrıcalık vermek gerekir.
İzinler söz konusu olduğunda genel bir yanılgı oluşur. O da izinlerin sadece insanlara verildiğidir. Aslında birçok uygulama, proses veya script bir kullanıcı gibi kullanıcı haklarını kullanarak çalışır. Sanki o kullanıcının kendisiymiş gibi. Hadi bunu biraz daha açalım.
Raskolnikov, sinirli sinirli:
“Eh Sonya”, diye ona bir şeyler söyleyerek itiraz etm…
Yok yok açıklayacağımız bu değildi. Eğer yazılımımız doğru kullanıcı hakları ile doğru şekilde çalışmıyorsa istismar edilmeye son derece açık olacak demektir. Eğer bir yerden sadece veri okuyorsanız, neden o prosese bir de yazma izni veriyorsunuz diye sorarlar. :)
Least Privilege aynı zamanda zaman sınırına da sahip olmalıdır. Yani yetkiyi vermelisiniz ama onu bir zaman sınırı içinde vermelisiniz. Ayrıca bu kavramın bize CIA’yi koruma gibi faydalar sağladığından artık bahsetmemize gerek yok sanırım.
Access Control
Access Control, bizim için verimli ve uygun bir şekilde erişimlere izin vermek anlamını taşıyor.
Erişim kontrolü söz konusu olduğunda iki farklı pencereden bakmamız gerekecek.
Birinci pencere: Privileged Access (Ayrıcalıklı Erişim)
Ayrıcalıklı erişim sadece daha yüksek düzey izinlere gereksinimi olan personel ile sınırlı olmalıdır. Ancak yazılım geliştiriciler çoğu zaman yüksek ayrıcalıklı yetkilerle çalışmak zorunda kalabilirler. Bu erişim kontrolünün zorlaşması, zaman zaman işin yavaşlamasına ve hatta durmasına yol açacak aksiliklere sebep olabileceği anlamına gelir.
Erişim kontrolü politikası ve prosedürü uygulanırken, bu sürecin olmazsa olmaz bir diğer parçası da monitoring (izleme) olacaktır.
İkinci pencere: Runtime (Çalışma Zamanı)
Runtime bir prosesin bir işletim sistemi üzerindeki çalıştığı (yürütüldüğü) zamanı ifade eder. Ve daha önce de bahsettiğimiz gibi çoğu proses ayrıcalıklı haklarla çalışmak isteyebilir. Bazen çalışmak için administrator yetkileri dahi istenebilir. Bu gibi durumlarda istenmeyen zararları engellemek için sistemler varsayılan olarak API’lerin ayrıcalıklı programları otomatik olarak çalıştırmasını kısıtlamalıdır.
Özetleyecek olursak erişim kontrolü, tüm kullanıcılara, sistemlere ve süreçlere uygun erişim seviyelerinin verilmesini sağlamak için bir politika uygulamaktır.
Seperation of Duties
Görevler ayrılığı. Bu kavram aynı zamanda birden fazla isim ile karşınıza çıkabilir. Segregration of Duties veya Compartmentalization Principle. (Üzülmeyin, bunu ben de söylemekte zorlanıyorum)
Görevler ayrılığı, tek bir görevin başarıyla tamamlanmasının, yerine getirilmesi gereken iki veya daha fazla koşula bağlı olduğunu ve bu koşullardan yalnızca birinin görevi kendi başına tamamlamada yetersiz kalacağını belirten bir güvenlik ilkesidir. Yine bir İngilizce tanımı alıp Türkçe yazmaya çalıştık ama biraz havada kaldı sanki. O halde biraz daha açalım.
Bu kavram, herhangi bir görev için birden fazla kişinin dahil edilmesi gerektiğini savunur. Kritik olan görevler birden fazla kişi, kurum veya prosese bölünerek hem güvenli katmanlara ayrılmış olur hem de işin tek bir kişi ile yapılması riskine girilmez. Bu sayede kimse (herkes bir araya gelip voltranı oluşturmadığı sürece) görevini kötüye kullanamayacaktır.
Daha da basiti, nükleer füzeleri göndermek için üç kişinin (ülke başkanı, komutan ve savunma bakanı) aynı anda anahtarı sokup birlikte çevirmeleri gerekliliği gibi. Hepimiz o tarz filmleri izlemişizdir.
Peki ne işimize yarar? Faydaları nelerdir?
- Fraud’u (sahtecilik) zorlaştırır ve tespit edilmesini kolaylaştırır.
- Hataların azaltılmasını sağlar.
- Kişilere bağımlılığı azaltır.
Bu kavram kendi içinde birkaç dezavantaj bulundurur. Bunlardan en önemlisi Risk collusion yani gizli anlaşma riskidir. Yetki verdiğiniz kişilerin bir araya gelerek sisteme zarar vermeye çalışması gibi.
Defense in-depth
Bu kavram özellikle cloud sistemleri yaygınlaştıkça hayatımıza daha çok girdi. Karşımıza Layered Defense olarak da çıkabilir. Türkçesi ile derinlemesine savunma, güvenlik önlemlerinin katmanlara ayrılarak uygulanmasını ve her katmanın bir önceki katman tarafından ekstra korunmasını içeren bir savunma metodolojisidir.
Bir sistemin Single Point of Compromise’a sahip olmamasını amaçlar. Yani tek bir noktadan değerli verileri sızdırmama durumu.
Yüzüklerin efendisi filmindeki kalelerden birini düşünün. Bu kalenin kalın duvarları, duvarların hemen dışında çok derin hendekleri, yüksek savunma noktaları üzerinde okçuları, içeriye girildiğinde de birçok savunma noktası vardır. İşte defense in-depth tam olarak budur.
Eğer hayatınızda Gandalf yoksa %100 güvenlik diye bir şeyin söz konusu olmadığını bilirsiniz. Bu yüzden yazılımlar, defense in-depth mimarilerini kullanmalı ve sürekli güvenlik için ekstra bir adım ekleyebilir miyiz mantığında yaşamlarını sürdürmelidir. Mükemmel denilecek hiçbir güvenlik mekanizması olmadığı için sistemlerimizin tek bir güvenlik önlemine bağlı kalmasına göz yummamalız. Yeterli zaman ve kaynak sağlandığında her şeyin hacklenebileceğini aklımızdan çıkarmamalıyız. Güvenliğin gerçek amacı sadece güzel ve iyi güvenlik önlemleri almak değil, saldırganların bize zarar vermesini olabildiğince zor, maliyetli ve sıkıcı hale getirmektir.
İkinci bölümün de sonuna geldik. Yazılara gelen geri bildirimler sonucunda artık yazıları daha kısa olacak şekilde daha fazla parçaya ayırıyoruz. Bu sayede okuma süreleri daha kısa oluyor.
Bir sonraki bölümümüz olan üçüncü ve son bölümde Fail Safe, Economy of Mechanism and Leveraging Existing Components, Complete Mediation, Open Design, Psychological Acceptability ve Least Common Mechanism and Single Point of Failure konularına detaylı olarak değineceğiz.
Sorularınız ve düzeltme önerileriniz için iletişim: serhanw@pm.me
Kaynaklar:
CSSLP Certification All-in-One Exam Guide, Second Edition 2nd Edition by Wm. Arthur Conklin, Daniel Shoemaker
Official (ISC)2 Guide to the CSSLP CBK ((ISC)2 Press) 2nd Edition by Mano Paul
