Ürün Yöneticileri İçin Temel Veri Güvenliği Rehberi

Code Spaces'i duydunuz mu? Github'a benzer bir kaynak kodu deposuydu.

Muhtemelen onları daha önce hiç duymadınız çünkü umut vadeden bir ürün olmalarına rağmen, büyük bir güvenlik ihlalinin ardından Haziran 2014'te neredeyse anında ortadan kayboldular. İhlal, tüm müşteri verilerini kaybetmelerine ve faaliyetlerini durdurmak zorunda kalmalarına neden oldu.

Bu olaydan sonra ürün yöneticileri de dahil olmak üzere dijital dünyadaki herkes, asla unutulmaması gereken bir ders aldı—ÜRÜNLER GÜVENLİ OLMALIDIR.

Bu rehberde sizi ürün güvenliği dünyasıyla tanıştıracak ve ürünlerinizi yönetirken güvenliği göz önünde bulundurmanıza yardımcı olacağım.

Ürün Yöneticileri Veri Güvenliğini Neden Önemsemeli?

Teorik olarak, günlük ürün yönetimi çalışmalarınız güvenlik konusunda endişelenmeden yalnızca elde tutma, kullanıcı görüşmeleri ve diğer teknik olmayan konulara odaklanmalıdır.

Ancak kötü niyetli amaçları olan kötü insanların bulunduğu bir dünyada yaşıyoruz. Bu kişiler verilerinizi çalmaktan (daha sonra bir yerde satmak için), şifrelemekten, karşılığında fidye talep etmekten (diğer adıyla fidye yazılımı) veya yalnızca zarar vermek için zarar vermekten fazlasıyla memnuniyet duyabilir.

Bu nedenle aktivasyon ve elde tutmanın yanı sıra, zayıf güvenliğin ürününüz için oluşturabileceği büyük iş riskini de önemsemelisiniz. Yeterince ciddi bir güvenlik ihlali itibarınıza o kadar büyük zarar verir ki pazarlama, ürün geliştirme ve satış ekiplerinizin yıllarca süren yoğun çalışmaları tek bir günde yok olabilir.

Ayrıca, verilerini koruyamadığınız ortaklarınız ve müşterileriniz tarafından açılacak hukuki davalarla karşı karşıya kalabilirsiniz.

Bu nedenle, bence ürün yöneticilerinin ürünlerini oluştururken ve büyütürken “güvenlik bilincine sahip” olmaları son derece önemlidir.

Ürün Geliştirmedeki En Yaygın 4 Güvenlik Açığı

Bir ürün yöneticisi olarak en güncel bilgisayar korsanlığı yöntemleri ve bunlardan korunma yolları hakkında derinlemesine bilgi sahibi olmanız gerçekten gerekmez. Bunlar, güvenlik ve mühendislik ekiplerinizin uygulayıp yönetmesi gereken konulardır.

Ancak en yaygın güvenlik sorunlarından bazılarının nasıl çalıştığı ve bilgisayar korsanlarının bunlardan nasıl yararlanabileceği hakkında temel bir teknik anlayışa sahip olmanız gerekir. Bu, karar verme sürecinizi “güvenlik bilincine sahip” hale getirecektir.

Şimdi bu tür dört güvenlik açığını birlikte inceleyelim ve neyle ilgili olduklarını anlayalım.

1. SQL Enjeksiyonu

Genç bir ürün yöneticisiyken biraz kodlama öğrenmeye karar verdim ve bir web sitesindeki iletişim formunun arka ucu olarak çalışan küçük (ve berbat) bir PHP kodu yazdım. Bu kod bir mesaj alıyor, mesajı veritabanında saklıyor ve içeriğiyle birlikte bana gönderilmek üzere bir e-posta oluşturuyordu.

Bunu geliştirici bir arkadaşıma gösterdiğimde, eğlencesini zar zor bastırmasının (kodum gerçekten de inanılmaz derecede kötüydü) yanı sıra girdilerimi temizleyip temizlemediğimi sordu. Tahmin edebileceğiniz gibi ne demek istediği hakkında hiçbir fikrim yoktu. Bana, girdiler temizlenmeden veritabanlarımın SQL enjeksiyonuna açık olduğunu açıkladı.

SQL enjeksiyonu, bilgisayar korsanının girdilerinize metin yerine özel SQL kodu yazması ve sonunda bu kodun arka uçta çalıştırılarak ürününüze yetkisiz erişim elde edilmesi veya veritabanlarınızdaki bilgilerin çalınması sürecidir.

Giriş yaparken parolanızı kontrol etmek için LinkedIn'in bu SQL sorgusunu kullandığını düşünün (uyarı: kesinlikle buradaki SQL'den daha akıllı bir şey kullanıyorlardır).

Teorik olarak giriş sayfasındaki girdiler temizlenmemiş olsaydı, kullanıcı adı ve parola alanlarına ' OR '1'='1 yazıp Giriş Yap düğmesine basabilirdiniz.

Bu durumda arka uç, ' OR '1'='1 ifadenizi SQL sorgusuna ekler ve sorgu buna benzer bir hale gelirdi.

Bu sorgu “true” değerini döndürür. Bu da gerçek bir kullanıcı adı ve parolaya sahip olmadan LinkedIn'e giriş yapabileceğiniz anlamına gelir.

Daha önce de belirttiğim gibi, girdilerinizi temizleyerek bu sorunu önleyebilirsiniz. Bu bağlamda temizleme, giriş alanlarına yazdığınız her şeyin, kod veya SQL sorgusu yazsanız bile sıradan metin olarak ele alınmasını sağlamak anlamına gelir.

Girdiler temizlendiğinde LinkedIn, kodu çalıştırmak yerine veritabanında ' OR '1'='1 adlı bir kullanıcı aramayı deneyecektir. Sonunda bu kullanıcıyı bulamayacak ve LinkedIn'de böyle bir kişinin bulunmadığını belirten bir hata mesajı gösterecektir.

Not

Elbette, yukarıdaki örnek basitleştirilmiş bir örnektir ve gerçek hayattaki siber saldırılar çok daha karmaşıktır. Ancak teknik ayrıntılara inmek ve bu saldırılar hakkında daha fazla bilgi edinmek istiyorsanız, Justin Clarke-Salt’ın SQL Enjeksiyonu Saldırıları ve Savunma kitabına göz atmanızı öneririm.

Kendinizi SQL enjeksiyonlarından korumak, müşterilerinizin verilerini güvende tutmak, zararlı veri sızıntılarını ve yetkisiz erişimleri önlemek için atabileceğiniz temel adımlardan biridir.

2. Siteler Arası Betik Çalıştırma (XSS)

XSS, bilgisayar korsanlarının ürününüzü manipüle ederek kötü niyetli eylemlerde bulunmasının bir başka yaygın yoludur. XSS’nin ne kadar yaygın olduğunu anlamak için Positive Technologies raporuna göre, internetteki web uygulamalarının yaklaşık %90’ı bu tür saldırılara karşı savunmasızdır.

Peki bu saldırı tam olarak nedir? XSS, bilgisayar korsanlarının sisteminizi olmaması gereken kodları çalıştıracak şekilde manipüle etmesi açısından SQL enjeksiyonuna biraz benzer. Ancak bu durumda çalıştırılan kötü amaçlı kod sisteminizin arka ucunda/veritabanlarında değil, ön yüzünde bulunur.

XSS’nin eğlenceli ve zararsız örneklerinden biri, Twitter’ın (evet, hâlâ Twitter diyorum—isterseniz bununla ilgili benimle tartışın) kendi kendini retweetleyen kalp emojisi olayıdır. Eğlenceliydi, çünkü hiç kimse Twitter’ın bu kadar büyük bir hata yapmasını beklemiyordu; zararsızdı, çünkü yaptığı tek şey kendi kendini retweetlemekti.

Bu saldırı, aşağıdaki metni içeren basit bir tweet’ten ibaretti.

Görselden de anlaşılacağı üzere bu, basit bir metin değil; sonunda bir kalp emojisi bulunan bir kod parçasıdır (daha kesin ifade etmek gerekirse jQuery içeren JavaScript kodu).

Twitter bu güvenlik açığını düzeltmeden önce, bu tweet’i tarayıcınızda açarsanız tarayıcının motoru içeriği geçerli bir kod olarak tanır, kullanıcıdan gizler ve çalıştırırdı. Böylece iki satır kod yerine yalnızca kalp emojisi bulunan bir tweet görürdünüz.

Kod çalıştığında sayfanın HTML’i içinde gezinir, ekranınızdaki retweet düğmesini otomatik olarak bulur ve ona tıklardı.

Bu da bu tweet’i görüntüleyen herkesin onu otomatik olarak retweetlemesi ve Twitter kullanıcılarının büyük bir bölümünün bu saldırıdan etkilenmesi anlamına geliyordu.

Şimdi bunun kendi kendini çoğaltan bir tweet değil, ekranınızdaki gizli bilgileri toplayıp bilgisayar korsanına gönderen bir betik gibi daha zararlı bir şey olduğunu düşünün. Alternatif olarak, tarayıcınızdaki kötü amaçlı bir kod internet bankacılığı web uygulamanızı ele geçirip hesabınızdan para transfer etmeye başlayabilirdi.

Ne demek istediğimi anladınız—XSS, sunucularınıza ve veritabanlarınıza erişemese bile hâlâ son derece tehlikelidir.

Peki bunun bir ürün yöneticisi olarak sizinle ne ilgisi var? Mühendislerinizden, web sitenizin kullanıcının tarayıcısındaki diğer sekmelerin içeriğini görmesini ve bu bilgilerle ilginç bir şeyler yapmasını sağlayan özellikler ve entegrasyonlar gibi harika işlevler geliştirmenizi istemeniz mümkündür.

Böyle bir istekte bulunur ve ekibiniz bu özelliği geliştirmeyi reddederse şaşırmayın veya üzülmeyin; çünkü istediğiniz şey temelde diğer sitelere yönelik bir XSS saldırısıdır.

XSS, siber güvenlikte büyüleyici bir alandır ve bu konuda önerebileceğim pek çok harika kitap vardır. Favorim, Seth Fogie’nin XSS Saldırıları kitabıdır.

3. Güvensiz API’ler

Uygulama Programlama Arayüzleri (diğer adıyla API’ler), sunucunuz ile kullanıcıların tarayıcısı veya mobil cihazlarında/masaüstü bilgisayarlarında çalışan uygulamanız arasındaki iletişim araçlarıdır.

Sunucunuzdaki verileri alma, depolama veya işleme ihtiyacı olduğunda tarayıcı/uygulama (diğer adıyla "istemciler"), gerekli bilgilerle birlikte sunucuya bir istek gönderir. Ardından sunucu işlemi gerçekleştirir ve yanıtı gönderir.

Örneğin oturum açarken istemciler kullanıcı adınızı ve parolanızı göndererek sunucudan kimliğinizi doğrulamasını ister. Sunucu isteği tamamlar tamamlamaz, oturum açma işlemi tamamlandığında kullanıcının görmesi gereken sayfa içeriğiyle birlikte bir “başarılı” mesajı gönderir.

API’ler kullanıcı verileriyle çalıştığı için, kötü amaçlı veri manipülasyonuna (örneğin sunucudan kullanıcı adına para transferi yapmasını istemek) veya veri ihlaline (örneğin sunucudan kullanıcının tıbbi kayıtlarını açıklamasını istemek) yol açabilecek güvenlik açıklarına da yatkındır.

En yaygın API güvenlik açığı türleri şunlardır:

Kimlik doğrulama yok: Bu durumda API, gizli bilgileri sağlamadan önce istemcinin kimliğini kanıtlamasını gerektirmez. Bunun nasıl çalıştığını anlamak için birinin bankaya gidip Mark Zuckerberk’in hesabından para çekmek istediğini söylediğini ve veznedarın da "Elbette, ne kadar?" diye yanıt verdiğini düşünün.

Hız sınırlaması yok: Burada API'ler, çok fazla istek olsa bile (hatta olması gerekenden çok daha fazla olsa bile) istekleri işlemeyi durdurmaz; bu da sunucunuzun aşırı yüklenmesine ve devre dışı kalmasına yol açar. Bu tür aşırı istek yağmuru, biri sunucularınıza DDoS saldırısı düzenlemeye çalıştığında gerçekleşir.

Aşırı veri ifşası: Bu, API yanıtlarınızın insanların gerçekten erişmesini istemediğiniz bilgileri içermesi durumudur. Örneğin, internet bankacılığı üzerinden birine para gönderdiğinizi düşünelim; işlemin başarılı olduğunu bildiren API bildirimi, alıcının hesap bakiyesini de içeriyor olabilir. Oysa bu, kesinlikle görmemeniz gereken bir şeydir.

Bu üç güvenlik açığının çözümleri oldukça açık. Hassas verileri sunarken kimlik doğrulaması isteyin, hız sınırlaması ekleyin ve orada olmaması gereken verileri sunmadığınızdan emin olun.

API güvenliğini biraz daha derinlemesine incelemek isterseniz, bu konudaki Neil Madden’ın kitabına göz atabilirsiniz.

4. Şifreleme Eksikliği

Güvenlik yöneticim, bir ürün için iyi uygulanmış bir siber güvenlik stratejisinin soğana benzediğini sürekli tekrarlamayı seviyor: Ürünün farklı bölümlerinde birden fazla güvenlik katmanından oluşur.

Şimdiye kadar tartıştığımız her şey, kullanıcının sunucularınıza veya veritabanlarınıza erişemediği ve “yüzeyden” saldırmaya çalıştığı yüzey katmanındaki güvenlik riskleriydi.

Ancak bir bilgisayar korsanı bir şekilde sunucularınıza tam erişim elde ederse (ilk katmanı aşarsa), veritabanlarınızı yetkisiz erişimlerinden korumak için yine de önlemleriniz olmalıdır; böylece iç katmanlarınızı da güvenli tutabilirsiniz.

Bu durumda verilerinizi korumanın en iyi yollarından biri onları şifrelemektir. Bu, biri veritabanlarınıza erişip bu verileri indirse bile verilerin şifrelenmiş olması nedeniyle onlar için anlamsız bir karakter dizisinden ibaret olacağı anlamına gelir.

Şifreleme anahtarına sahip iki taraf olan şirket veya kullanıcı, bu anlamsız karakter dizisini yararlı bilgilere dönüştürerek çözebilecek tek kişiler olacaktır. Ancak ne yazık ki sunuculardaki verileri şifrelemeyi unutmak son derece yaygındır ve çok sayıda büyük veri sızıntısına yol açmıştır.

Kullanıcılarının parolalarını düz metin olarak saklayarak şansını zorlayan çok fazla web sitesi ve ürün gördüm; bu, yazılım dünyasında ölümcül bir günah olarak kabul edilir. Bu durum için en iyi uygulama, parolayı bir karma algoritmasından geçirmek, şifrelenmiş bir sürümünü (karma olarak adlandırılır) elde etmek ve bunun yerine onu saklamaktır.

Bunun güzel yanı, hem kullanıcının hem de şirketin karmayı düz metin biçimine geri döndürmek ve bu parolayı kimlik doğrulama için kullanmak üzere anahtara sahip olmasıdır. Ancak bir bilgisayar korsanı veritabanına erişip karmayı indirirse, anahtar olmadan onu tekrar orijinal parolaya dönüştürmek milyonlarca yıllık hesaplama gerektirir. (Şaka yapmıyorum, gerçek sayı bu!)

Şifreleme, siber güvenlikte ayrıca büyüleyici bir alandır ve incelemenizi tavsiye ederim. Özellikle, tüm internetin artık üzerine kurulu olduğu Açık Anahtarlı Şifrelemenin nasıl çalıştığını öğrenerek başlayabilirsiniz.

Uygulama Güvenliğini Ürün ve Yazılım Geliştirme Yaşam Döngüsüne Entegre Etme

Tüm bu güvenlik açıklarını ve en iyi uygulamaları göz önünde bulundurarak, aklınıza gelebilecek açık bir soruya odaklanalım—bir ürün yöneticisi olarak ürünlerimi nasıl güvende tutarım?

Bunu asla sormayacağını sanmıştım! İşte bu konuda size yardımcı olabilecek iki önemli güvenlik en iyi uygulaması:

Tasarım Gereği Güvenli Ürünler

Bu, ürünlerinizi geliştirmeye başladığınız andan itibaren güvenlik gereksinimlerini göz önünde bulundurmanız gerektiğini söyleyen bir geliştirme süreci yaklaşımıdır. Böylece güvenlik önlemleri, SDLC içinde sonradan eklenmek yerine kodunuza ve mimarinize yerleşik olarak entegre edilir.

İkincisi genellikle çok daha pahalıdır ve “yerleşik olarak” güvenli yazılımla aynı düzeyde koruma sağlamaz.

Bu nedenle bir ürün yöneticisi olarak, geliştirme ekibinizden bu yaklaşımı izlemesini istemek ve güvenliği ürüne yerleştirmeye yardımcı olan maddelerin önceliğini düşürmekten kaçınmak sizin sorumluluğunuzdur.

Düzenli Güvenlik Denetimleri

Yönettiğim ürünlerin çoğu düzenli güvenlik testlerinden geçiyordu (genellikle altı ayda bir veya yılda bir). Tüm güvenlik durumunu test ettik ve bunlar şunları içeriyordu:

• Sızma testi
• Tehdit modelleme
• Güvenlik kontrollerinin incelenmesi
• Güvenlik stratejisinin ve güvenlik özelliklerinin incelenmesi
• Tedarik zincirinin ve otomasyon iş akışlarının incelenmesi
• Kod analizi (kullandığımız açık kaynak kodlar ve üçüncü taraf iş ortaklıklarından edindiğimiz kodlar dahil)
• Güvenlik yol haritası ve ölçümlerinin oluşturulması
• Risk değerlendirmesi
• ...ve daha fazlası!

Bu önemlidir; çünkü ürününüz sürekli gelişir ve yeni bir şey eklerken yazılım güvenliğinizi yanlışlıkla tehlikeye atabilirsiniz. Düzenli denetimler bu sorunları hızla tespit etmenizi, kötü niyetli bir kişi bunları sizden önce bulmadan önce düzeltip doğrulamanızı sağlar.

Ürün yöneticisi olarak göreviniz, bu denetimler ve bunların ardından yapılacak kod temizlemeleri için zaman ayırmak ve bunlara öncelik vermektir.

Güvenlik Ekibinize Güvenin

Hangi özelliği geliştirmeyi planlıyor olursanız olun ve büyüme hedeflerinize ulaşmak için hangi eylem planına sahip olursanız olun, fikirlerinizi güvenlik ekibinizle mutlaka değerlendirdiğinizden emin olun.

Bir de dinleyin—güvenlik ekibinizin ürününüzü “aşırı güvenli” hale getirmenizi istediğini düşünebilirsiniz. Ancak çoğu zaman fikrinizi beğenmiyorlarsa, üzerinde değişiklik yapmayı düşünmelisiniz. Aksi takdirde riske girmeye değmez.

Ayrıca bir şeyleri değerlendirme konusuna değinmişken, çok sayıda ürün yönetimi rehberini ve makalesini doğrudan gelen kutunuza almak için bültenimize abone olmayı da düşünün!