Minimum privileges / permissions required for virtual machine user related tasks and assigning them to roles in VMware vCenter 4

It can be very frustrating or even confusing when dealing with privileges / permissions and roles in VMware vCenter because of hierarchical inheritance of permissions. After some point, you forget about the security and give the users more permissions than they actually need.

Least privileges required for a user to work with his/her virtual machines are listed below:

Task

Privilege

Location

Create a virtual machine

Virtual Machine.Inventory.Create (*)

Destination Folder or Datacenter

Virtual Machine.Configuration.Add New Disk (*)

Virtual Machine .Configuration.Add Existing Disk

Virtual Machine.Configuration.Raw Device

Resource.Assign Virtual Machine to Resource Pool  (*)

Destination host, cluster, or resource pool

Datastore.Allocate Space (*)

Destination datastore or datastore folder

Network.Assign Network (*)

Network

Deploy a virtual machine from template

Virtual Machine.Provisioning.Deploy Template

(plus above privileges with *, if not exist)

Destination Folder or Datacenter

Clone a virtual machine

Virtual Machine.Provisioning.Clone Virtual Machine

(plus above privileges with *, if not exist)

Destination host, cluster, or resource pool

Take a snapshot

Virtual Machine.State.Create Snapshot

Destination Folder or Virtual Machine

Datastore.Allocate Space

Destination Datastore or datastore folder

Revert to a snaphot

Virtual Machine.State.Revert to Snapshot

Destination Folder or Virtual Machine

Remove a snapshot

Virtual Machine.State.Remove Snapshot

Destination Folder or Virtual Machine

Power on / off and reset virtual machine

Virtual Machine.Interaction.Power Off

Destination Folder or Virtual Machine

Virtual Machine.Interaction.Power On

Virtual Machine.Interaction.Reset

Console interaction with virtual machine

Virtual Machine.Interaction.Console Interaction

Destination Folder or Virtual Machine

Connect / disconnect media or device

Virtual Machine.Interaction.Device Connection

Destination Folder or Virtual Machine

Install VMware tools

Virtual Machine.Interaction.Tools Install

Destination Folder or Virtual Machine

As you can see above, these privileges are assigned to different objects and related to different operations on VMware vCenter. Therefore instead of creating one role and giving all permissions to it, best way is to create one role for each specific object or operation. Here are the roles I have created for these permissions:

Role

Privilege

Location

VMUserRole

Virtual Machine.Inventory.Create

Destination Folder or Virtual Machine

Virtual Machine.Configuration.Add New Disk

Virtual Machine .Configuration.Add Existing Disk

Virtual Machine.Configuration.Raw Device

Virtual Machine.Provisioning.Deploy Template

Virtual Machine.Provisioning.Clone Virtual Machine

Virtual Machine.State.Create Snapshot

Virtual Machine.State.Revert to Snapshot

Virtual Machine.State.Remove Snapshot

Virtual Machine.Interaction.Power Off

Virtual Machine.Interaction.Power On

Virtual Machine.Interaction.Reset

Virtual Machine.Interaction.Console Interaction

Virtual Machine.Interaction.Device Connection

Virtual Machine.Interaction.Tools Install

DatastoreRole

Datastore.Allocate Space

Destination datastore or datastore folder

NetworkRole

Network.Assign Network

Network

ResourcePoolRole

Resource.Assign Virtual Machine to Resource Pool 

Destination host, cluster, or resource pool

Below you can see how these roles should be assigned to objects in VMware vSphere 4:

You can add or remove permissions to roles according to your own design. I hope this helps you to design your own roles and decide which privileges are assigned to each role.

Posted in Virtualization | Tagged , , , , | Leave a comment

Social Engineering Toolkit – Can not get UPX encoding work (SET Error: “UPX was not detected. Try configuring the set_config again”)

In BackTrack5, when you try to use SET to create a fake website using its Java Applet Attack Method and Backdoored Executable encoding, it is probable that you get an error message as follows: “UPX was not detected. Try configuring the set_config again”.

In order to resolve this issue, here are the options you can do (Option 3 is the best one);

Option 1: you need to change the two directives in set_config (/pentest/exploits/set/config/set_config) as below:

  • DIGITAL_SIGNATURE_STEAL=OFF
  • UPX_PATH=/pentest/web/scanners/sqlmap/lib/contrib/upx/linux/upx

It seems that first directive, which enables digital signature stealing, is what causes the problem with UPX. The second directive changes the  default path of UPX, because it could not be found in that path. Luckily, it also comes with SQLMAP, therefore you can change the default path of the UPX to path of the one which comes with sqlmap.

OR

Option 2: You can check if upx is located in its default folder (/usr/bin/upx), if not you can install it by using apt-get as below:

  • apt-get install -y upx

Then you need to change one directive in set_config (/pentest/exploits/set/config/set_config) as below:

  • DIGITAL_SIGNATURE_STEAL=OFF

OR

Option 3: If you also want to get the use of digital signature stealing capability of set, then first you need to install pefile module as follows:

  • apt-get install python-pefile

Then install upx as described in option 2 above which is executing the code below:

  • apt-get install upx

Now, you don’t need to change anything in the set_config file, you can use the default settings.

Using one of the options above, fixes the problem and UPX encoding works fine.

Posted in Penetration Testing | Tagged , , , , , , , | Leave a comment

Microsoft Exchange 2010 – Information Store service does not start (mostly after converting physical server to virtual using vmware converter)

If you are facing problems while starting Information Store service in Microsoft Exchange 2010 server and getting an error message in an alert window with error code of -2147221213, it is most probable that there is a missing key in registry related with the exchange setup. If you also check application event logs for detailed information and see events with errors 7024, 1026, 9542 and 5000, then that is the case.

Problem occurs because there is no “Services” string value in the below registry key or the key is inaccessable: HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Setup

To fix this problem and be able to start the Microsoft Exchange Information Store service, do the following steps:

  • Go to Start > Run > type “regedit”
  • Check if there is a key “Setup” under: HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\
  • If not, right click key “Exchange” > New > Key and name it as “Setup”
  • Create a new string value in this newly created key and name it as “Services”
  • Right click Services > Modify and enter the full installation path of Exchange 2010, default path is C:\Program Files\Microsoft\Exchange Server\V14
  • If there already exists a string value “Services” in the registry key “Setup”, check if it points to the installation folder of Exchange 2010 or check if SYSTEM user has permission to access to this registry key “Setup” (Right click Setup > Permissions)

In our case, we faced the problem in virtual Exchange 2010 server after we converted the running physical one using VMware Converter tool. It is probably that while converting the physical server to virtual, VMware Converter could not access the registry key described above and therefore skipped it.

Posted in Exchange | Tagged , , , | 4 Comments

How to kill or stop a process from command prompt in Windows 7

In order to kill a process in Windows 7, first you should get its process id. To get it from command prompt, type the following command;

netstat -ao

Instead of listing all processes, you can filter the process list by getting processes only in “listening” or “established” state as below;

netstat -ao | find /i “listening”

From the process list, find the process to be killed and note its id from the PID column. Using this process id, execute the following command in order to kill the process;

taskkill /f /pid <process-id>

More than one process can be killed in a single command by using multiple “/pid <pid>” pairs as below;

taskkill /f /pid <process1-id> /pid <process2-id> /pid <process3-id>

Posted in Windows Security | Tagged , , , , , , | Leave a comment

Freeze or stall while connected to virtual machines with Windows 2008 R2 or Windows 7 through console on VMware vSphere 4 client

On VMware vSphere client, while you are connected to virtual machines with Windows 2008 R2 or Windows 7 operating system using console connection, guest operating system can freeze or stall for a long period of time so that it doesn’t respond any of your actions. Actually operating system is still working but you can not see or interact with the guest operating system because of the SVGA drivers that is installed by the VMware Tools.

In order to avoid having the guest operating system freeze or stall while working on console of vSphere client software, you need to;

  1. uninstall VMware tools, if you have already installed,
  2. choose custom installation, as seen on the screenshot below,
  3. deselect SVGA drivers from VMware Device Drivers as below,
  4. then click install to install VMware Tools without SVGA drivers.

Although it is said that the problem is fixed with the vSphere 4 Update 1, i had the same problem with the newer version which is vSphere 4.1.

Posted in Virtualization | Tagged , , , , , , , , , | Leave a comment

ICMP Keşif (“Reconnaissance”) Saldırıları

ICMP Nedir?

ICMP (Internet Control Message Protocol) protokolü, IP protokol takımının bir parçasıdır. Hedef ve özellikleri RFC 792’de belirtilmiştir. ICMP protokolünün temelde iki çeşit görevi bulunmaktadır. Bu görevler;

  • Sürekli hata durumlarının bildirilmesi ve
  • Ağ ile ilgili genel özellikleri saptamak üzere, istek ve cevap mesajlarıyla ağın araştırılmasıdır.

Bu sebeple, ICMP mesaj çeşitleri de yerine getirdikleri görevleri yansıtacak şekilde ikiye ayrılmaktadır;

  • ICMP Hata Mesajları (Örneğin; “Destination Unreachable”, “Source Quench”, “Redirect”, vs.)
  • ICMP Sorgu Mesajları (Örneğin; “Echo Request & Reply”, “Timestamp Request & Reply”, vs.)

ICMP mesajları, IP paketleri içinde gönderilseler de, bu ICMP’nin daha üst seviye bir protokol olduğu için değil, IP’nin bir iç parçası olduğu içindir. ICMP mesajları aşağıdaki şekildeki gibi sarmalanarak gönderilirler.

icmp-pr555.png

Şekil-1 ICMP Mesajları gönderimi

ICMP Keşif Saldırıları

ICMP mesajlarını değiştirip, mesajın başlık (“header”) kısmında bulunan belirli alanlarda oynamalar yaparak veya bu mesajları asıl amaçları dışında kullanarak, hedef olarak seçilen sistemlere keşif (“reconnaissance”) saldırıları düzenlenebilir. Keşif saldırılarının amacı, yapılacak asıl saldırılar öncesinde, hedef sistemler hakkında gerekli bilgileri elde etmek ve bu bilgileri kullanarak hedef sistemlere etkin saldırılar düzenlemektir. Bu yazıda toplamda yedi çeşit keşif türü incelenecektir;

  1. Sunucu Tespiti
  2. Ağ Topolojisinin Tespiti
  3. Güvenlik Duvarı Kuralları Tespiti (“Firewalk”)
  4. Ters Eşleme (“Inverse Mapping”)
  5. Erişim Kontrol Listesi (“Access Control List”) Tespiti
  6. Protokol/Port Taraması
  7. İşletim Sistemi Tanıma (“OS Fingerprinting”)

1. Sunucu Tespiti

ICMP mesajları kullanılarak sunucu tespiti yapılması iki farklı yöntemle mümkün olmaktadır. Bu yöntemler; gönderilen ve alınan mesajlar olarak aynı olmakla birlikte, mesaj içeriğindeki hedef sunucu adresleri olarak farklılık göstermektedir.

ICMP/Ping  Taraması (“ICMP/Ping Sweep”)

ICMP mesaj çeşitlerinden “Echo Request” mesajı gönderilip, cevap olarak “Echo Reply” mesajı alınarak (daha bilinen bir şekilde “ping” komutuyla), yerel ağ veya İnternet üzerinden erişilebilir ve çalışmakta olan sunucuların tespit edilmesi mümkün olmaktadır. Bu yöntemde, ICMP mesajı doğrudan hedef sunucunun IP adresine gönderilir. Bu işlemin tek bir IP adresi yerine, belirli bir IP adres aralığı için yapılması ve bu aralıktaki sunucuların tespit edilmesi mümkün olmaktadır.

ICMP Yayınlama (“Broadcast ICMP”)

Bu yöntem, her bir sunucunun IP adresine tek tek “ICMP Echo Request” mesajı göndermekle uğraşmak yerine, hedef ağın yayın (“broadcast”) adresine bir tek “ICMP Echo Request” mesajı gönderilerek gerçekleştirilir. Bu sayede, toplu olarak ağdaki canlı sunucuların mesajı gönderen bilgisayara/saldırgana “ICMP Echo Reply” mesajları göndermesi sağlanılarak, tüm bir ağdaki çalışan sunucuların tespit edilmesi mümkün olmaktadır. Bu şekilde, tek bir mesajla tüm ağdaki çalışan sunucuların tespiti yapılabilmektedir.

Tüm kolaylığına rağmen, bazı Unix (Linux Kernel 2.2.x ve 2.4.x) ve Unix benzeri işletim sistemleri (Solaris 2.5.1, 2.6, 2.7 ve HP-UX v10.20) dışındaki diğer bir çok işletim sisteminin yayın adresinden gelen mesajlara cevap göndermemesi sebebiyle, bu tespit yöntemi yaygın olarak kullanılamamaktır (Örneğin, Windows işletim sistemi).

2. Ağ Topolojisinin Tespiti

Hedef sunucunun ağ topolojisindeki yerinin tespitinde “traceroute” (Windows işletim sistemleri için “tracert”) komutu kullanılmaktadır. Bu komutun gerçekleştiriminde (Windows işletim sistemi için), ICMP “Echo Request” mesajları ve ICMP paketi içerisinde yer alan TTL (Time-to-Live) alanı kullanılır. TTL değeri, paketin hedefe giderken yol boyunca uğradığı her bir yönlendirici tarafından bir azaltılarak bir sonrakine iletilir. Bu iletim sırasında TTL değeri sıfıra ulaşır ise, paket düşürülür ve gönderen sunucuya ICMP “Time Exceeded” mesajı gönderilerek paketin hedefe ulaşamadan düşürüldüğü bildirilir. Bu komut ile yapılan ise, hedefe giderken yol boyunca, ilk olarak TTL değeri bir olan ICMP paketinin gönderilmesi ve sonrasında ise ICMP paketindeki TLL değerinin sırayla birer arttırılarak yollanması, böylece her bir adımdaki sunucudan dönecek ICMP “Time Exceeded” mesajlarıyla yol üzerindeki sunucuların tespit edilebilmesidir.

Hedef sistemin bulunduğu ağ topolojisi bilgisinin elde edilmesi ise, anlatılan yöntemin bir ağdaki bütün bilgisayarlar için gerçekleştirilmesi sonucu olabilmektedir.

3. Güvenlik Duvarı Kuralları Tespiti (“Firewalk”)

Paket filtreleyen bir güvenlik duvarı üzerindeki açık olan portların tespit edilmesi, ağ topolojisinin tespitinde kullanılan yöntemin daha ileri götürülmesiyle mümkün olmaktadır. Bu sayede, güvenlik duvarı üzerindeki kurallar tespit edilebilmektedir.

Bu işlem, iki aşamada yapılmaktadır. İlk aşamada, saldırganla güvenlik duvarı arasındaki sunucu/yönlendiricilerin (“hop”) sayısı “traceroute” yapılarak tespit edilir. İkinci aşama olan tarama aşamasında ise, güvenlik duvarı arkasındaki bilinen bir sunucuya, TTL değeri güvenlik duvarından bir büyük olan TCP veya UDP segmentleri gönderilir. Bu işlem sonrası cevap olarak ICMP “Time Exceeded” mesajı geliyorsa, bu segmentin güvenlik duvarını geçebildiği anlaşılır (Segmentler güvenlik duvarını geçtikten sonra TTL değerleri sıfıra düşeceğinden dolayı). Cevap olarak herhangi bir mesajın geri dönmediği durumda ise segmentin güvenlik duvarı tarafından engellendiği sonucu çıkarılır. Bu işlemin olası bütün TCP/UDP port kombinasyonları için gerçekleştirilmesi durumunda, güvenlik duvarı üzerindeki açık olan portlar tespit edilebilir.

Ters Eşleme (“Inverse Mapping”)

Ters eşleme yöntemiyle, güvenlik duvarı arkasında bulunan sunucuların veya tüm bir ağın tespit edilmesi mümkün olabilmektedir.

Birçok güvenlik duvarında ICMP mesajları için, dinamik filtreleme / durum denetimli (“stateful”) engelleme uygulanmamaktadır. Bu sebeple, güvenlik duvarı arkasındaki bir iç ağın, sahip olduğu tahmin edilen bir IP adres aralığı için, ICMP “Echo Reply” mesajları gönderilebilmektedir. Bu ağdan ICMP “Echo Request” mesajı gönderilmediği halde, güvenlik duvarı durum bilgisini tutmadığı için, ICMP “Echo Reply”mesajları engellenmeden güvenlik duvarından geçebilirler. Güvenlik duvarını geçen ICMP “Echo Reply ” mesajları arasından hedef IP adresinde bir sunucu bulunmayan mesajlar için, iç ağdaki bir yönlendirici tarafından ICMP “Host Unreachable” mesajı gönderilir. Saldırgan gönderilen bütün bir IP aralığındaki adreslerden, ICMP “Host Unreachable” mesajı gelen adresleri elde eder. Bu sayede, ICMP “Host Unreachable” mesajı gönderilmeyen IP adreslerinde çalışan sunucular bulunduğu tespit edilerek, güvenlik duvarı arkasında bulunan iç ağ ortaya çıkarılabilir.

Erişim Kontrol Listesi (“Access Control List”) Tespiti

ICMP hata mesajlarını kullanarak, yönlendirici veya sunucu gibi filtreleme yapabilen cihazlarda bulunan erişim denetim listelerinin tespit edilmesi mümkün olmaktadır.

Bu yöntem, IP paketi başlığı içinde yer alan, toplam uzunluk (“Total Length”) alanının gerçek değerinden daha büyük bir değer ile değiştirilmesi ilkesine dayanmaktadır. Toplam uzunluk alanı değiştirilen paket hedef sunucuya ulaştığında,  hedef sunucu tarafından paket açılacaktır. Fakat toplam uzunluk değerine göre olması gereken ama gerçekte olmayan alandaki veriye ulaşılamaması sonucunda, hedef sunucu tarafından ICMP “Parameter Problem Code 2” mesajı oluşturulacak ve saldırgana yollanacaktır. Gönderilen paketin karşılığında, ICMP parametre sorunu mesajının alınması, saldırgana pakette kullanılan protokol ve servisin filtreleme cihazı tarafından engellenmediğini göstermektedir. Başlık kısmı değiştirilen IP paketi içinde, ICMP veya daha üst seviye protokoller olan TCP veya UDP protokolleri sarmalanmış olabilir.

Bu işlemin, tüm olası protokol ve servis kombinasyonları ile bütün bir ağ için tekrarlanması durumunda, filtreleme cihazında yer alan erişim listelerinin tamamını elde etmek mümkün olabilmektedir.

Protokol/Port Taraması

ICMP “Protocol/Port Unreachable” mesajlarını kullanarak, hedef sunucu üzerinde hangi protokol veya portların kullanıldığını tespit etmek mümkündür.

Bu yöntemde, IP başlığı içinde yer alan sekiz bitlik protokol alanın tüm kombinasyonları (toplamda 256 değişik protokol) kullanılarak hazırlanan paketler hedef sunucuya gönderilir, cevap olarak ICMP “Protocol Unreachable” mesajı gelen protokol veya portların kapalı olduğu, cevap gelmeyenlerin ise açık olduğu anlaşılabilmektedir. Bu sayede, hedef sunucunun kullanımda olan açık protokol veya portlarının bir listesi elde edilebilmektedir.

İşletim Sistemi Tanıma (“OS Fingerprinting”)

Farklı işletim sistemi geliştiricilerinin, ağ trafiğini yönetme anlamında  birbirlerine göre az da olsa farklı yolları benimsemiş olmaları sebebiyle, aktif veya pasif olarak hedef sunucunun işletim sisteminin tespit edilmesi mümkün olmaktadır.

Aktif Tanıma

İşletim sisteminin aktif olarak tanınması, hedef sunucuya doğrudan ICMP hata/sorgu mesajları gönderilmesi ve sonrasında gelen cevapların analiz edilmesi ile gerçekleştirilir. Dönen ICMP mesajlarının başlık kısmındaki belirli alanlar, işletim sistemlerine göre farklılık gösterebildiğinden dolayı, bir veya birden fazla mesaj alış verişi ile işletim sistemlerinin tespit edilmesi mümkün olabilmektedir (Herhangi bir cevabın dönmemesi de tanıma işleminde kullanılır). Gönderilen farklı türdeki ICMP mesajlarına dönülen/dönülmeyen cevapların işletim sistemlerine göre değişebilmesi sayesinde, aşağıdaki örneklerdeki gibi hedef sistemlerin işletim sistemleri ve bu işletim sistemlerinin versiyonları tespit edilebilmektedir.

icmp_lin.jpg

Şekil – 2 Linux işletim sistemleri için ICMP mesajlarıyla tanıma

icmp_win.jpg

Şekil – 3 Windows işletim sistemleri için ICMP mesajlarıyla tanıma

Pasif Tanıma

Pasif tanıma, hedef sunucuya doğrudan ICMP mesajları göndermek yerine, hedef sunucunun ağ trafiğinin dinlenmesi sonucu elde edilen bilgilerin (gelen/giden ICMP mesajlarının) analiz edilmesiyle gerçekleştirilir. Pasif tanımanın aktif tanımaya göre pozitif yönleri olarak; herhangi bir ağ trafiği oluşturmadığından zor fark edilebilmesi, tüm trafiğin kaydedilmesinden dolayı daha fazla mesajın incelenebilmesi, trafik analizinin çevrimdışı olarak yapılabilmesi, iç veya dış ağın farklı noktalarının dinlenerek (ağı dinleyen sensörler yardımıyla), farklı ağ trafik bilgilerine erişilebilmesi gibi özellikleri sayılabilir.

Referanslar

[1] SANS Institute, ICMP Attacks Illustrated, 2001

[2] Ofir Arkin, ICMP Usage in Scanning, Haziran 2001

[3] KoonYaw Tan, Intrusion Detection FAQ: How can attacker use ICMP for reconnaissance?, http://www.sans.org/security-resources/idfaq/icmp_misuse.php (Ağustos 2010’da erişildi)

Posted in Network Security | Tagged , , , , , , , , , , , , , , , | Leave a comment

Robocopy – Copying files with file permissions (ACLs) and Importing file permissions / security information

If you have a file server in your corporate environment and want to move all files to another location with all security information / file permissions  (ACLs), you can use robocopy, a built-in tool which can be called simply from a command prompt of a Windows Server 2008 or Windows 7 installed computer.

If you want to copy all the files into the new file server by keeping directory tree as it is and security information / file permissions, you can simply use the following command to achieve that;

robocopy “source address” “destination address” *.* /mir /sec

If you have copied the files before with another tool or technique but without any file permissions or security information (ACLs), you can fix the security information of each file and add file permissions using the following command;

robocopy “source address” “destination address” *.* /mir /secfix /sec

Using the command above, you don’t need to copy all files again or try to write a script to add access control list to each file, robocopy will read the file permissions from the existing directory tree and add the security information to each file in the new location.

Posted in Windows Security | Tagged , , , , , , , , , | 3 Comments

Bulut Bilişim Risk Değerlendirmesi (Cloud Computing Risk Assessment)

Bulut Bilişim’in Risk Değerlendirmesi

Giriş

Sunduğu geniş imkânların ve esnekliğinin yanında, Bulut Bilişim beraberinde belirli riskleri de barındırmaktadır. Bu bölümde, bu riskler üzerinde durulurken unutulmaması gereken bir nokta her riskin bir fırsat ile eşlenmiş olduğu, 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ğerlendirmesinin, her kurumun kendine özel şartları, dinamikleri ve faaliyet alanları göz önünde bulundurularak iyi yapılmış olmasıdır. Ayrıca risklerin değerlendirilmesi sırasında dikkat edilmesi gereken bir diğer nokta da, Bulut Bilişim’in içerdiği riskler ile hali hazırda kullanılan geleneksel çözümlerle devam edilmesi durumunda karşı karşıya kalınabilecek risklerin karşılaştırmasının doğru olarak yapılmış olmasıdır [1]. Belirli riskler sadece Bulut Bilişim’e özel olmakla birlikte, bazı risklerinin boyutu ve öneminin geleneksel yöntemlere göre, Bulut Bilişim’de daha fazla veya daha az olabileceği gibi, sadece geleneksel yöntemlerde rastlanabilecek riskler de bulunabilir. Yapılacak risk değerlendirmesinin sağlıklı olabilmesi için, tüm bunların göz önünde bulundurulması gerekmektedir.

Bulut Bilişim’in beraberinde getirdiği riskler olarak, bu yazıda 7 adet riskten söz edilecektir. Bu riskler ile ilgili geniş anlatım takip eden bölümde bulunmaktadır. Burada her bir risk, kendi içinde farklı açılardan inceleneceği gibi, bu riskin azaltılabilmesi için yapılması gerekenlere veya hali hazırda yapılmakta olan çalışmalara da değinilecektir.  Riskler şu şekilde sıralanabilir;

  1. Hizmet Devamlılığı ve Kullanılırlığı
  2. Veri Güvenliği ve Gizliliği
  3. Veri Denetlenebilirliği, Uygunluğu ve Yasal Düzenlemeler
  4. Hizmet Sağlayıcı Bağımlılığı ve Veri Kilitlenmesi
  5. Yönetim Ara yüzü ve Uzaktan Erişim
  6. Bant Genişliği ve Veri Transferi
  7. Yazılım Lisanslama

Bulut Bilişim Riskleri

Risk 1 – Hizmet Devamlılığı ve Kullanılırlığı

Bulut Bilişim hizmet sağlayıcılarda hizmet kesintisine sebebiyet verebilecek bir sorun yaşanması durumunda, bu hizmet sağlayıcıdan hizmet tedariki yoluna gitmiş tüm şirketler birden bundan etkilenecek ve kesinti sonuçlanana kadar,  şirketlerin müşterilerine hizmet veremez hale gelmelerine sebep olacaktır. Eğer şirketler tüm teknolojik altyapı ve hizmetleri tek bir Bulut Bilişim hizmet sağlayıcıdan temin ediyorlarsa, oluşabilecek bir kesinti, şirketin tüm işletme ve ekonomik faaliyetlerinin durmasına sebebiyet verebilir. Her ne kadar Bulut Bilişim hizmet sağlayıcı firmalar bu tür durumlara karşı hazırlıklı ve çok geniş teknolojik altyapılara sahip olsalar da, Haziran 2008’de Google AppEngine’de meydana gelen bir programlama hatasından dolayı 6 saat, Temmuz 2008’de ise Amazon S3’te tek bir bit hatasından kaynaklanan bir hatadan kaynaklanan 8 saatlik hizmet kesintileri yaşandı [2, 3].

Tek bir yıkım noktasına (“single point of failure”) dayanmaktan kaçınarak, şirketlerin ihtiyaç duydukları hizmetlerini farklı hizmet sağlayıcılardan tedarik etmeleri, şirketlerin riski dağıtmasına, hizmet sağlayıcılarda oluşabilecek kesintilerden ve hatta hizmet sağlayıcıların iflası gibi durumlardan en az etkilenmelerine imkân tanıyacaktır [4].

Bulut Bilişim hizmet sağlayıcılarında meydana gelebilecek hizmet kesintileri, hizmet sağlayıcıları içindeki yazılımsal, donanımsal ya da mimari bir hatadan kaynaklanabileceği gibi, dışarıdan gelebilecek saldırılardan da kaynaklanabilir. Bu tür dışarıdan yapılan saldırılar genelde,  dağıtılmış hizmet dışı bırakma saldırıları (“DDoS”) tabir edilen, birçok bilgisayardan aynı anda aynı noktaya isteklerin yönlendirilip, sunucuların bu isteklere cevap veremez hale getirilmesi ilkesine dayanan saldırılardır. Suçlular, “DDoS” saldırıları düzenleyip, Bulut Bilişim hizmet sağlayıcıların hizmetlerini kesintiye uğratacakları tehdidi ile hizmet sağlayıcı firmalardan para talep edebilmektedirler [4]. Bu saldırılarda kullanılan bilgisayarlar “bot” adı verilen, bilgisayar korsanları tarafından zararlı yazılımlar yüklenip ele geçirilmiş ve kullanıcısının farkında olmadan istenildiği an istenen bir noktaya saldırması sağlanan bilgisayarlardır. İnternet üzerinde karaborsada, ele geçirilmiş bir bilgisayarın (“bot”) 0.03 dolar gibi düşük bir fiyatla bir hafta süreyle kiralanabildiği bilinmektedir [5]. Bu sayede kolay bir şekilde, düşük bir harcama ve çok büyük sayıda ele geçirilmiş bilgisayar kullanılarak (“bot”), etkili hizmet dışı bırakma saldırılarının (“DDoS”) düzenlenebilmesi, hizmet sağlayıcılar için önemli tehlike ve risk oluşturmaktadır. Fakat Bulut Bilişim hizmet sağlayıcılarının bu tür saldırılara karşı koyacak koruma mekanizmalarını oluşturma yoluna gitmesi, ihtiyaç anında hızlı ve dinamik kaynak ayırabiliyor olmaları sayesinde, gelen “DDoS” saldırılarına karşı koyabilmeleri, saldırının geldiği noktaları tespit edip engelleyebilmeleri mümkün olmaktadır.

Risk 2 – Veri Güvenliği ve Gizliliği

Bulut Bilişim hizmetlerindeki önemli kaygılardan birini de, hizmet sağlayıcılar ile paylaşılan özel ve gizli bilgilerin, Bulut içindeki diğer hizmet kullanıcısı olan şirketlerden nasıl korunacağı, veri gizliliğinin nasıl sağlanacağı konusu oluşturmaktadır. Bulut içindeki bir kullanıcı için mümkün olan veri gizliliği seviyesi çoğu durumda, masaüstü uygulama kullanıcılarına göre daha düşük olmaktadır [7].

Bulut Bilişim hizmetlerinin aynı anda birçok kullanıcı tarafından kullanılması ve fiziksel kaynakların tüm kullanıcılar tarafından ortak olarak kullanılıyor olması veri gizliliği ve güvenliği için riskler barındırmaktadır. Bulut içindeki farklı kullanıcıların, ortak kaynaklar üzerindeki depolama, bellek alanlarını birbirinden ayırmaya yarayan iç mekanizmalarda ortaya çıkabilecek açıklık ve hatalar, yapılacak saldırılar sonucu kullanıcıların özel ve gizli verilerinin ele geçirilmesine sebebiyet verebilir.

Ayrıca, Bulut Bilişim’de kaynakların dinamik olarak ayrılıp bırakıldığı düşünüldüğünde, çoğu işletim sisteminde uygulandığı gibi,  silinen verilerin fiziksel olarak silinmeyip sadece mantıksal seviyede silinmesi durumunda, bırakılan depolama kaynağının başka bir kullanıcıya tahsis edilmesi sonucu, bu fiziksel olarak silinmeyen verinin başka kullanıcılar tarafından ele geçirilmesi mümkün olabilmektedir.

Bulut Bilişim’in dağıtık mimaride olması sebebiyle, içerisinde hizmetler arası yoğun veri trafiği ve veri iletişimi gerektirmektedir. Bunun sonucu olarak, Bulut içinde bulunabilecek kötü niyetli kullanıcılar, zararlı yazılımlar çalıştırıp, açık kapı (“port”) taraması yaparak elde edeceği bilgilerle, korsan saldırılarda bulunabilir ve olası veri kaçaklarını ve veri iletişimini dinleyip, gizli verileri ele geçirebilirler [1].

Bulut Bilişim hizmet sağlayıcı firmaların, belirli özelleşmiş görevleri dışarıdan 3. Parti firmalardan tedarik yoluna gitmesi, hizmet sağlayıcıların aldıkları tüm güvenlik önlemlerine rağmen sistemlerinin güvenlik seviyesini, 3. Parti firmalarla kurulan bağlantının ve bu firmaların sistemlerinin güvenlik seviyesine bağlı hale getirerek, veri güvenliği ve veri kontrolünün kaybedilmesine sebebiyet verebilir.

Yukarıda sayılan veri gizliliğine zarar verebilecek davranışların büyük bölümü, Bulut içinde verileri şifreli şekilde saklama, sanal yerel ağlar kullanımı ve ağ içi güvenlik duvarı kullanımı yöntemleri ile engellenebilir. Örnek olarak, verilerin Bulut Bilişim hizmet sağlayıcısına şifrelenip gönderilmesi yöntemi, hastaların hassas sağlık bilgilerine erişime sahip olan TC3 adlı bir sağlık firması tarafından başarıyla kullanılmıştır [8].

Risk 3 –Veri Denetlenebilirliği, Uygunluğu ve Yasal Düzenlemeler

Belirli alanlarda faaliyet gösteren şirketler, sertifikasyonu sağlamak, rekabet avantajı elde etmek, endüstri standartlarını karşılamak veya yasal zorunluluklardan dolayı, belirli standartlara uyma konusunda büyük yatırımlar yapmaktadırlar. Fakat Bulut Bilişim hizmet sağlayıcılarının, bu standartların gereklerini yerine getirmeye yönelik, kendi uygunlukları (“compliance”) konusunda kanıt sunamamaları ve Bulut kullanıcılarına bunlara ilişkin denetim izni vermediği durumlarda, yapılan yatırımlar riske atılmış olabilir. Örnek olarak, Amazon EC2 hizmet sağlayıcısı kullanıcılarını, platformları üzerinde PCI Veri Güvenlik Standardına uygunluğu sağlamada zora düşebilecekleri konusunda uyarmaktadır. Bu sebeple, EC2 üzerinde faaliyet gösteren hizmetler, kredi kartı işlemlerini yerine getirememektedir [1].

Bulut Bilişim hizmetlerinin dağıtılmış olarak çalışan küresel hizmetler olduğu düşünüldüğünde, farklı ülkelerden kullanıcılar, farklı iş kültürlerine ve yasal düzenlemelere sahip olarak iş görmektedirler. Bulut Bilişim hizmet sağlayıcılarının farklı ülkelerde ve bölgelerde veri merkezleri bulundurması, bulunduğu ülkedeki yasal düzenlemelere de uyum sağlamasını gerektirebilir. Veri gizliliği ve denetimi konusunda ülkelerin farklı yasal düzenlemelere sahip olması, Bulut Bilişim hizmet sağlayıcılarının hizmetlerini yerine getirirken, farklı yasal düzenlemelere uyum sağlamada sorunlara neden olabilir. Avrupa Birliği ülkeleri ve Amerika Birleşik Devletleri arasında bile, kişisel gizlilik ve kişisel gizliliği koruma türleri konusunda belirgin farklılıklar bulunmaktadır [9]. Ayrıca, bulunduğu ülke dışındaki başka bir ülkede yerleşik bir Bulut Bilişim hizmet sağlayıcısından hizmet alan şirketler, dolaylı olarak bu ülkenin yasalarının kapsamına girdiği için, burada saklanan verilerine hizmet sağlayıcının bulunduğu ülke tarafından adli yargı yoluyla erişilebilir ve verilerinin gizliliği tehlikeye girebilir. Örnek olarak, Amerika Birleşik Devletleri hükümeti, A.B.D. Vatanseverlik Yasası, Yurtiçi Güvenlik yasası benzeri yasaları kullanarak, gelişmiş bilgi toplama teknolojilerinin yardımıyla her türlü bağlamdaki elektronik veriye erişebilmektedir [10]. Dolayısıyla Avrupa’da bulunan bir kullanıcı, A.B.D. merkezli bir Bulut Bilişim hizmet sağlayıcıdan hizmet temin etme kararı alırken, bu ülkedeki yasal düzenlemeleri göz önünde bulundurması gerekmektedir.

Bulut Bilişim mimarisine, veri denetimi özelliği kazandırabilmek ve bu yolla belirli standartları ve yasal zorunlulukları sağlayabilmek için, sanal misafir işletim sisteminin erişemeyeceği, ayrı bir veri denetimi katmanı eklenebilir. Bu sayede veri denetimi ve uygunluğu merkezileştirilmiş tek bir mantıksal katman üzerinden sağlanabilir [4].

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ı; belirli alanda uzmanlaşmış uygulamalarını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.

Kaynakça

[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.

Posted in Bulut Bilişim - Cloud Computing | Tagged , , , , , , | Leave a comment