Bu yazıda, Bulut Bilişim risk değerlendirmesi kapsamında belirlenen toplamda 7 riskten, ilk bölüm olan Bulut Bilişim Risk Değerlendirmesi - I adlı yazıda incelenen 3 riskin devamında, kalan diğer riskler ayrıntılı olarak incelenecektir.

Risk 4 – Hizmet Sağlayıcı Bağımlılığı ve Veri Kilitlenmesi

Bir Bulut Bilişim hizmet sağlayıcısından diğerine geçiş yapmak istenmesi durumunda, Bulut Bilişim hizmet sağlayıcılarının; yazılım programlama ara yüzlerini (API) istenen seviyede standartlaştırmamış olmaları, verilerin hizmet sağlayıcılara özel veritabanı şemalarında tutulmaları gibi sebeplerle, veri ve yazılımların taşınmasında büyük zorluklarla karşılaşılmaktadır. Bunun sonucu olarak şirketlerin, Bulut Bilişim hizmet sağlayıcılarına bir anlamda bağımlı durumuna geldikleri görülmektedir. Bu bağımlılık farklı hizmet modelleri için, farklı şekillerde olabilmektedir. Bir Servis olarak Yazılım (“SaaS”) modelinde, şirket verilerinin hizmet sağlayıcının tasarladığı özel bir veri tabanının şemasında saklanması, verinin taşınmasını güçleştirirken; belirli alanda uzmanlaşmış uygulamaların bulunması, şirketlerin uygulama değiştirmelerini zorlaştırmaktadır. Servis olarak Platform (“PaaS”) modelinde ise, şirketler hizmet sağlayıcıların yazılım geliştirme ara yüzlerine (“API”) ve bileşenlerine bağımlı hale gelirlerken, Servis olarak Altyapı modelinde (“IaaS”) ise, kullanılan donanımsal kaynaklara bağımlı hale geldikleri görülmektedir [1].

Bir Bulut Bilişim hizmet sağlayıcısına, depolanan veri ve kullanılan uygulamalar dolayısıyla bağımlı olmak, uygulanan fiyat politikalarına karşı esnek olamamaya, hizmet sağlayıcısının mimarisinde var olabilecek açıklık ve zayıflıklar sonucu oluşabilecek arıza ve saldırılardan dolayı veri kaybına uğramaya sebebiyet verebilir. Ayrıca, bir Bulut Bilişim hizmet sağlayıcısının bir diğeri tarafından satın alınması sonrasında gerçekleşebilecek olan hizmet veya kullanım şartnamesi değişiklikleri, şirketleri zora sokabileceği gibi; bir hizmet sağlayıcının yaşadığı teknik ve ekonomik zorluklar sonucu batması, hizmet alan şirketlerin büyük veri ve itibar kaybına uğramalarına neden olabilir. Her ne kadar bu zor bir ihtimal olarak görülse de, Linkup adlı çevrim içi veri depolama hizmetinin, 8 Ağustos 2008 tarihinde, müşteri verilerinin %45’ini kaybettikten sonra batması bu riskin var olduğuna örnek olarak verilebilir [6].

Risk 5 – Yönetim Ara yüzü ve Uzaktan Erişim

Bulut Bilişim hizmet sağlayıcıların kullanıcılarının hizmetlerini yönettikleri ara yüzler, internet üzerinden erişilebilir olmaları ve geniş yönetim imkânları barındırmaları sebebiyle, internet tarayıcıların ve uzaktan erişimin zayıflıkları düşünüldüğünde, yüksek güvenlik riski taşımaktadırlar. Uzaktan erişim sırasında, saldırganlar tarafından koklama (“sniffing”), yanıltma (“spoofing”) ve araya girme (“man-in-the-middle”) gibi saldırı yöntemleri kullanarak, iletişimin ve taşınan verinin dinlenmesi, kullanıcı oturumunun elde edilmesi ve kullanıcı şifrelerinin çalınması mümkün olabilmektedir [1]. Eğer saldırgan kullanıcı şifre ve bilgilerini ele geçirirse, yapılan işlemleri izleyebilir, verileri silebilir, veriler üzerinde oynayabilir, hatalı veri döndürülmesine sebep olabilir ve hatta müşterileri zararlı sitelere yönlendirebilir. Ayrıca saldırgan, ele geçirdiği kullanıcı hesabını veya kullanılan hizmetleri, daha ileri ve geniş saldırılar yapmak için bir merkez olarak kullanıp, kullanıcıya duyulan güveni ve kullanıcının itibarını kullanarak, başka kişiler ve Bulut Bilişim hizmet sağlayıcısını da etkileyebilecek daha büyük saldırılar gerçekleştirebilmektedir [11].

Bulut Bilişim hizmet sağlayıcılar tarafından, bulut temelli güvenlik modeli oluşturulmasına başlanıp, Bulut Bilişim kullanıcılarının anti virüs ve güvenlik yazılımları kurmasına gerek bırakmayan, Bulut-içi (”in-the-cloud”) tarama hizmetleri başlatıldı. Bu sayede, bulut kullanıcılarının zararlı yazılımlara, sistemdeki açık kapılara (“loophole”), zayıflıklara ve araya girme (“man-in-the-middle”) saldırılarına karşı korunmasına, bulut içindeki saldırıların engellenmesine çalışılmaktadır [12].

Risk 6 – Bant Genişliği ve Veri Transferi

Bulut Bilişim’in temelinde yatan ana fikirlerden biri olan, kullanıcıların veri işleme ve saklama faaliyetlerinden arındırılıp, verilerin merkezi bir Bulut içine toplanması ve buradan gerekli işlemlerin yapılabilmesi fikri, uygulamaların giderek daha yoğun veri kullanmaya başlamasıyla, verilerin kullanıcıdan Bulut Bilişim hizmet sağlayıcısına taşınmasında zorluklara sebep olmaktadır. Bulut Bilişim hizmet sağlayıcısına geçiş sırasında şirketlerin tüm verilerini hizmet sağlayıcısına taşıması gerekliliği, kullanılabilir bant genişliğinin sınırlı olması, veri transferinin uzun sürmesi ve veri transfer maliyetlerinin yüksek olması, şirketlerin Bulut Bilişim yoluyla hizmet almasının önündeki önemli engellerdendir.  Örnek olarak, Amazon S3 hizmet sağlayıcısına veri transferinde ortalama bant genişliğinin 5 ile 18 Mbit arasında olduğu ölçülmüştür [13]. 10 TB’lık bir veriyi, ortalama değerin üzerinde 20 Mbit/saniye hızda S3 hizmet sağlayıcısına gönderilmesi işleminin, toplamda 45 günden fazla süreceği hesaplanmaktadır [4].

Bant genişliğinin belirli limitlerin üzerine çıkamaması, dolayısıyla büyük veri transferlerinin çok uzun sürmesi ve maliyetinin yüksek olması gibi sorunlara karşı, veri disklerinin kargo şirketleri tarafından 1 günde teslim edilmek üzere fiziksel olarak yollanması gibi çözümler önem kazanmıştır.

Bulut Bilişim hizmet sağlayıcılarının düzenli bir internet bağlantısına ve yüksek bant genişliğine ihtiyaç duymaları sebebiyle, Bulut Bilişim hizmet sağlayıcılarına gerekli internet altyapısını ve bant genişliğini sağlayan İnternet hizmet sağlayıcılar (“ISP”), uyguladıkları fiyat politikaları yoluyla Bulut Bilişim hizmet sağlayıcılarını ekonomik baskı altına alabilirler. Hatta bazı İnternet hizmet sağlayıcılar, hali hazırda büyük ağ ve veri merkezleri bulundurma, kendi veri iletişim altyapılarına sahip olma, yüksek bant genişliği kullanabilme gibi avantajları sebebiyle, haksız rekabete yol açabilecek şekilde, Bulut Bilişim hizmetleri verme yoluna gidebilir [10].

Risk 7 – Yazılım Lisanslama

Günümüzdeki yazılım lisanslama mekanizmaları, yazılımların çalışacağı bilgisayarların sayısını ve hangi bilgisayarlarda çalışabileceğini kısıtlarken, çevrim içi lisanslama denetimi yaparak kullanılan lisanslarla yazılımların yüklendiği bilgisayarları eşlemektedir. Bulut Bilişim hizmet yapısında ise, işlemci, bellek ve depolama alanları dinamik olarak değişebildiği, dinamik olarak makine eklenebildiği için, yazılım lisanslaması karmaşık hale gelmektedir. Örnek olarak, kullanılan kopya (“instance”) sayısına göre lisanslama yapan bir yazılımda, çalışan hizmette kullanılmak üzere yeni bir makine eklendiğinde, bu makine üzerinde yeni bir yazılım kopyası (“instance”) oluşturulup, lisanslaması ayrı olarak yapılacaktır. Fakat Bulut Bilişim’de makinelerin dinamik olarak eklenip çıkarılabildiği düşünüldüğünde, çıkarılan bir makine yerine yenisi eklendiğinde, toplamda makine sayısı aynı da kalsa, klasik lisanslama mantığında her yeni makine için yeni bir lisans kullanılması gerekeceği için, lisans sayısı makine sayısının çok üzerine çıkabilir [1]. Bu durumda kullanılan yazılımların çeşidi ve sayısına göre, şirketlerin katlanmak durumunda kalacakları Bulut Bilişim hizmet maliyeti çok yükselebilir ve şirketler için Bulut Bilişim hizmet tedariki yapmak cazip olmaktan çıkabilir.

Ayrıca lisanslama ve kullanıcı anlaşmaları ulusal pazarlarda değişebildiği ve bazı ürünlerin sadece belirli ülke pazarlarında kullanılabildiği düşünüldüğünde, Bulut Bilişim hizmet sağlayıcıları içinde yazılımların yönetimi ve denetimi karmaşık hale gelip, bu konuda sorunlar ortaya çıkabilir.

Bulut Bilişim hizmetlerinde yazılım lisanslamada sorunlar yaşanması, hizmet sağlayıcılar tarafından açık kaynak kodlu yazılımların kullanılmasına sebep olması üzerine ve Bulut Bilişim pazarının ticari olarak oldukça büyümesinin de yardımıyla, büyük ticari yazılım firmaları kullandıkça-öde (“pay-as-you-go”) mantığında çalışan lisanslama mekanizmaları geliştirmeye başladılar. Son olarak, Microsoft yazılım firması, Amazon EC2 Bulut Bilişim hizmet sağlayıcısı üzerinde, kullandıkça-öde lisanslama imkânları sağlayıp, Windows Server ve SQL Server yazılımlarını kullanılmasına olanak sağlamıştır. Örnek olarak, Microsoft Windows Server işletim sisteminin saatlik kullanım bedeli olarak 0.15 dolar belirlenmişken, açık kaynak kodlu muadillerinin saatlik kullanım bedelleri 0.10 dolar olmaktadır [4].

Sonuç

Yazıda konu edilen riskler her kurum için aynı önemde ve öncelikte olmadığı gibi, bazı kurumlar için geçerli de olmayabilir. Bir riskin kurum için önem derecesini, kurumların içyapıları, ilişkide bulundukları veya faaliyet gösterdikleri alanlar ve olası özel durumları belirlemektedir.

Ayrıca, aralarında güven ilişkisi bulunan iki kurum arasında kurulan bulut (“community/private cloud”) ile aralarında herhangi bir güven ilişkisi bulunmayan iki kurum arasında kurulan bulutun (“public cloud”) risk derecesi farklı olacaktır. Bu sebeple kurum dışı faktörlere ve bulut bilişim hizmet sağlayıcı ile kurulacak ilişkinin türüne göre risklerin önemi değişecektir.

Son olarak, risk değerlendirmesinde bulunurken, her riskin bir fırsat ile eşlenmiş olduğu unutulmamalı, bulut bilişim tarafından sunulan fırsatların getirisi ile göze alınan riskin sonucunda karşı karşıya kalınabilecek zararın değerlendirmesi, her kurumun kendine özel şartları, dinamikleri ve faaliyet alanlarından başlayarak, tüm ilgili bileşenler göz önünde bulundurularak iyi yapılmış olmalıdır.

Referanslar

[1] ENISA, Benefits, risks and recommendations for information security, November 2009.

[2] WILSON, S. AppEngine Outage. CIO Weblog (June 2008). Available from: http://www.cio-weblog.com/50226711/appengine\_outage.php.

[3] THE AMAZON S3 TEAM. Amazon S3 Availability Event: July 20, 2008 [online]. July 2008. Available from: http://status.aws.amazon.com/s3-20080720.html.

[4] ARMBRUST et. al., Above the Clouds: A Berkeley View of Cloud Computing, February 2009.

[5] PAXSON, V. private communication, December 2008.

[6] BRODKIN, J. Loss of customer data spurs closure of online storage service ’The Linkup’. Network World, August 2008.

[7] DELANEY, K. J., & VARA, V. (2007, November 27). Google plans services to store users’ data. Wall Street Journal. Retrieved July 2, 2008, from http://online.wsj.com/article/SB119612660573504716.html?mod=hps_us_whats_news

[8] TC3 Health Case Study: Amazon Web Services [online]. Available from: http://aws.amazon.com/solutions/case-studies/tc3-health/

[9] SUNOSKY, J. T. (2000). Privacy online: A primer on the European Union’s Directive and the United States’ Safe Harbor privacy principles. Currents: International Trade Law Journal,9, 80-88.

[10] JAEGER et. al., Cloud Computing and Information Policy: Computing in a Policy Cloud?, 2008.

[11] CSA, Top Threats to Cloud Computing V1.0, March 2010.

[12] RAGRAGIO & RADU, The cloud or the mist?, September 2009.

[13] GARFINKEL, S. An Evaluation of Amazon’s Grid Computing Services: EC2, S3 and SQS . Tech. Rep. TR-08-07, Harvard University, August 2007.

Sadece kayıtlı kullanıcılar yorum yazabilir.
Lütfen sisteme giriş yapın veya kayıt olun.