ARCSIGHT LOGGER’DA YENİ SEARCH İLE GELEN ÖZELLİKLER VE YAYGIN KULLANILAN OPERATÖRLER

Arcsight Logger Nedir ?

Günümüzde siber güvenlik tehditlerinin artmasıyla log yönetimi önemli bir konu haline gelmektedir. Log yönetimini özetle anlatmak gerekirse, BT  sistem loglarının toplanması, saklanması ve analiz edilmesidir. Tam da burada ArcSight ürün ailesinin bir üyesi olan logger devreye girmektedir. Logger toplanan logların depolanmasında, analiz edilmesinde ve arşiv özelliği ile geçmişe dönük search yapmamıza olanak sağlayan bir platformdur. Bu yazımda logger search performansını arttırmanın yöntemlerini, yaygın kullanabileceğimiz operatörleri ve 7.0 güncellemesi ile gelen search kısmında ki yeniliklere değinmeye çalışacağım. Keyifli okumalar dilerim.

Arcsight Logger Search Performansını Arttırmak

 Orta ölçekli bir şirketin ürettiği günlük log sayısı bile milyonları geçmektedir. Hal böyle olunca da milyonlarca log arasından istediğimiz logları analiz etmek ve bunu mümkün olan en az kaynak ve zamanla yapmak hayli önem teşkil etmektedir. Birçok faktör arama ve tarama hızını etkileyebilmektedir. Bir aramanın gerektirdiği süre, aranacak veri kümesinin boyutuna, query karmaşıklığına, peer yapı olup olmamasına göre değişmektedir. Aynı sistemdeki 2 Logger aynı versiyona ve konfigürasyona sahip olsa bile üzerindeki anlık yüklerden dolayı search zamanları farklılık gösterebilmektedir.

Search performansını etkileyen ilk unsurlardan biri yapılı veya yapısız aramalardır.

Arama yerine sadece bir kelime yazmak çoğu zaman kolaydır, fakat hız olarak daha yavaştır.

Arama yerine biraz daha zaman ayırıp yukarıdaki query yazıldığında taranan event sayısına göre arama işlemi daha hızlı gerçekleşmektedir. Bunun sebebi index alan ile arama yapmaktır. Logger’da alanlar 4’e ayrılmaktadır. Bunlar Superindex alanlar, Index alanlar, Indexable alanlar ve Metadata alanlarıdır.

Şekilde görüldüğü üzere koyu yeşil alanlar superindex alanlarıdır. Bu alanlarda arama işlemi index ve diğer alanlara göre daha hızlı gerçekleşmektedir. Yeşil alanlar ise index alanları temsil etmektedir. Superindex alanlardan sonra arama işlemi en hızlı bu alanlarda gerçekleşmektedir. Indexable alanlar ise varsayılan olarak indexlenmemiştir. Ancak ihtiyaç doğrultusunda index alan yapılabilen alanlardır. Indexable alanlar bir kez index alan yapıldıktan sonra silinemezler. Eğer çok fazla indexable alan index alan yapılırsa logger’da arama hızı ve rapor oluşturma süresi artabilmektedir. Bununla birlikte index alan sayısı arttıkça logger üstünde daha fazla disk alanı kaplamaktadır. Metadata alanlar ise üzerinde değişiklik yapamadığımız ve diğer alanlara göre arama hızı en yavaş olan alanlardır.

Search performansını etkileyen bir diğer unsur ise storage groups’tur. Logger yüklendiğinde varsayılan olarak 2 grup karşımıza çıkmaktadır. Bunlar default storage group ve internal storage group’tur. Default storage group, logger’a yönlendirilmiş logların kayıt altına alındığı alandır. İnternal storage group ise logger’ın kendi loglarının saklandığı alandır. Bir search işlemi gerçekleştirileceği zaman storage group ismi ile arama işlemi yapıldığında hangi logu nerede arayacağı belirtildiği için search performansı artmaktadır. Aynı zamanda storage group alanının doluluk seviyesi de search performansını etkilemektedir.

Kompleks query kullanımı da search performansını etkileyen bir diğer unsurdur. Rex, sort, chart ve eval gibi operatörlerin kullanımı search performansını düşürmektedir. Bununla birlikte iyi network altyapısı, peer loggerların aynı subnette bulunması, çok fazla Schedule report, search ve forward’lama search performansını etkileyen unsurlardandır.

ArcSight Logger Yaygın Kullanılan Operatörler

Boolan Operatörler: AND, OR, OR NOT gibi operatörlerdir.

AND: AND operatörü ve anlamına gelmektedir. A ve B şartlarının her ikisinin de gerçekleşmesi durumunda sonuç getirir.OR: OR operatörü veya anlamına gelen operatördür. A veya B şartlarının birinin oluşması durumunda sonuç getirir.

OR NOT: OR operatörünün zıttı olarak kullanılan operatördür.

Cef: |cef <Alan Adı> şeklinde kullanılan operatördür. Almak istediğimiz alanı selected fields bölümüne ekler ve seçili alanı öne getirmeye yarar.

Dedup: |dedup <Alan Adı> şeklinde kullanılarak aynı tip logları tekil hale getiren operatördür.

Top ve Chart by count: |top <Alan Adı> veya |chart by count <Alan Adı> Şeklinde kullanılan operatörlerdir. Seçili alanı grafiksel olarak getirmeye yarar.

Where: Koşul operatörüdür. | where <Alan Adı> <İstenen Koşul> şeklinde kullanılmaktadır.

Arcsight Logger 7.0 Güncellemesi ile Search’te Olan Yenilikler

ArcSight Logger’a 7.0 güncellemesi ile birçok yenilik gelmiştir. Search alanında gelen yenilikler olarak EndTime’a göre arama yapma, Yeni search arayüzü, Renk kodlu query arama özelliği, Event alanlarını özelleştirme, raw event view, grid view ve event karşılaştırma özellikleri gelmiştir.

EndTime’a Göre Arama Yapma Özelliği

Önceden logger’da search işlemi sadece logger receipt time’a göre yapılabiliyordu. Logger receipt time, logların logger’a ulaştığındaki zamanına göre arama yapma anlamına gelmektedir. EndTime kullanıldığında ise logların kaynakta oluştuğu saate göre arama yapılmaktadır.

Renk Kodlu Query Özelliği ve Yeni Arayüz

Yeni arayüz ile birlikte kullanılabilen renk kodlu query özelliği ile query yazımında yazım hatasının önüne geçilebilir hale gelmektedir.

Event Alanlarını Özelleştirme

Event alanlarını özelleştirme seçeneği ile birlikte şekilde görülen kategoriler yardımıyla istediğimiz alanları seçili alan bölmesine taşıyarak kullanıma göre özelleştirme işlemleri gerçekleştirebilmekteyiz.

Raw Event View

Yeni arayüz ile birlikte gelen bir diğer özellik ise seçtiğimiz event’e ait details sekmesi ekrana gelmektedir. Buradan daha okunaklı bir şekilde raw event, agent bilgileri, category bilgileri gibi bilgiler çok daha rahat bir şekilde okunabilmektedir.

Grid View

Izgara görünümü sayesinde alanlar daha okunaklı hale getirilmiştir.

Event Karşılaştırma Özelliği

Son olarak 7.0 güncellemesi ile birlikte arama kısmında event karşılaştırma özelliği gelmiştir. Alan isimleri sol tarafa gelerek sütun halinde eventlerimizi kıyaslayabiliriz.

Kaynaklar

https://community.microfocus.com/t5/Logger/Logger-Release-Notes-7-0/ta-p/2750305

https://community.microfocus.com/t5/Logger/Logger-Administrator-s-Guide-7-0/ta-p/2750303

https://community.microfocus.com/t5/Logger/Logger-Best-Practices-Guide-7-0/ta-p/2750307

Görey Eğribel

KRİPTOGRAFİK ZAFİYETLER

Bu yazımda e-dönüşüm çerçevesinde kurumların sıkça kullandığı elektronik imza mimarisindeki özet fonksiyonlar ve ödeme sistemlerindeki hassas verilerin güvenliğinin temelini oluşturan DES algoritmalarının metodolojilerine değinip, performans ve ataklara karşı dayanıklılıklarına göz atacağız. Keyifli okumalar dilerim.

Sayısal İmza ve Özet Fonksiyonları

Açık anahtar altyapısında (Public Key Infrastructure) sayısal imza, public ve private anahtar çiftlerinden private ile veriye dijital ortamda vurulan elektronik bir mühürdür. Sayısal imzalar göndericinin kimliğinin inkâr edilemez şekilde teyit edilmesini ve verinin bütünlüğünün kontrolünü sağlar.

Sayısal imza, imzalayacak tüzel veya gerçek kişiye ait sertifikaya bağlı private anahtar ile, imzalanacak verinin belirli fonksiyonlara tabii tutulması sonucunda oluşur. İşleyişi kısaca özetlemek için öncelikle kriptografik algoritmalardan olan özet fonksiyonlarından bahsetmek gerekecektir.

Özet fonksiyonlar, bir mesajın uzunluğu ne olursa olsun; kullanılan fonksiyona göre aynı uzunlukta parmak izi (message digest) oluşturan fonksiyonlardır. Aynı verinin aynı özet fonksiyonu ile işleme tabii tutulması her zaman aynı çıktıyı verecek olmasıyla birlikte; eğer iyi bir özet fonksiyonu kullanılıyorsa verideki tek bitlik bir değişiklik bile özette içerik olarak bambaşka bir çıktıya sebep olacaktır. Özet fonksiyonlar ile tüm verinin şifrelenmesinin önüne geçilerek, kaynak kullanımının ve hareket edecek toplam verinin boyutunun düşürülmesi sağlanır. Bu sayede daha az kaynak ve bant genişliği kullanılabilir. Özet fonksiyonların en büyük özelliği ise özet verisinden orijinal verinin elde edilemiyor olmasıdır.

Bir verinin imzalanması, önce o verinin özet fonksiyonu ile dijital özetinin çıkartılması akabinde oluşan özet çıktının anahtar çiftlerinden private anahtar ile şifrelenmesi anlamına gelmektedir.

Bu noktada kullanılacak özet fonksiyonun doğru seçilmesi gerekmektedir. Uzun yıllar boyunca SHA-1 ve MD5 algoritmaları kullanımdayken artık bu algoritmalar özetin, orijinal veriye döndürülemezliği açısından yeterli görülmemektedir. Şimdi bu özet algoritmalara kısaca göz atalım.

MD5 (Message-Digest Algorithm 5)

1991 yılında Ron Rivest tarafından tasarlanmıştır. Giriş verisini 512-bit lik bloklar halinde işleyip, 128-bit lik çıktı üretmektedir. 2004 yılında, collision a karşı güvenli olmadığı kamuoyuna duyurulmuştur. Günümüzde kullanılmamaktadır.

Secure Hash Algorithm (SHA)

SHA özetleme algoritması NSA tarafından tasarlanmış ve NIST (National Institute of Standards and Technology) standardı olarak yayımlanmıştır. Kriptografik algoritmalarda karşı karşıya gelinen en önemli problemlerden biri çakışma (collision)dır. Collision, farklı verilerin kriptografik fonksiyonlara tabii tutulduktan sonra aynı çıktıyı vermeleri durumuna denir. SHA algoritması da bu sorunun önüne geçilmesi adına zaman içerisinde geliştirilerek dönemin mevcut computing power ına karşı yeterli seviyede collision resistant bir hale getirilmeye çalışılmıştır.

SHA-1

Maksimum 2⁶⁴-1 bitlik mesajdan 160 bit’lik özetleme değeri üretir. 2010 yılından itibaren güvenli kabul edilmemektedir.

SHA-2

SHA-2 ailesi, 2001 yılında yayınlanmış olup 6 özet fonksiyonuna sahiptir. Bunlar 224, 256, 384, 512, SHA-512/224, SHA-512/256 dır. Güvenli şifre özeti için Unix/Linux üreticileri SHA-256/512 kullanırken; bitcoin gibi birçok kripto para birimi işlemleri, doğrulama yapmak, para iletimini kanıtlamak ve hisseleri kapatmak için SHA-256 kullanmaktadır.

 En yaygınlarından SHA-256 ve SHA-512 arasındaki temel farklara değinecek olursak. SHA-256, 2⁶⁴  bit e kadar girdileri, 512-bit lik parçalara ayırarak işlemekte ve çıktı olarak 256-bit uzunluğunda veri üretmektedir.

Öte yandan SHA-512, 2¹²⁸ bit e kadar olan girdileri 1024-bit lik parçalara ayırıp işlemekte ve 512-bit uzunluğunda çıktılar üretmektedir. SHA-512 kullanılması durumunda 256-bit, SHA-256 kullanılması durumunda, 128-bit collision a karşı dayanıklılık sağlanacaktır. Şu anki ve öngörülebilir teknolojik ilerlemeyi göz önüne alırsak ikisi de yeterli seviyede güvenli sayılmaktadır. SHA-256 32-bitlik işlemcilerde genelde daha hızlı çalışırken; SHA-512, 64-bit işlemcilerde daha performanslı çalışmaktadır. Ancak kuantum hesaplama ile SHA-512 özet algoritmasının yaygınlaşması beklenmektedir. Günümüzde, çıktısının daha kısa olması ve bant genişliğinin daha efektif kullanılması adına SHA-256 tercih sebebidir.

            Bilgi Teknolojileri ve İletişim Kurumu (BTK) tarafından hazırlanan “Elektronik İmza ile İlgili Süreçlere ve Teknik Kriterlere İlişkin Tebliğ’de Değişiklik Yapılmasına Dair Tebliğ” Resmi Gazete’de yayımlanarak yürürlüğe girdi. Tebliğ ile ile birlikte elektronik imza oluşturma ve doğrulama verileri ile özetleme algoritmalarında daha gelişmiş ve güvenli  SHA-2 ve SHA-3 uygulamasına geçildi. Elektronik Sertifika Hizmet Sağlayıcılar (ESHS) ler ise 1 yıl içerisinde yeni standartlara uyum sağlamak ile yükümlü olacaklar. Düzenleme sonrası geçerli kılınan algoritma ve parametreler 31 Aralık 2022’ye kadar geçerli olacak.

Kullanılan Donanım Özellikleri:

• CPU: Intel(R) Core (TM) i7-4700MQ CPU 2.40GHz
• OS: Windows 7, 64-bit
• Memory: 32.0 GB (31.6 GB kullanılabilir)

DES (Data Encryption Standard)

Özellikle ödeme sistemlerinde hassas verilerin şifrelenmesinde kullanılan DES algoritmasının geçmişten günümüze hangi değişikliklere uğrayarak geliştiğine göz atalım.

DES in kısaca tarihçesinden bahsetmek gerekirse, 1970 lerin başında IBM tarafından geliştirilmiş; 1977 yılında NSA tarafından standart haline getirilmiştir. Single DES 64-bit uzunluğa sahip olmakla birlikte çalışma mantığı girdiyi 64-bit lik bloklara ayırıp 56-bit lik bir anahtarla şifrelemektir.

56-bit lik bir anahtar ile şifrelemesindeki kasıt 64-bit lik anahtarın sadece 56-bit inin şifrelemede kullanılmasıdır. Geri kalan 8-bit parity bit olarak tanımlanmaktadır. RSA Security tarafından 1997 yılında başlatılan 10.000$ ödüllü bir yarışmada DESCHALL project tarafından kırılıp güvensizliği ispatlanmıştır. Dolayısıyla günümüzde güvenli kabul edilmemektedir.

Algoritmanın ikinci etabındaki gelişme ise 2 adet DES anahtar ile arka arkaya girdiyi şifreleme mantığına sahip Double DES tir. Girdi 64-bit lik bloklara bölünür ve anahtar uzunluğunun 112-bit i şifreleme için kullanır. Ancak Meet-in-the-middle ataklarına karşı zafiyetinden dolayı 2⁵⁷ deneme ile kırılabilmektedir. Günümüzde kullanılmamaktadır.

IBM tarafından 1999 yılında geliştirilen Triple DES (3DES) ise meet-in-the-middle ataklarının önüne geçmiştir. 2 tanesi birbirinden farklı 64-bit lik toplamda 3 adet DES anahtar ile şifrelenmiş veriyi meet-in-the middle atağı ile yakalamak için 2¹¹² operasyon gerekmektedir. Ayrıca bu algoritmada 3 anahtarın da birbirinden farklı olduğu 3-length 3DES metodu da vardır. Ancak bu metot da Meet-in-the-middle ataklarına karşı 2¹¹² operasyonluk bir koruma sağlamaktadır. Genel olarak 2-length 3DES yerine 3-length 3DES metodunun kullanılma sebebi brute force ataklara karşı daha güvenilir olmasıdır.

Kaynaklar

https://crypto.stackexchange.com/questions/6345/why-is-triple-des-using-three-different-keys-vulnerable-to-a-meet-in-the-middle

https://www.pcisecuritystandards.org/documents/Cryptographic_Key_Blocks_Information_Supplement_June_2017.pdf

https://usa.visa.com/dam/VCOM/global/partner-with-us/documents/key-bundling-effective-date-change.pdf

https://www.nku.edu/~christensen/3DES.pdf

https://security.stackexchange.com/questions/165559/why-would-i-choose-sha-256-over-sha-512-for-a-ssl-tls-certificate

Onur Demir

DEEP SECURITY SANAL YAMA TEKNOLOJİSİ

Güvenlik mimarisini oluştururken en önemli nokta olarak sunucuları belirleriz. Önceliğimiz sunucu güvenliğini ve çalışabilirliğini sağlamak olur. Bu noktada Trend Micro Deep Security, birden fazla güvenlik tekniğini bir arada sunar. Güvenliğin dağıtımını ve yönetimini hızlı ve kolay hale getirir. Fiziksel, sanal ve bulut ortamlarda koruma sağlar. Mikro servis mimarileri ve Docker konteyner koruması sunarak gelişen veri merkezi teknolojilerini güvence altına alırken VMware, AWS ve Microsoft Azure gibi platformlarda entegre bir şekilde çalışmaya olanak tanır. Bu yazımda sizlere birçok farklı güvenlik modülünden oluşan Deep Security’nin Intrusion Prevention(Sanal Yama) özelleğinden bahsediyor olacağım.

Güvenlik AçığınınYaşam Döngüsü

Öncelikle güvenlik açığının yaşam döngüsüne değinelim. Güvenlik açıkları üretici, son kullanıcı veya güvenlik açığı aramaları gerçekleştiren kişiler tarafından tespit edilir. Bu açık ortaya çıktıntan sonra üretici desteği var ise ilgili yama için üretici bir takvim belirler. Yama yayınlandıktan sonra gerekli testleri uygulayarak yamayı canlı sistemlerimizde hayata geçiririz ve bir güvenlik açığının yaşam döngüsünü bu şekilde tamamlamış oluruz.

Üretici tarafından ilgili yama yayınlanıp sisteminize uygulanana kadar bilgisayarlar bu güvenlik açığına karşı savunmasız durumda kalır. Tam bu noktada Intrusion Prevention modülü, bilgisayarlarınızı bilinen ve sıfırıncı gün güvenlik açığı zafiyetlerinin yanı sıra SQL Injection, Cross-site Scripting Atacks ve web uygulamalarındaki güvenlik açıklarını da tespit eder ve koruma sağlar.

Sanal Yama Nasıl Çalışır?

Deep Security, belirlenen aralıklarda sunucular üzerinde taramalar gerçekleştirir. İşletim sistemini ve üzerinde uygulamaları tanımlayarak mevcut güvenlik açıklarını belirler. Belirlenen güvenlik açıklarını kapsayan ve üretici tarafından yayınlanan yama geçilmemiş ise güvenlik açığını engelleyecek olan kural ağ kartına eklenir. Eklenen kural ile eşleşen bir imza tespit edildiğinde bağlantı ağ seviyesinde sonlandırılır. Bu işleme Sanal Yama denir. Bu sayede yamanın yayınlanmasını beklemeden veya üreticinin desteğini çekmiş olduğu herhangi bir ürünle ilgili güvenlik açığı kapatılmış olur. Bir sonraki taramada sunucu üzerinde ilgili yamanın geçildiği tespit edilirse kural otomatik olarak kaldırılır.

Güvenlik açığı barındıran bir işletim sisteminde bu açığı sömürmek için farklı yöntemler ile ataklar gerçekleştirdiğimizde, bu ataklara karşı Deep Security’nin vermiş olduğu tepkileri ve özetlerini aşağıdaki ekranda inceleyebiliriz.

Zero Day Initiative

Deep Security’nin, güvenlik açığı tespiti noktasında beslendiği en önemli kaynaklardan birisi Zero Day Initiative’dır. 2005 yılında oluşturulan ZDI ekibi, yazılımların güvenlik açıklarını tespit eden ve üreticilere ileten bir oluşumdur. Tespit edilen güvenlik açığı tüm detayları ile üreticisine aktarılırken, kullanıcılara ise filtrelenmiş genel bir bilgilendirme yayınlanır. Eş zamanlı olarak güvenlik açığını kapsayan ve gerekli korumayı sağlayacak olan Rule Set, üreticinin yamayı yayınlaması beklemenden Deep Security’ye eklenir. Artık sunucular bu zafiyete karşı koruma altındadır.

Analysis of the Global Public Vulnerability Research Market 2017 raporuna göre açıklanan her üç kritik güvenlik açığından ikisinin ZDI ekibi tarafından ortaya çıkarıldığı belirtilmektedir.

Aşağıdaki görselde Microsoft ile ilgili tespit edilen ve bu güvenlik açıklarını Microsoft’a iletilen üreticileri görmekteyiz.

Günümüzde artık ağları Trust-Untrust olarak tanımlayamıyoruz. Sadece dış ağlardan gelen trafiği izlemek ve ağ güvenlik duvarlarındaki IPS modülleriyle güvenliği sağlamak mümkün olmuyor. İç ağda veya DMZ’te barındırdığımız sunucularda Host Based IPS konumlandırmamız sunucu güvenliğinde son derece fayda sağlamaktadır.

Kaynaklar

https://www.trendmicro.com/tr_tr/business/products/hybrid-cloud/deep-security.html

https://www.zerodayinitiative.com/

Serhat Güçtekin

CYBERARK APPLICATION ACCESS MANAGER İLE UYGULAMA HESAPLARININ YÖNETİMİ

CyberArk, herhangi bir sistem üzerindeki ayrıcalıklı hesapların (Privileged Accounts), özelleştirilebilen politikalar aracılığıyla yönetim ve denetimini sağlayan “Ayrıcalıklı Erişim Güvenliği-Privileged Access Security (PAS)” platformudur . Bu kapsamda, kritik sistem erişimlerini kontrol eder,yönetir, izler ve  ayrıcalıklı hesapların parola yönetiminin otomatik yapılmasına olanak sağlar. CyberArk’ın güvenli kasa (vault) yapısında tutulan ayrıcalıklı hesapların kimlik bilgilerine erişim, kullanıcıların yetkileri çerçevesinde mümkündür. Yetkili kullanıcı CyberArk sistemine giriş yaparak, yetkisi dahilindeki ayrıcalıklı hesaplar ile -hesapların parolasını bilmese dahi- hedef sistemlere kontrollü bir şekilde erişir. Hedef sistem erişimi CyberArk üzerinden gerçekleşeceği için ayrıcalıklı hesabın hash bilgisi bağlantı kurulan sunucuda kalmaz, dolayısıyla “Golden Ticket” ve “Pass the Hass” gibi atakların önüne geçilmiş olur.

Ayrıcalıklı hesap kavramı akıllara öncelikle Windows, Linux vb işletim sistemlerindeki kullanıcı hesaplarını getirse de, bu kavram gerçekte çok daha fazlasını ifade etmektedir. Database(veritabanı), network, güvenlik cihazı, çeşitli uygulama ve programlarda yer alan ve bulundukları sistem üzerinde oturum açma ve değişiklik yapma hakkına sahip olan hesaplar ayrıcalıklı hesap olarak adlandırılmaktadır. Bahsi geçen bu sistemlere ait hesapların bir çoğu CyberArk CorePAS yapısı ile yönetilir ve güvenli erişim sağlanır. Ancak uygulamalarda, yapılandırma dosyalarında veya komut dosyalarında yer alan ayrıcalıklı hesaplar CorePAS platformu ile tam anlamıyla korunamamaktadır.Bu hesaplara ait kimlik bilgilerinin CyberArk’ın güvenli kasasında tutulması ve yönetilmesi için CyberArk Application Access Management (AAM) modülüne ihtiyaç vardır.

 Sistemler üzerinde, hassas bilgileri beslemek, depolamak ve almak için veritabanlarına erişmesi gereken birden fazla komut dosyası ve uygulama vardır. Bu veritabanlarına erişmek için, veriler üzerinde okuma ve/veya yazma hakkına sahip hesaplar kullanılmaktadır. Uygulama hesaplarına ait kimlik bilgileri,  uygulama kodunda gömülü biçimde (hard-coded) tutuluyor olabilir veya herkes tarafından okunabilir şekilde saklanıyor olabilir.Her iki koşulda da bu durum bir güvenlik açığıdır. Sabit kodlanmış parolalar, parola değişimini sınırlar, statik ve kalıcı hale getirir. Örneğin bir veritabanı hesabının parolasını değiştirmek için aynı veritabanını kullanan tüm uygulamalarda şifreyi elle değiştirmek gerekir. Buna uygulama kodu, derleme(compilation) ve kodun içerisindeki değişiklikler de dahildir.Bu işlemlerin elle yapılması zaman alacağından sistemde kesinti meydana gelecektir. Kritik sistemler ve uygulamalarda kesinti istenmeyen bir durumdur, dolayısıyla parola değişikliği mümkün olduğunca yapılmaz veya yılda bir kez gibi uzun süreli periyotlar ile gerçekleştirilir. Uygulama geliştiriciler, sistem yöneticileri ve uygulama danışmanları bu parolaları biliyor olurlar ve işten ayrılmaları, bölüm değiştirmeleri vb durumlar düşünüldüğünde riskin büyüklüğü ortaya çıkar.

Veritabanları, uygulamalar, servisler, konfigurasyon ve komut dosyaları… sistemimizin her noktasında ayrıcalıklı hesaplara rastlamak mümkün. Bu durum düşünüldüğünde akıllara “hangi uygulama hangi hesabı kullanıyor?”, “hangi uygulamalar, ne tür hesaplar ile nerelere erişebiliyor?”, “geliştiriciler ve uygulama sorumluları bu hesapların güvenliğini sağlayabiliyor mu?”, “bu hesapların parolalarının biliniyor olması risk oluşturuyor mu?” gibi sorular geliyor. Regulasyonlar gereği, uygulamalar etkinleşmeden veya müşteriye devredilmeden önce uygulama hesaplarının kimlik bilgileri kaldırılmalı, hassas veriler açıklanmamalı, güvenlik ihlallerine neden olabilecek hatalı kodlamalar gözden geçirilmeli ve doğru adresleme yapılmalıdır. CyberArk’ın AAM Credential Providers çözümü, uygulamalarda, komut dosyalarında veya yapılandırma dosyalarında parolaların, koda gömülü olarak saklanma ihtiyacını ortadan kaldırır ve vault üzerinde merkezi olarak tutulmasına ve CyberArk ile yönetilmesine izin verir. Böylece, parola yönetimi CyberArk üzerinde belirlenen politikalar ile otomatik olarak ve uygulamada herhangi bir kesinti olmadan gerçekleşir.Tüm sistemler, veritabanları ve uygulamalar arasındaki erişim güvenli bir şekilde sağlanır.

               CyberArk AAM Credential Providers modülünü Credential Provider, Application Server Credential Provider ve Central Credential Provider olarak 3 başlıkta inceleyebiliriz.

               Credential Provider (CP):            

               Uygulama sunucusuna, sunucunun işletim sistemine uygun credential provider ajanı kurularak, vault üzerinde tutulan uygulama hesaplarının kimlik bilgilerine kontrollü ve sürekli erişim sağlanır. CP, yerel önbelleğinde uygulama hesaplarına ait kimlik bilgilerini tutar ve uygulama Password SDK (Software Development Kit)  ile parolayı  istediğinde, credential provider uygulanamanın yetkili olup olmadığını kontrol ederek, bu isteği yanıtlar. CyberArk PAS modülleri ile senkronize bir şekilde çalışır, böylece parolaların doğruluğundan emin olur. CyberArk tarafından uygulama hesabının parolası değiştirildiğinde, CP kendi önbelleğini günceller. Vault ile CP arasında ağ bağlantısında kesinti olması durumunda CP, önbelleğindeki bilgiyi kullanarak uygulamaya yanıt verir, dolayısıyla kesintisiz, %100 kullanılabilirlik sağlanmış olur. Bu durum performans açısından da etkilidir, her istek için vault’a gidilmez ve önbellekteki bilgi kullanılarak daha hızlı yanıt verilmesi sağlanır.

Vaulta erişebilen CP ‘lerin sayısına göre lisanslama yapılır. PrivateArk client üzerinde, CP ajanının uygulama sunucusuna kurulmasıyla “Prov_sunucuadı” olarak isimlendirilen  “AIMAccount” kullanıcı tipindeki kullanıcılar oluşur. Bu Prov kullanıcıları uygulama hesaplarının kimlik bilgilerini alabilmek için uygulama hesaplarının tutulduğu kasada yetkilendirilmelidir. Uygulama sunucusunda yer alan farklı uygulamar için tek bir CP ajanı kullanılabilir bu sayede uygulama sunucu sayısına göre CP ajanı gereksinimi ortaya çıkarılabilir. Özel uygulamalar için ayrı lisanslama gereksinimleri olabliyor, yapınıza uygun, doğru bilgiye ulaşmak için bizimle iletişime geçebilirsiniz.

Application Server Credential Provider (ASCP):

J2EE uygulama sunucuları “data source” tanımlarıyla çalıştırdıkları uygulamalar için veritabanı bağlantıları başlatır. Bu bağlantılarda kullanılan hesaplar, uygulama sunucu üzerinde çoğunlukla XML formatında tutulan dosyalarda saklanmaktadır. Uygulama geliştirici veya uygulamanın kendisi doğrudan bir hesap bilgisi kullanmıyor olsa da bu hesapların dosya sistemi üzerinde saklanması bahsettiğimiz sebepler nedeniyle yine parola yönetimini güçleştirmektedir.

ASCP modülü, JDBC Driver Proxy Model ve Credential Mapper Modelleri ile IBMWebShere, Oracle Weblogic, Jboss ve Apache Tomcat gibi uygulama sunucularında yer alan gömülü kimlik bilgilerini ortadan kaldırmayı amaçlar. ASCP uygulama sunucunun kullanabileceği güvenli bir JDBC yapısı sağlayarak, kod üzerinde herhangi bir değişiklik yapılmadan kimlik bilgilerinin alınmasını sağlar.

Windows servislerde veya scheduled task ‘larda yer alan servis hesaplarını kaldırmak mümkün değildir. Bu nedenle CyberArk bu sistemlerde yer alan hesaplara ait parolaların mümkün olduğunca sık değiştirilmesini önerir ve alternatif bir yol olarak “pushed” metodunu sunar. Bu yöntem ile kimlik bilgileri değiştiğinde her seferinde yeni kimlik bilgileri uygulamaların kimlik bilgilerini okuduğu konumlara “aktarılır”.

Central Credential Provider (CCP):

IIS sunucusuna kurulan CCP, çalışma sırasında uygulamalara kimlik bilgisi sağlamak için RestAPI kullanır.  Farklı lokasyonlarda yer alan uygulamalar,  web servis çağrılarını kullanılarak bu parolalara CCP üzerinden erişebilirler.

Kimlik bilgilerinin doğru uygulamalara aktarılabilmesi için Vaultta yer alan uygulama ayrıntılarının, parola isteği yapan uygulama ile eşleşip eşleşmediği kontrol edilir. Windows Domain OS kullanıcısı veya uygulamanın çalıştığı sunucu adresi gibi tüm ölçütler karşılanıyorsa CCP vaulttan parolayı alır ve uygulamaya iletir. Erişim denetimi sayesinde bu uygulamanın diğer hesaplara ait kimlik bilgilerine erişiminin önüne geçilir. Böylece, yalnızca yetkili uygulama, o uygulama ile ilişkili hesaba ait kimlik bilgilerini CCP’den web servis çağrıları ile alabilir. CCP,vault ile senkronize çalışarak önbelleğini sürekli olarak yeniler ve her zaman doğru bilgi iletilmesini sağlar. CCP sunucu sayısına göre lisanslama yapıldığı için (her bir CCP sunucusu 1 lisans demektir), farklı lokasyonlardaki uygulamaları tek merkezden daha az maliyetle yönetebilirsiniz.

Aşağıdaki görselde, her lokasyonda ayrı CCP sunucusu konumlandırılmış olup, uygulama sunucuları ve vault ile CCP arasındaki iletişim gösterilmiştir.

Yüksek düzeyde kullanılabilirlik, performans ve güvenlik gerektiren uygulamalarda CP kullanılması, çok kritik olmayan uygulamarda ve her bir uygulama sunucusuna ajan kurulması mümkün olmayan durumlarda ise CCP kullanılması önerilmektedir. Merkezi bir IIS sunusuna kurulan CCP’den daha iyi performans almak için birden fazla CCP konumlandırılarak “Load Balancer” arkasına alınabilir.

Ayrıntılı bilgi almak isterseniz aşağıdaki linki inceleyebilirsiniz.

https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-CP/Latest/en/Content/Resources/_TopNav/cc_Home.htm

Kaynaklar

https://docs.cyberark.com

https://www.beyondtrust.com/resources/glossary/privileged-access-management-pam

https://www.pcisecuritystandards.org/

https://www.mas.gov.sg/

Çağla DEMİR SICAKYÜZ