5   Sunucu Dönüşümü

5.1   E-Posta Sistemi Dönüşümü

E-posta sistemi ilk çıktığı hali ile güvenlik ön planda olmadan sadece insanların bilgisayar başında değilken birbirlerine ulaşmayı amaçlamış bir protokoldür. E-posta sistemlerinde güvenlik daha sonradan düşünülmüş bir özelliktir. Güvenli kalması gereken dokümanlarınızı mümkün olabildiğince güvenlik önlemleri artırılmış e-posta sunucularından -bu sizin eposta sunucunuzun güvenli olması gerekliliğini gösterirken karşı tarafında güvenlik konusunda yeterli olduğuna kanaat getirebilmenizi tavsiye eder.- ve ya güvenliğinden emin olamadığınız durumlarda göndereceğiniz dokümanları şifrelenmiş olarak göndermeniz tavsiye edilir.

Bedelsiz olarak e-posta hizmeti sağlayan kuruluşların lisans sözleşmeleri dikkatli incelenirse e-posta içeriklerinin; sayfalarda size gösterilen reklam içeriklerini iyileştirmek için tarandığını belirten maddeleri görebilirsiniz. Ayrıca bağlı oldukları ülkelerin varsa siber güvenlik yasalarında ihtiyaç görülen durumlarda sunucularındaki içerikleri devlet yetkililerine teslim edebileceklerine dair maddeler unutulmamalıdır.

Ayrıca genel olarak devlet kurumlarında gözlemlenen; yaklaşık bütün servisler için barındırılan tüm BT ekipleri kurulum destek ve lisans anlaşmaları ile ayakta duruyor. Kurumlar teknik olarak bilgiyi satın almaya muhtaç bir yapı haline geliyorlar. Elbette hiçbir kurumun oturup baştan bir e-posta sistemi yazması beklenmiyor ancak özgür yazılımlarla veya özgür yazılımların teknik destek sözleşme ve lisansları ile yapılan anlaşmalardan edindiğimiz kazanımlar düşünüldüğünde hem rekabet açısından hem de sermayemizin ülke içinde kalması açısından daha olumlu sonuçlar doğurmaktadır.

E-posta göçünü düşündüğünüzde edineceğiniz kazanımları birçok açıdan değerlendirerek girmeniz bu göçün ve zorluklarının benimsenmesi açısından çok faydalı olacaktır. Önem sırasına göre;

  • Siber güvenlik,
  • Firma-ürün bağımlılıklarından kurtulmak, (vendor-lockin) (altyapınızı kolayca taşıyabilme)
  • Kendi kurumuna ait yetkin personel yetiştirmek,
  • Fiyat / Performans şeklinde sıralanmaktadır.

Kurumsal e-posta sistemi dönüşümünde temel olarak aşağıdakiler hedeflenmektedir:

  • İşletme / toplam sahip olma maliyetinin düşürülmesi,
  • Kurumun iş süreçlerinin e-posta sistemine bağımlı olmasından kaynaklanan riskin azaltılması,
  • Kullanılan servis yazılımlarında üretici bağımlılığından kurtulmak,
  • Operasyonel etkinliğin artırılması,
  • Kurumsal e-posta servisinin diğer servisler ile birlikte çalışabilirliği noktasında esnekliğin artırılmasıdır.

Kurumsal e-posta sistemi göçü analizi yapılırken aşağıdaki sorulara yanıtlar bulunmalıdır.

  • İşin yapılması ile ilgili teknik gereksinimler; Kurum tarafından kullanılan e-posta yazılımındaki işlevler ve bu işlevlerin kurumsal işin yapılmasındaki öneminin ne olduğu,
  • Yasal gereksinimler; Kurumsal e-postalardaki üst verilerin ve e-posta kutusunun (erişim tarih bilgiler, okundu bilgileri, e-posta içeriği vb.) saklanma sürelerinin ne kadar olduğu,
  • Kullanılan e-posta sistemi bileşenlerinden göçe tabi tutulacak kısmı; Takvim davetleri, notlar, adres defterleri, dağıtım listeleri gibi unsurların hangilerinin göç planına ekleneceği,
  • E-posta verilerinin depolanması için gereken depolama alanının ne kadar olduğu,
  • E-posta verilerinin saklama sürelerinin ne kadar olduğu,
  • Kullanıcı verileri taşınma planının ne olduğu,
  • Herhangi bir kesinti durumunda dayanılabilecek sürenin ne kadar olduğu,
  • Kullanıcıların e-posta mesajlarını okuması için kullanılan istemcilerin neler olduğu,
  • Aktarma (relay) hakkı verilen cihazlar ve bunların ağ bilgilerinin ne olduğu,
  • Kimlik doğrulama yöntemlerinin neler olduğu,
  • Kullanıcılarla ilgili kota tanımlamalarının neler olduğu,
  • Felaket kurtarma, yedekleme, yük dengeleme gibi kurumsal mimari isteklerinin neler olduğudur.
Bir e-posta sistemi göçü aşağıdaki adımlardan oluşmalıdır:

  • Analiz ve Değerlendirme

  • Kavram Kanıtlama Çalışması

  • Pilot Tasarım Kurulum ve Göç Testleri

    • Altyapısal isterlerin karşılanması için gerekli servis yazılımlarının seçimi,
    • İlk testlerin yapılması,
      • Bir kullanıcı verisinin (e-posta kutusu) pilot sisteme taşınması uygulaması,
      • Bir dağıtım listesi verisinin pilot sisteme taşınması uygulaması,
    • Pilot sistem ile kurumun kullanmakta olduğu anti-spam, anti-virüs geçitlerinin birlikte çalışırlığının test edilmesidir.
  • Yaygınlaştırmanın yapılması
    • Kullanıcı ve dağıtım listesi verilerinin oluşturulacak sisteme aktarımı için gerekli otomasyon çözümlerinin hazırlanması,
    • Canlı sisteme dahil edilecek sunucunun ve servis yazılımlarının kurulması,
    • Kurumsal mimari isteklerin tamamlanması,
    • Kullanıcı verilerinin aktarımı,
    • Sistemi işletmeye alma planlaması,
    • Sistem testleri,
    • Regresyon testleri,
    • Başarı ölçütleri ve testleri
    • İşletmeye alma öncesi kullanıcı veri aktarımının artımlı olarak tekrarı
    • Sistemin işletmeye alınması,
    • Sistem başarım takibinin yapılmasıdır.

5.1.1   Kurumsal e-posta Dönüşümünde Riskler

Kaynak sistemin kapalı kod ve üretici bağımlı olmasından kaynaklı olarak e-posta hesaplarına ait parolaların ve kullanıcı e-posta kutularının hedef sisteme aktarma noktasında oluşabilecek riskleri barındırmaktadır. Örneğin bir e-posta sisteminin, ÖY/AKK sistemine göçüne ilişkin aşağıdaki tablo kullanılabilir.

Örnek E-posta Göçü Etki-Olasılık Tablosu(Şiddet En yüksek 5, En düşük 1’dir)
Risk tanımı Olasılık Şiddet Risk Puanı Önlem Tepki Risk Sorumlusu
Hizmet kesintisi 0,2 3 0,6 Faaliyetler e-posta uygulamalarının daha az yoğun olduğu zaman planlanmalı Riski kabul et Bilgi İşlem Ağ Birimi
Uyumsuz veri 0,3 4 1,2 Veri uyumluluğu analiz aşamasında denetlenmeli Riski hafiflet (Verileri dönüştürmek için bir yazılım geliştirmek) VTYS Birimi
Sistem yöneticilerinin eğitim yetersizliği 0,4 4 1,6 Sistem Yöneticisi eğitimi planlanmalı Riski Transfer et (Bakım ve Destek temin edilmeli) İnsan Kaynakları Birimi

Sık kullanılan e-posta hizmet yazılımlarının eşdeğerlilik tablosu aşağıdaki gibidir:

Örnek Yazılım Eşdeğerlilik Tablosu
Hizmet Açıklaması Mevcut Sistem Eşdeğer Sistem
E-Posta Sunucusu Microsoft Exchange Zimbra, OpenExchange, Postfix+Dovecot+Caldav+Carddav+Webmail

Örnek bir karşılaştırma tablosu şu şekilde olabilir:

Örnek Karşılaştırma Tablosu
S/N İşlev Alternatif A Alternatif B Varolan Sistem
1 Ortak adres defteri uygulaması Var Var Var
2 Ortak takvim uygulaması Var Var Var
3 Akıllı telefon ve tabletlere, Microsoft Outlook ve Mozilla Thunderbird gibi farklı istemcilerle temel e-posta hizmeti Var Var Var
4 Başka bir kişi ya da grup adına e-posta gönderme Var Var Yok

Dönüşüm planınızı yaparken ilk ihtiyacınız neyi amaçladığınıza karar vermek sonrasında alternatiflerinizi teknik olarak değerlendirmek ve bu kararlardan çıkan sonuçlara göre kabul edilebilirlik tablosu, riskleriniz, etki-olasılık tablosu gibi öngörülerinizi ortaya koyabilmeniz gerekir. Yukarıdaki tablolara benzer şekilde;

  • Kurum kazanımlarını,
  • Mevcut sistemden geçilmek istenen sistemi,
  • Mevcut sistem ve yeni kurulması planlanan sistem arasındaki halihazırdaki ve geçişten sonra kullanabilecek fonksiyonların tablosunu, (Kabul edilebilirlik tablosu),
  • Yeni sisteminin yedeklilik yapısı ve yedekleme güvenlik prosedürlerini,
  • Risklerini,
  • Etki-olasılık tablosu oluşturulmalıdır.

Bunların yanında yeni e-posta sisteminiz hazır olduğunda test veya geçiş aşamasında iki sistemin beraber mi kullanılacağı yoksa tek seferde eski sistem terkedilip yeniye mi geçileceği gibi durumları olabildiğince önceden belirlenmeniz faydanıza olacaktır. Örneğin; halihazırda kullanılan bir Microsoft Exchange sunucudan Zimbra Collaboration sistemine geçmek istediğinizi düşünürsek; aynı alan adını iki sunucu ile yönetebilecek şekilde yapılandırma yapmanız gerekir ki Zimbra sunucu üzerinde olan bir e-posta kutusuna e-posta geldiğinde Exchange sunucusu bu e-posta kutusunun Zimbra sunucu üzerinde olduğunu bilsin ve tersi de mümkün olsun. Böylelikle canlı çalışan bir Zimbra sunucuya istediğiniz hesapları taşıyarak test kullanımı yapabilirsiniz.

Kullanıcıların tamamının tek seferde geçeceği bir senaryo için ise genelde tavsiye edilen eski sunucunuzun imap/pop3 bağlantılarını keserek e-posta alışverişini sonlandırmak ancak kullanıcıların verilerini görebilmelerini sağlamak için arayüzüne erişimi açık bırakarak tüm e-posta trafiğini yeni sisteminiz üzerinden devam ettirmektir. Böylelikle kullanım dışı olma sürenizi neredeyse sıfıra indirip, eski verilerin tamamı yeni sisteminize tamamen taşınmamış olsa bile servisi çalışır tutup bu süre içinde de eski verilerinizi yeni sisteminize aktarabilirsiniz.

5.2   DHCP Hizmeti Dönüşümü

Diğer servis göçlerine göre DHCP hizmeti göçü yapısı gereği daha hızlı ve kolaylıkla yapılabilen bir göç olarak değerlendirilebilir. Özellikle maliyet, yazılım - donanım olarak verimlilik ve ağ düzeyinde (TCP/IP) bir servis olması nedenleri ile genellikle dönüşüm projelerinde ilk adımda yapılabilecek olan göç şeklinde karar alınabilmektedir.DHCP hizmetinin dönüşümünde temelde aşağıdakiler hedeflenmiştir:

  • İşletme/toplam sahip olma maliyetinin düşürülmesi,
  • Kurumun yerel ağının DHCP hizmetine bağımlı olmasından kaynaklanan riskin azaltılması,
  • Kullanılan servis yazılımlarında ve işletim sisteminde üretici bağımlılığından kurtulunması,
  • Operasyonel etkinliğin artırılması,
  • DHCP hizmetinin diğer servisler ile birlikte çalışabilirliği noktasında esnekliğin artırılmasıdır.

DHCP hizmeti dönüşüm analizi yapılırken aşağıdaki sorulara yanıtlar bulunmalıdır;

  • Kurumsal işin yapılması ile ilgili teknik gereksinimler; Kurum tarafından kullanılan DHCP yazılımındaki işlevler ve bu işlevlerin kurumsal işin yapılmasındaki öneminin ne olduğu,
  • Yasal gereksinimler; kiralanan IP adreslerinin kurum envanterinde kayıtlı bilgisayar MAC kimlikleri ile eşleştirilerek kiralama kayıtlarının tutulması ve eğer varsa bu kayıtların kurum merkezi kayıt sunucusuna belirli kurallar çerçevesinde aktarımının nasıl olacağını,
  • Kullanılan DHCP sisteminde yapılmış yapılandırmaların dışa aktarılmasının nasıl olacağını(Her IP havuzu için ayrı ayrı olmak üzere),
    • MAC kimliklerine göre yapılan sabit IP atamaları,
    • Dağıtım bloğu bilgisi [başlangıç - bitiş IP adresi aralığı],
    • Ağ adresi (network),
    • Alt ağ maskesi (netmask),
    • Ağ geçidi (gateway),
    • Varsa atanabilecek diğer özellikler (DNS, PXE Boot Sunucusu vb.),
    • Statik IP atanacak mac adreslerinin tanımlanması,
  • Varsa kurumda kullanılan 802.1x ve Ağ Erişim Kontrolü (NAC) çözümleri ile DHCP servisi bağıntılarının ortaya konması,
  • Herhangi bir kesinti durumunda dayanılabilecek sürenin ne kadar olduğu,
  • Felaket kurtarma, yedekleme, yük dengeleme gibi kurumsal mimari isteklerin neler olduğunun yanıtlanmasıdır.

DHCP sistemi göçü aşağıdaki adımlardan oluşmalıdır:

  • Analiz ve Değerlendirme

  • Kavram Kanıtlama çalışması

  • Pilot Tasarım Kurulum ve Göç Testleri

    • Altyapısal isterlerin karşılanması için gerekli hizmet yazılımlarının seçimi,
    • İlk testlerin yapılması,
      • Bir IP havuzu bilgisinin pilot sisteme tanımlanması,
    • Pilot sistem ile kurum ağının bir bölümünün ilişkilendirilmesi, kurumsal kablolu ve kablosuz ağlarda çalışırlığın test edilmesidir.

  • Yaygınlaştırmanın Yapılması

    • Eski sistemden alınmış yapılandırma bilgileri ile yeni sistemde kullanılacak yapılandırmanın üretilmesi,
    • Canlı sisteme dahil edilecek sunucunun ve servis yazılımlarının kurulması,
    • Kurumsal mimari isteklerin tamamlanması,
    • Üretilmiş yapılandırmanın yeni DHCP sistemine uygulanması,
    • Sistemi işletmeye alma planlaması,
    • Sistem testleri,
    • Regresyon testleri,
    • Başarı ölçütleri ve testleri
    • Sistemin işletmeye alınması,
    • Sistem başarımının takibinin yapılmasıdır.

DHCP servisi göçünde riskler aşağıda sıralanmıştır;

  • Kaynak sistemin kapalı kod ve üretici bağımlı olmasından kaynaklı olarak yapılmış yapılandırmaların dışa aktarımında sorunlarla karşılaşılabilir.
  • Kurumsal NAC çözümünün RFC standartlarının dışına olan uyumsuz anons talepleri olabilir.
  • Hizmet kesintisi olabilir.
  • Statik Ip tanımlarının eksik veya yanlış yapılabilir, IP çakışması olabilir.

5.3   Dosya Sunucusu Hizmeti Dönüşümü

Dosya sunucusu göçü, bilgi işlem birimlerinin maliyet, verimlilik ve sunulan dosya sunucusu hizmetlerinin geliştirilmesi gibi nedenlerle aldığı dönüşüm kararı çerçevesinde gerçekleştirilmektedir. Dosya sunucusu göçünde temel olarak aşağıdakiler hedeflenmektedir:

  • İşletme/toplam sahip olma maliyetinin düşürülmesi,
  • Kurumun iş süreçlerinin belirli bir işletim sistemine bağımlı olmasından kaynaklanan riskin azaltılması,
  • Üretici bağımlılığından kurtulunması,
  • Operasyonel etkinliğin artırılması,
  • Kurumsal dosya paylaşımı hizmetinin diğer servisler ile birlikte çalışabilirliği noktasında esnekliğin artırılması,
  • Kurumsal dosyalara yetkisiz erişim, paylaşım ve değiştirilme işlemlerinin engellenmesi, raporlanması, kurumsal belgelerin erişilebilirliğinin, bütünlüğünün ve erişilebilirliğinin sağlanmasıdır.

Kurumsal dosya sunucusu dönüşüm analizi yapılırken aşağıdaki sorulara yanıtlar bulunmalıdır;

  • Kurumsal işin yapılması ile ilgili teknik gereksinimler; Kurum tarafından kullanılan dosya sunucusu işlevleri ve bu işlevlerin kurumsal işin yapılmasındaki öneminin ne olduğu,
  • Yasal gereksinimler; bazı durumlarda dosyaların oluşturulma zamanları, dosyayı yaratan kişi, paylaşma zamanı gibi bilgiler kritik öneme sahip olabilmektedir. Bu nedenle dosya sunucusu aynı zamanda geriye dönük olarak bu tip bilgilerin ne kadar süre saklanması gerektiği,
  • Dosya sunucusunda saklanan veriler için gereken depolama alanının ne kadar olduğu,
  • Verilerinin saklama sürelerinin ne kadar olduğu,
  • Kullanıcı verilerinin taşıma planının ne olduğu,
  • Herhangi bir kesinti durumunda dayanılabilecek sürenin ne kadar olduğu,
  • Kullanıcıların dosyalara erişim için varsa programların neler olduğu,
  • Kimlik doğrulama yöntemlerinin neler olduğu,
  • Kullanıcılarla ilgili kota tanımlamalarının ne kadar olduğu,
  • Felaket kurtarma, yedekleme, yük dengeleme gibi kurumsal mimari isteklerin neler olduğu,
  • Kurumsal dosyaların, kim tarafından ve kiminle paylaşılması konusundaki güvenlik gereksinimlerinin neler olduğu soruları için yanıtların alınması gerekmektedir.

Bir dosya sunucusu göçü aşağıdaki adımlardan oluşmalıdır:

  • Analiz ve Değerlendirme
  • Kavram Kanıtlama Çalışması
  • Pilot Tasarım Kurulum ve Göç Testleri
    • Altyapısal isterlerin karşılanması için gerekli ÖY/AKKY’ın seçimi
    • İlk testlerin yapılması
      • Bir kullanıcı verisinin pilot sisteme taşınması,
      • Kullanıcının dosya paylaşımı, erişimi gibi işlevlerin kontrol edilmesi,
      • Dosya sunucusunda geriye dönük yapılan işlemlerin takibi ve kontrolü,
      • Bir kullanıcı grubunun ortak dosya paylaşım ve kullanım sistemine entegre edilmesidir.
  • Yaygınlaştırmanın yapılması
    • Kullanıcı dosyalarının yeni dosya sunucusuna aktarımı için gerekli otomasyon çözümlerinin hazırlanması,
    • Kurumsal mimari isteklerin tamamlanması, ortak dosyalara erişim, paylaşım ve güvenlik isterlerinin belirlenmesi,
    • Sistemi işletmeye alma planlaması,
    • Sistem testleri,
    • Başarı ölçütleri ve testleri,
    • Sistemin işletmeye alınması,
    • Sistem başarımının takibinin yapılmasıdır.

Kurumsal dosya sunucusu dönüşümünde riskler;

  • Özellikle kullanıcı hakları ile ilgili otomasyon çalışmasının yapılmaması neticesinde riskler oluşabilmektedir.

Aşağıda örnek olarak yapılan karşılaştırma tablosu sunulmaktadır:

Dosya Sunucusu Örnek Özellik Karşılaştırma Tablosu
S/N Özelllik NextCloud OwnCloud FSRM
1 Dosya Depolama Var Var Var
2 Dosya Paylaşımı Var Var Var
3 Fulltext Arama Var Var Yok
4 Dizin Paylaşma Var Var Var
5 LibreOffice Online entegrasyonu Var Var Yok
6 PDF Gösterici Var Var Yok
7 Fotoğraf Galerisi Var Var Yok
8 Doküman üzerinde birlikte çalışabilme Var Yok Sharepoint ile
9 Dosyalar için Faaliyet takibi Var Var Var (event log)
10 Büyük Dosya Desteği Var Var Var
11 Kullanıcı Kota Desteği Var Var Var
12 Dosya erişim Kontrolü Var Var(Kurumsal Versiyonda) Var
13 Web Arayüzü Var Var Yok
14 Windows, Mac, Linux ve Mobil desteği Var Var Yok
15 Uygulama Dükkanı Var Var Yok
16 Sesli ve Video görüşmeleri Var Var Yok
17 Takvim Uygulaması Var Var Yok
18 Kontak Uygulaması Var Var Yok
19 E-posta Uygulaması Var Var Yok
20 Notlar Var Var Yok
21 2 Seviyeli Kimliklendirme Var Var 3.parti yazılımlarla
22 Kaba Kuvvet Saldırı Engelleme Var Var 3.parti yazılımlarla
23 API Var Var Yok
24 Kullanıcı Grupları Oluşturulması Var Var ADDS desteği ile
25 ADDS Entegrasyonu Var Var Var
26 Rol Tabanlı Yönetim Var Var ADDS desteği ile
27 Versiyonlama Var Var Yok

5.4   Web Sunucusu Hizmeti Dönüşümü

Web sunucusu göçü, bilgi işlem birimlerinin maliyet, verimlilik, sunulan web sunucusu hizmetlerinin geliştirilmesi ve gelişmiş güvenlik önlemlerinin alınabilmesi gibi nedenlerle aldığı dönüşüm kararı çerçevesinde gerçekleştirilmektedir. Web hizmetinin dönüşümünde temelde aşağıdakiler hedeflenmiştir:

  • İşletme/toplam sahip olma maliyetinin düşürülmesi,
  • Kurumun Web sunucuları üzerinden olabilecek saldırılara karşı güvenliklerinin artırılması,
  • Kullanılan servis yazılımlarında ve işletim sisteminde üretici bağımlılığından kurtulmak,
  • Operasyonel etkinliğin artırılması,
  • Web hizmetlerinin devamlılığının sağlanmasıdır.

Web hizmeti dönüşüm analizi yapılırken aşağıdaki sorulara yanıtlar bulunmalıdır:

  • Kurumsal işin yapılması ile ilgili teknik gereksinimler; kurum tarafından kullanılan web sitelerindeki işlevler ve bu işlevlerin kurumsal işin yapılmasındaki öneminin ne olduğu,
  • Yasal gereksinimler; web sitelerine erişim bilgilerinin kaydedilmesi, olası saldırılara karşı alınacak faaliyetlerin desteklemesi için nelerin yapılacağı,
  • Kullanılan Web sitelerinde yapılmış yapılandırmaların dışa aktarılmasının nasıl olacağı,( Her Web sitesi için ayrı ayrı olmak üzere)
    • Web sitesinin yazılımsal gereksinimlerin neler olduğu, ( Php, Java .Net )
    • Web sitesi içeriğinin ve yardımcı programların güncellenebilmesi, güncel olmayan yazılımlara uyumsuz içeriklerin tespit edilmesi,
    • Herhangi bir kesinti durumunda dayanılabilecek sürenin ne kadar olduğu,
    • Felaket kurtarma, yedekleme, yük dengeleme gibi kurumsal mimari isteklerin neler olduğudur.

Web sunucusu göçü aşağıdaki adımlardan oluşmalıdır:

  • Analiz ve Değerlendirme
  • Kavram Kanıtlama çalışması
  • Pilot Tasarım Kurulum ve Göç Testleri
    • Altyapısal isterlerin karşılanması için gerekli hizmet yazılımlarının seçimi
    • İlk testlerin yapılması
      • Bir web sitesinin açık kaynaklı web sunucusu üzerinden hizmet vermesi
      • Pilot web sitesi üzerinde, öncelikli olarak yönetici ve pilot ekibin erişim, yönetim, içerik güncelleme işlemlerinin yapılması.
  • Yaygınlaştırmanın yapılması
    • Eski sistemdeki Web sitesinin, yeni sistemde aynı işlevlere sahip olacak şekilde taşınması, varsa diğer etkileştiği sistemlere ( DB, Firewall ) gereken tanımlarının yapılması,
    • Web sitesinin yeni sistemde yaşayabileceği uyumsuzlukların giderilmesi,
    • Sistemi işletmeye alma planlaması,
    • Sistem testleri,
    • Regresyon testleri,
    • Başarı ölçütleri ve testleri,
    • Sistemin işletmeye alınması,
    • Sistem başarımının takibinin yapılmasıdır.

Web sunucusu hizmeti dönüşümünde riskler aşağıda sıralanmıştır:

  • Kaynak sistemin kapalı kod ve üretici bağımlı olmasından kaynaklı olarak yapılmış yapılandırmaların dışa aktarımında sorunlarla karşılaşılabilir.
  • Kaynak sistem açık kaynak web dillerine uyumlu olmayabilir.
  • Kaynak sistem, güncel web dillerine uyumsuz içerik barındırabilir.

5.5   Veritabanı Hizmeti Göçü

Veritabanı en genel tanımıyla, kullanım amacına uygun olarak düzenlenmiş veriler topluluğudur. Birbirleriyle ilişkileri olan verilerin tutulduğu, mantıksal ve fiziksel olarak tanımlarının olduğu bilgi depolarıdır. Veritabanları gerçekte var olan ve birbirleriyle ilişkisi olan nesneleri ve ilişkileri modeller. Günümüzde kullanıcı ihtiyaçlarına göre farklı veritabanı türleri bulunmaktadır: İlişkisel veritabanları, NoSQL veritabanları, Grafik tabanlı veritabanları bunlara birkaç örnektir. İlişkisel veritabanlarına örnek olarak, açık kaynak kodlu en yaygın veritabanı olan PostgreSQL verilebilir.

Bununla beraber Veritabanı Yönetim Sistemleri (VTYS); bahsedilen veritabanlarının yönetimi için kullanılan sistemlerdir. Her veritabanının yapısı ve yönetim şekilleri birbirinden farklıdır. Modern VTYS’lerde genel olarak aşağıdaki bileşenler bulunmaktadır;

  • View’lar; Üzerinde veri depolanmayan sanal tablolardır. Veritabanı sorgulamalarını hızlandırmak için kullanılabilir. Bazı VTYS’de ek güvenlik katmanı olarak da kullanılabilmektedir
  • Tetikleyiciler; Veritabanlarında bir tabloya bağlı olarak bir takım işlemler yapan küçük kod parçalarıdır.
  • Kullanıcı tanımlı fonksiyonlar ve Saklı Prosedürler; Kullanıcılar tarafından oluşturulan ilişkisel veritabanı nesneleridir. Oluşturulan fonksiyonlar, “select” ifadelerinin içinde kullanılabilirken, depolanan prosedürler kullanılamaz.

Modern VTYS’lerde genel olarak aşağıdaki özellikler bulunmaktadır;

  • Transaction desteği; Bir işlemin yapılması sırasında birden fazla SQL sorgusunun belli bir düzen içerisinde doğru ve tam olarak çalışması sonucu onaylanması veya işlemlerden herhangi birisinin tamamlanamaması durumunda yapılan diğer işlemlerin de iptal edilmesi şeklindedir. Veritabanı üzerindeki bir işlemin tam olarak yapılmasını ya da hiç yapılmamasını güvence altına almak için kullanılan bir özelliktir.
  • ACID desteği; VTYS’nin, işlemin tamamlanması ya da iptal olması (Atomicity), konulan transaction kurallarının tamamını başarılı olarak gerçekleştirmesi veya herhangi bir adımı gerçekleştiremediği durumda tüm transaction işleminin iptal etmesi (Consistency), herhangi bir transaction tüm adımları tamamlanana kadar diğer herhangi bir transaction tarafından yapılmış olan işlemlerin görünememesi (isolation), onaylanan ve işlenen (commit) bir transaction sonucunda verilerin bir depolama alanına yazılması ve olası sistem hatalarından korunması (durability) özelliklerine sahip olmasıdır.
  • Kayıt noktaları (savepoint); Transaction yönetiminde Savepoint denilen saklama notları tanımlanabilir olmalıdır. İşlem birden fazla olduğu zaman başarıyla sonuçlanan her iş parçacığının bitiş noktasını kayıt noktası olarak işaretleyerek, özellikle karmaşık veritabanı sistemlerinde geri dönüş (rollback) işleminin yükünü hafifletir. ya da belirli senaryolara göre tanımlanmış kayıt noktalarına geri dönülmesi istenebilir.
  • Yedekleme ve kurtarma.
  • Güvenlik ve Yetkilendirme.
  • Sorgu Optimizasyonu.

Günümüzde hemen her yazılım dilini destekleyecek şekilde VTYS’ler bulunmaktadır. En sık kullanılan VTYS’lere ait kullanım oranları ve sıralamaları aşağıdaki tabloda verilmektedir [SolidIT2018] .

VTYS’ne Ait Kullanım Oranları ve Sıralamaları Tablosu
S/N VTYS Lisanslama VT Modeli Skor
1 Oracle Ticari İlişkisel 1319.27
2 MySQL İkili Lisanslama (Ticari ve GPL uyumlu) İlişkisel 1178.12
3 Microsoft SQL Server Ticari İlişkisel 1058.33
4 PostgreSQL PostgreSQL lisansı (BSD ve MIT Türevi) İlişkisel 419.39
5 MongoDB İkili Lisanslama (Ticari ve Server Side Public License/GNU AGPL v3.0) Belge Deposu 363.19
6 DB2 Ticari İlişkisel 179.69
7 Redis BSD Lisans türevi Key&Values 145.29
8 Elasticsearch İkili Lisanslama (Ticari ve Apache 2.0 ile Elastic Lisansı) Arama Motoru 142.33
9 Microsoft Access Ticari İlişkisel 136.80
10 Cassandra Apache License 2.0 Wide Sütun Deposu 123.39

5.5.1   ÖY/AKK Veri Tabanı Yönetim Sistemleri(VTYS)

Yukarıda bahsedilen tablodan hareketle, 2 önemli ÖY/AKK VTYS bulunmaktadır.

5.5.1.1   MySQL

MySQL, açık kaynak kodlu ilişkisel veritabanı yönetim sistemidir. MySQL AB şirketinden Oracle şirketine satılmasından dolayı kullanıcı kaybına uğrasa da en çok kullanılan ÖY/AKK VTYS’lerin başında gelmektedir. Özellikle web sunucularında LAMP olarak bilinen (Linux, Apache, MySQL, Perl/PHP/Python) yazılımlarının içerisinde kullanılır. Joomla, WordPress, phpBB, ve Drupal gibi yazılımlar ile birlikte yaygın olarak kullanılmaktadır. Bununla beraber, Facebook, Google (arama motoru hariç), Twitter, Flickr ve YouTube gibi web sitelerinin altyapısında kullanılmaktadır.

5.5.1.2   PostgreSQL

PostgreSQL, açık kaynak kodlu en gelişmiş nesne-ilişkisel veritabanı yönetim sistemidir. Geçmişi, 1986 tarihli California Üniversitesi’ndeki Postgres projesine dayanmaktadır. Kendisini kanıtlamış olan güçlü yapısı, zengin özellikleri, mimarisi, güvenilirliği, eklentileri ile özellik setinin genişletilebilirliği ve güçlü topluluk desteği ile iyi bir itibara sahiptir. Özgür lisans yapısı ve yetenekleri ile çok sayıda ticari ürünün içerisinde bütünün bir parçası olarak kullanılmaktadır. Aynı zamanda özgür lisansı sayesinde Oracle’dan göç için uyumluluk ve kolaylaştırıcı araçlar, bulut ortamı veya büyük veri özelinde yapılan özelleştirmeler gibi özel amaçlı olarak çeşitli alanlarda farklılaşmış bir çok açık kaynaklı ve ticari dağıtımları da bulunmakta ve açık kaynak kod topluluğuna katkı sağlamaktadır. Bunlardan bazıları için EnterpriseDB Postgres Advanced Server, Amazon Redshift, Yahoo Everest, AgensGraph, Greenplum Database, HadoopDB, FUJITSU Enterprise Postgres, ToroDB örnek verilebilir.

PostgreSQL ANSI SQL uyumluluğu ve PL/pgSQL dilinin yetenekleri sayesinde birçok VTYS’nden göç edilmesi sürecini kolaylaştırmakta, yazılımcılar açısından PL/SQL ve PL/pgSQL’in birbirine olan yakınlığı, mimarisinin güvenilirliği ve veritabanı yöneticileri için yapısal benzerlikleri Oracle VTYS’nden göç etmek istendiğinde ilk akla gelen seçeneğin PostgreSQL ve dağıtımlarının olmasını da sağlamaktadır. Göç sürecinde izlenecek olan metodoloji bir sonraki başlıkta açıklanmak ile birlikte, canlı sistemlerde yapılacak olan geçişlerde geçiş risklerini azaltmak ve geçiş sürecini kısaltmak için diğer ticari PostgreSQL dağıtımları ve araçları da kullanılabilmektedir.

5.5.2   VTYS Göç Metodolojisi

Veritabanı yönetim sistemleri göçü, Bilgi işlem birimlerinin her zaman karşılaşmadıkları ve uzmanlık isteyen bir çalışmadır. Dolayısı ile, veritabanı teknolojilerinin göç analizlerinin yapılması yeterli bilgi birikimi ve tecrübe gerektirmektedir. Veritabanı göç programlarının belirli bir plan dahilinde yapılmaması, geri dönüşü de her zaman mümkün olmadığından kurumsal işin gerçekleştirilmesi açısından yıkıcı etkileri olabilmektedir.Bir veritabanı göçünden hedeflenenler aşağıdaki gibidir;

  • İşletme/toplam sahip olma masraflarının düşürülmesi,
  • Veritabanı yapısının işin yapılmasına (business) ait risk oluşturmasının azaltılması,
  • Kurumsal veritabanı çeşitliliğinden kurtulunması,
  • Üretici bağımlılığından kurtulunması,
  • Operasyonel etkinliğin artırılması,
  • Birlikte çalışabilirlik için esnekliğin artırılmasıdır.

Bir VTYS göçü analizinde aşağıdaki bilgiler toplanmalıdır;

  • Sunucu mimarisi;
  • Sunucu donanım bilgileri, sanal/fiziksel, Çekirdek sayısı,
  • Replikasyon,
    • Replikasyon var mı?
    • Replikasyon türü,
    • Replikasyon yapılan sunucu sayısı,
    • Replikasyon sunucuların sanal/fiziksel işlemci çekirdeği sayısı,
    • Bulut ortamına replikasyon var mı?

  • Yedekleme/Felaket Kurtarma

    • Yedekleme politikası
    • Ortalama yedek boyutu
    • Yedeklerin saklanma süreleri
    • FKM(Felaket Kurtarma Merkezi) ile ilgili bilgiler

  • Diğer Sunucular ile Etkileşimleri

    • Göçe konu VTYS başka bir VTYS ile hibrit çalışıyor mu?

  • Bağlı bulunduğu uygulama ile ilgili bilgiler;

    • Uygulama kodlarına erişim
    • Uygulamanın veritabanı bağımlılığı
    • Uygulama dili
    • Uygulama içerisinde gömülü SQL cümlecikleri ve ara katman yapısı
    • Uygulama VTYS bağlantı yöntemleri

  • Yapılandırma ayarları

    • Toplam saklı yordam sayısı
    • En uzun prosedür satır sayısı
    • Toplam fonksiyon sayısı
    • En uzun fonksiyon satır sayısı
    • Toplam trigger sayısı
    • En uzun trigger satır sayısı
    • Veritabanı adı, sürüm bilgisi
    • Toplam VT boyutu
    • Kullanıcı rolleri
    • Özel veri yapıları kullanımı (GIS vb)

  • VTYS güvenlik bileşenleri

    • Yetkilendirme
    • VTYS güvenlik duvarı
    • VTYS kayıtları, saklanma politikası, alarm vb. konuları

  • Bakım/Destek konuları

    • Bakım sözleşmesi ve süresi
    • Destek alınan paydaş bilgisi

  • Göç edilecek ÖY/AKK VTYS alternatiflerinin değerlendirmesi

  • Göç edilecek ÖY/AKK VTYS’nin kurumsal isteklere göre seçimi

  • Riskler ve risk azaltma stratejileri

Bir veritabanı göç planı aşağıdaki adımlardan oluşmalıdır;

  • Analiz ve değerlendirme
  • Kavramın ispatlanması
  • Tasarım, kurulum, göç ve testlerin yapılması
    • Altyapısal kurulum ve gereksinimlerin tespiti
    • İlk testlerin yapılması ve detaylı çözümlerin oluşturulması
    • Veritabanı göçünün yapılması
    • Uygulama göçü
    • Birim testleri
    • Sistem testleri
    • Regresyon testleri
    • Başarı ölçütleri ve testleri
    • Donanım talepleri
    • Kullanıcı kabul testleri
  • Sistemi işletmeye alma planlaması
  • Sistemin işletmeye alınması
  • Sistem başarımının takibinin yapılmasıdır.

Veritabanı göçü için uygun olabilecek uygulamalar genel olarak şunlardır;

  • Kurum içi geliştirilmiş yazılımlar,
  • Üretici tarafından sağlanan kurumsal çözüm paketleridir.

Bununla beraber üretici tarafından sağlanan uygulama paketlerinde teknoloji göçü için aşağıdaki riskler mevcuttur;

  • Üretici veritabanı göçünü tavsiye etmiyor, belgelendirmiyor veya destek vermiyor olabilmektedir.
  • Kaynak kodun sahipliği üreticinin kendisinde ve lisans kısıtlamaları nedeniyle paylaşmıyor olabilmektedir.

5.6   Dizin Hizmetleri Dönüşümü

Kurumsal yapılarda, kimlik doğrulama tüm servisler için önemli ve ortak bir kaynak olduğundan, bu dönüşüm sürecinin ayrıntılı olarak planlanması çok önemlidir. Özellikle çok sayıda kullanıcısı olan kurumlarda var olan kullanıcı parolalarının dönüşüm sırasında korunması, oluşabilecek kullanıcı tepkilerini en aza indirmenin de yoludur.

Ülkemizde, LDAP (Lightweight Directory Access Protocol) temelli olan Microsoft Aktif Dizin (AD) hizmeti kurumsal yapılarda yaygın olarak kullanılmaktadır. Bu yapı bünyesinde, DNS, güvenlik politikaları, dosya paylaşımları erişim yetkilendirmesi gibi yaygın kullanılan hizmetleri de entegre olarak barındırmaktadır.

Linux türevi işletim sistemlerinde güvenlik politikaları Microsoft Windows tabanlı işletim sistemlerinden farklı çalışmaktadır. İstenilen güvenlik politikalarının Linux işletim sistemi üzerinde yeniden yapılandırılması gerekmekle birlikte bu yapılandırmaları LDAP ya da AD yapısı üzerine ayrıca bağlamak da mümkündür. Örneğin; USB isimli bir AD grubu tanımlayıp, bu grubun üyesi olan kullanıcılara yerel sunucu üzerinde USB aygıt kullanma hakkı tanımlanabilmektedir.

Sistem yönetimi ve güvenlik için oluşturulan politikaları destekleyen Microsoft Windows işletim sistemleri için hazırlanan politikaları Samba ile ağa yaymak mümkündür.

Microsoft AD yapısından, OpenLDAP ya da benzeri bir LDAP hizmet sunucusuna geçilmesi mümkündür. Aktif dizin göç işlemlerinde, istemci güvenliği açısından SASL desteği olması gerekmektedir. Microsoft AD yapısı içerisinde tek yönlü şifrelenerek tutulan kullanıcı parolaları, diğer LDAP yapılarına aktarılamamaktadır. Bu nedenle, LDAP hizmet sunucusuna geçişlerde tüm kullanıcıların parolalarının yeniden tanımlanması gerekmektedir.

LDAP ile DNS servislerini beraberce çalıştırmak mümkün olmakla birlikte günümüzde bu hizmetlerin yönetimi için geliştirilmiş ÖY/AKK yönetim arayüzü araçlarının yetkinlikleri konusunda eksiklikler olduğu görülmektedir. Bu nedenle genellikle konsol üzerinden yönetilmektedir. Ancak TÜBİTAK tarafından geliştirilen Lider Ahenk ürünü ile bu sorun aşılarak uç bilgisayar yönetimleri de dahil çözüm üretmek mümkün olabilmektedir.

LDAP sistemleri için en basit anlatımla, nitelik (attribute) tabanlı ağaç yapısında küçük veritabanlarıdır ve kendi protokolleri üzerinden sorgulama yapılmasına izin verir. Bu nedenle openLDAP, ApacheDS gibi birçok servis ile Microsoft AD yapısına alternatif oluşturulabilmektedir. LDAP sistemlerinin bütünsel olarak Microsoft AD ile birlikte çalışmaları oldukça zordur. Bu kapsamdaki en yaygın kullanım, openLDAP sistemin vekil (proxy) sunucu olarak yapılandırılıp, kimlik doğrulaması için Microsoft AD sistem ile birlikte çalışması şeklindedir.

Dizin hizmetlerinin ÖY/AKKY’a dönüşüm kapsamında, Microsoft AD yapısına en uygun olan çözümün Samba olduğu görülmektedir. Samba 4 sürümüyle birlikte Microsoft AD yapısına tam uyumlu hale gelmiş, kullanıcı kimlik doğrulaması ile ilgili şemalar Samba ve Microsoft mühendislerinin ortak çalışması sonucunda tam olarak entegre edilmiştir. Ancak Microsoft Exchange veya SharePoint Portal gibi uygulamaların kullandıkları özel şemalar üzerinde hala çalışılması gereklidir. Açıklanan nedenle, Exchange ve SharePoint portal şemaları desteklenmediğinden, Samba sunucuya geçiş yapıldığında bu hizmetler kullanılamaz. Bunun için planlanan göç öncesinde bu sunucuların göçü yapılmalıdır. Bu durumda örnek bir mimari yapı aşağıda sunulmaktadır.

Örnek bir mimari yapı

Şekil: Örnek Bir Mimari Yapı

AD üzerindeki tüm kullanıcı, grup, bilgisayar bilgileri ve bunlara tanımlı olan parolalar ile birlikte Samba altyapısına göç etmek mümkündür. Samba, AD üzerinde Etki Alanı Denetçisi (Domain Controller, DC) olarak kendini tanımlar ve diğer DC sunucularındaki haklarla hizmet verir. Bir kullanıcı bilgisi, dizine dahil herhangi bir DC üzerinde güncellendiğinde (ekleme, çıkarma ya da değiştirme), Samba dahil tüm etki alanı denetçileri otomatik olarak güncellenir. Bu durumda, AD içerisindeki Microsoft DC sunucular kapatılsa bile AD hizmet vermeye devam etmektedir.

Samba, DNS servisleri ile çalışabildiği gibi bütünleşik DNS hizmeti de sunabilir. Bütünleşik DNS hizmeti verecek şekilde yapılandırılmış bir Samba sunucusu, Microsoft AD üzerindeki DNS servisleri ile de çift yönlü çalışmaya devam etmektedir.

Özetle, Microsoft AD üzerindeki tüm kullanıcılar, parolaları ile birlikte uygun şekilde yapılandırılan Samba sunucusuna aktarılarak Microsoft AD sunucular kapatılabilmektedir.

Kurumsal yapı içerisinde Microsoft Exchange veya Sharepoint Portal gibi sistemlerin göçü yapıldıktan sonra AD servisini de Samba üzerine taşıyarak, hem AD üzerinden kimlik doğrulaması yapan diğer uygulamalar kullanmaya devam edilebilir, hem de göç projesinin önündeki en temel engel kaldırılmış olmaktadır.

Aktif dizin hizmeti zaman sunucusuna bağımlıdır. Kimlik doğrulama servisleri doğası gereği zamana bağlı olarak doğrulama hizmeti verir. O nedenle, DC olarak hizmet verecek sunucu ile kimlik doğrulamasını yapacak olan istemcinin saatleri tercihen aynı ya da kabul edilebilir bir farklılıkta olmalıdır. Bu sorunu ortadan kaldırmak için ağa hizmet veren NTP sunucusu kurmak yeterlidir.

5.6.1   Dizin Hizmetleri Dönüşüm Metodolojisi

Dizinler hizmetleri, kullanıcı bilgilerini ve kimlik doğrulama yapısını üstlendiği için, çok dikkatli ele alınması gerekmektedir. En ufak bir hata, tüm diğer işler mükemmel yapılmış olsa bile kullanıcıların sistemlere bağlanıp çalışamaması ile sonuçlanacağından, tüm dönüşüm projesini başarısız kılabilir.

Dizinler hizmetleri dönüşümünden önce mutlaka felaket kurtarma senaryosu hazırlanmalıdır. Mümkünse önceden mevcut sistem verilerini barındıran eş bir ortamı üzerinde çalışmak çıkabilecek sorunları deneyimleme açısından önemlidir. Dizin hizmetlerinde göç ile hedeflenenler aşağıdaki gibidir;

  • İşletme/toplam sahip olma masraflarının düşürülmesi,
  • Mevcut ihtiyaçları karşılayacak yedeklilik ve süreklilik sağlayan sistemler kullanılması.
  • Belirli bir marka bağımlısı sistemlerden kurtulunması,
  • Operasyonel etkinliğin artırılması,
  • Birlikte çalışabilirlik için esnekliğin artırılmasıdır.

Dizin hizmetleri dönüşümü analizinde aşağıdaki bilgiler toplanmalıdır:

  • Sunucu mimarisi,
  • Replikasyon,
    • Replikasyon var mı?
    • Replikasyon türü
    • Replikasyon yapılan sunucu sayısı
    • Replikasyon sunucuların sanal/fiziksel işlemci çekirdeği sayısı
    • Bulut ortamına replikasyon var mı?
  • Yedekleme/Felaket Kurtarma,
    • Yedekleme politikası
    • Ortalama yedek boyutu
    • Yedeklerin saklanma süreleri
    • FKM ile ilgili bilgiler
  • Diğer Sunucularla Etkileşimleri,
    • Göçe konu dizin hizmeti hangi ürünlerle birlikte çalışıyor?
    • Üzerinde ek şema bulunuyor mu?
  • Bağlı bulunduğu uygulama ile ilgili bilgiler,
    • Uygulama kodlarına erişim mümkün mü?
    • Uygulamanın özel şema bağımlılığı var mı?
    • Uygulama dili nedir?
  • Yapılandırma ayarları,
    • DNS hizmeti var mı?
    • DHCP hizmeti var mı?
    • Senkronizasyona özel yapılandırma var mı?
    • Aktif şema çalışma seviyesi nedir?
    • Orman (forest) yapısı var mı?
    • Ayrı site bilgisi var mı?
    • Birden fazla etki alanı var mı?
  • Dizin hizmetleri için güvenlik bileşenleri,
    • Yetkilendirme
    • Güvenlik duvarı ayarları

  • Bakım/Destek konuları,

    • Bakım sözleşmesi ve süresi
    • Destek alınan paydaş bilgisi
  • Göç edilecek ÖY/AKK seçeneklerinin değerlendirmesi,
  • Göç edilecek ÖY/AKK çözümünün kurumsal isteklere göre seçilmesi,
  • Riskler ve risk azaltma stratejileridir.

Bir Dizin Hizmetleri göç planı aşağıdaki adımlardan oluşmalıdır;

  • Analiz ve değerlendirme,
  • Kavramın ispatlanması,
  • Tasarım, kurulum, göç ve testlerin yapılması,
    • Altyapısal kurulum ve gereksinimlerin tespiti
    • İlk testlerin yapılması ve ayrıntılı çözümlerin oluşturulması
    • Göçün gerçekleştirilmesi
    • Birim testleri
    • Sistem testleri
    • Regresyon testleri
    • Başarı ölçütleri ve testleri
    • Donanım talepleri
    • Kullanıcı kabul testleri
  • Sistemi işletmeye alma planlaması,
  • Sistemin işletmeye alınması,
  • Sistem başarım takibinin yapılmasıdır.

Dizin hizmetleri göçü için uygun olabilecek uygulamalar genel olarak şunlardır;

  • Ticari LDAP çözümü kullanılan yapılar,
  • Microsoft AD kullanan yapılardır.

Bununla beraber üretici tarafından sağlanan uygulama paketlerinde teknoloji göçü için aşağıdaki riskler mevcuttur;

  • Microsoft Exchange, Sharepoint gibi patentli şema kullanmayan yapılar,
  • Patentli şema kullanan üçüncü parti yazılımlar.

Aşağıda, Kurumsal aktif dizin hizmetlerinin işlevsel karşılaştırmasını bulunmaktadır:.

Aktif Dizin Hizmetlerinin İşlevsel Karşılaştırma Tablosu
Temel Özellikler Microsoft® AD OpenLDAP Çözümleri LiderAhenk SambaBOX
Yönetimsel Özellikler        
         
Dizin yapısı yönetimi - (Ou ekleme, Group oluşturma..vb) Evet Evet Evet Evet
Linux İstemci Yönetimi Hayır Hayır Evet Evet
Windows İstemci Yönetimi Evet Hayır Evet (Samba 4 entegrasyonu) Evet
Apple macOS® İstemci Yönetimi Hayır Hayır Hayır Evet
Toplu olarak görev gönderebilme Evet Hayır Evet Evet
Anlık istemci offline online durumlarını görebilme Hayır Hayır Evet Evet
Kerberos Desteği Evet Evet Evet Evet
         
Politika Yayma        
         
Windows GPO kullanımı ile politika yayma Evet Hayır Hayır Evet
Linux için Kural Kümesi ile politika yayma Hayır Hayır Evet Evet
Grup ve istemci bazlı görev ve betik gönderebilme. Sonuçlarını anlık olarak görebilme Hayır Hayır Evet Evet
RSAT Uyumluluk Evet Hayır Hayır Evet
         
Kullanıcı Yönetimi Özellikleri        
         
Kullanıcı Yönetimi (Kullanıcı ekleme silme vb.) Evet Evet Evet Evet
Grup ve kullanıcı bazlı betik çalıştırma Evet Hayır Evet Evet
Offline görev ve betik gönderebilme Evet Hayır Evet Evet
Yönlendirilmiş Profil Evet Hayır Evet Evet
         
Diğer        
         
Eklenti Temelli yapı Evet Hayır Evet Hayır
Dinamik raporlama altyapısı Evet Hayır Evet Evet
Günce (log) altyapısı Evet Evet Evet Evet
Entegre DNS Hizmeti Evet Hayır Evet Evet
Cluster yapısı Evet Evet Evet Evet
Ortalama Kurulum Süreleri 30-60 dk 120 dk 10 dk 5 dk
Uzaktan Erişim Desteği Evet Evet Evet Evet
AD Uyumluluğu Evet Hayır Hayır Evet
AD ile Hibrit Çalışabilme Evet Hayır Hayır Evet
AD ile Çift Yönlü Senkronizasyon Evet Hayır Hayır Evet
ACL Yönetimi Evet Hayır Hayır Evet

5.7   Ağ ve Sistem İzleme

Sistem izleme ve ağ başarımının takibi için erişilen bilgiler tamamen sistemi denetim altında tutmak için ihtiyaç duyulan bilgilerle sınırlıdır. Kullanıcıların kurum kaynaklarını kullanarak ürettikleri bilginin içeriğine erişim sağlanmaz.

Bu içeriğe ilişkin veriler ancak yetkili kişiler tarafından erişilebilir olmalıdır. Ağın gerekli yazılımların uzaktan yüklenmesi, işletim sistemleri ve uygulamalar için gereken yamaların kurulması, ağ trafiğinin izlenerek uygulamalar veya donanımdan kaynaklanan sorunların tespiti ve giderilmesi için takip edilmesi gerekir. Güncellemelerin düzenli olarak denetlenmesi, ağa bağlı olan tüm cihazlarda yaşanan sorunların belirlenmesi için anlık olarak izlenmesi ve zaman kaybetmeden sorunların giderilmesi çok sayıda kullanıcı ve cihaz içeren kurum ve kuruluşlarda “sistem yönetimi”nin başarılı olabilmesi için olmazsa olmazdır.

Linux dışındaki işletim sistemleri tarafından yapılandırma işlemleri için kullanılan grafik arayüz ile istenen verim alınamamıştır. ÖY/AKK işletim sistemi türevlerinin yıllardır desteklediği ve betiklerle konsol üzerinden sorunsuz uyguladığı yapılandırma işlemleri ticari işletim sistemleri için de örnek oluşturmuş ve son dönemde bu işletim sistemleri, veritabanı ve uygulama sunucuları için bile bu yöntemle yapılandırma yoluna gitmiştir. ÖY/AKKY’ın bu konuda da yazılım camiasına örnek olduğu söylenebilir. Konsol üzerinde çeşitli betikler kullanılarak cron, at, SSH, SNMP, ping, syslog gibi pek çok basit araçla çok karmaşık sistem yönetim görevleri yapmak mümkün kılınmıştır. Ticari yazılımlarla ağ takibi ve sistem yönetimi görevleri yerine getirilebileceği gibi NAGIOS, ZABBIX gibi pek çok ticari yazılımın ötesinde yeteneklere sahip olan ÖY/AKKY ile de bu yönetim faaliyetleri başarıyla gerçekleştirilebilir.

NAGIOS, 2002 yılında yayınlanan ilk sürümünden bugüne kadar geçen sürede büyük bir kullanıcı kitlesine ulaşmış ve sadece ağın takibi ve analizi değil sunucular başta olmak üzere sistemde koşan uygulamaların da izlenebilmesini olanaklı kılmıştır. Özel ve resmi pek çok kurum, kuruluş ve bakanlıklarda kullanılmaktadır.

ZABBIX, 2001 yılında ilk sürümünün yayınlanması ile birlikte kabiliyetlerini gelişen teknoloji ile birlikte artıran bir uygulamadır. Ağ takibinin çok ötesinde sanal sunucuların hatta bulut bilişim hizmetlerinin izlenmesi dahil olmak üzere geniş bir yelpazede kullanım alanına sahiptir. Kurumsal alanda pek çok uygulama örneği ile dünya üzerinde kullanılmaktadır.

Alt yapıda ağ ve sistem yönetimi için kullanılan ticari yazılımlar var ise ÖY/AKK göç sürecinde daha önceden kullanılan sistemler için oluşturulan çeşitli politikaların da gözden geçirilmesi sağlanmış olur. Pek çok senaryoda ÖY/AKK göçünde sistem mimarisi içinde gözden kaçan ve takibin fayda getirebileceği yeni kural setleri ortaya çıkabilmektedir. Bu süreçte sistem oturana kadar çok kısa süreli kesintiler yaşanabilecektir, ancak bu sadece ağı ve sistemi takip eden personeli etkileyeceği için kullanıcılardan bağımsız bir çalışma olarak planlanmaktadır.

Ağ ve sistemi takip etmek ve yönetmek için NAGIOS ve ZABBIX dışında da çeşitli ÖY/AKK çözümleri vasıtasıyla ağ ve sistem hizmetleri başarıyla takip edilebilmektedir. Bu ÖY/AKKY dünya çapında binlerce sunucu ve istemcinin bulunduğu kurumlarda başarıyla kullanılmaktadır. ÖY/AKK göç aşamasındaki kurumlar sistem ve ağ takibi/yönetimi için bahse konu bu araçları kullanarak sistem göçü sırasında sorunsuz bir geçişin olmasında yarar sağlamanın yanı sıra, göç sonrası ağ ve sistemlerin yönetimi konusunda da faydalanabilecektir.

5.8   Sanallaştırma Altyapısı

Sanallaştırma işletim sistemleri, sistem ya da ağ kaynaklarının mantıksal olarak bölünmesi veya yalıtılması olarak tanımlanabilir. Sunucu, depolama birimleri, ağ, masaüstü ve uygulama sanallaştırmaları olarak çeşitleri bulunur. Sanallaştırma altyapıları, kurumların donanım gereksinimlerini azaltarak, sunucu sistemlerin merkezi bir kaynaktan yönetilebilmesi, yedeklenmesi, kaynak takibinin yapılması, ayarlanması, erişimi ve benzeri temel işlevlerin sağlanmasını sağlar. Sanallaştırma teknolojisi, kullanıldığı bilgi sistemine birçok avantaj sunmaktadır;

  • Sistem kaynaklarını yüksek verimle kullanma
  • Farklı işletim sistemlerini bir arada kullanabilme
  • İhtiyaç anında çok hızlı şekilde yeni sunucu oluşturabilme
  • İşletme/toplam sahip olma maliyetinin düşürülmesi,
  • Donanım maliyetlerinde azalma
  • Kurum altyapı kaynaklarının daha verimli kullanılması
  • Operasyonel kurulum ve bakım maliyetlerinde azalma
  • Yedekleme ve yedekten dönme işlemlerini kolaylaştırma
  • İşletim sistemi kurulumlarında donanım uyum sorunlarından kurtulma.
  • Merkezi bir sistem üzerinden sunucuların aktif olarak oluşturulabilme, takip etme, kaynak ayırma işlevlerinin yapılabilmesi.

5.8.1   Sanallaştırma teknolojileri

Sanallaştırma teknolojileri kısaca 4 başlık altında incelenebilmektedir. [Bazargan2013] Bunlar;

5.8.1.1   Konuk İşletim Sistemi Sanallaştırma

Standart işletim sistemi üzerinde sanallaştırma yazılımı kurularak sanal makineler oluşturulur. VirtualBox programı bu tip sanallaştırmaya örnektir.

5.8.1.2   Paylaştırılmış Çekirdek Sanallaştırma

Sistem seviyesi sanallaştırma olarak bilinir. Gerçekte çalışan tek işletim sistemi vardır. Konuk işletim sistemlerinin kendilerine ait dosya sistemleri ve hiyerarşileri vardır. Linux-VServer, OpenVZ bu tip sanallaştırmaya örnektir.

5.8.1.3   Çekirdek Seviyesi Sanallaştırma

İşletim sistemindeki çekirdek kısmen değiştirilerek bir çok misafir işletim sisteminin çalıştırılması için gerekli ortam sağlanmaktadır. KVM, User-Mod Linux (UML) bu tip sanallaştırmaya örnektir.

5.8.1.4   Hipervizör Sanallaştırma Teknolojisi

Hipervizör çoklu işletim sistemlerinin aynı donanım üzerinde çalışmasını sağlayan uygulamadır. Bu uygulama doğrudan donanım üzerinde çalışarak birden fazla değişik işletim sistemi kurup koşturabilmektedir.

  • Paravirtualization (PV); Bir işletim sistemi ara katmanında kurulan hipervizör üzerinde sanal makinelerin çalışması prensibine dayanır ve misafir işletim sistemleri hipervizör üzerinde çalışır. Xen projesi ile tanıtılmıştır. Sanal makineler üzerinde bir takım ayarlamalar yapmak gerekebilir.
  • Tam Sanallaştırma; Fiziksel donanım kaynaklarının tamamen sanallaştırılması olarak tanımlanabilir. Paravirtualization ile hemen hemen aynı olmakla beraber sanal makineler üzerinde herhangi bir değişiklik gerektirmez.
  • Donanım Seviyesi Sanallaştırma; Donanımın sanallaştırma teknolojisine izin vermesi gerekir. Sanal makine, işletim sistemine fiziki donanımın sadece belirli kısımlarını sanal donanım olarak sunar.

Bununla beraber, ağ sanallaştırma, depolama birimi sanallaştırma, uygulama sanallaştırma, masaüstü sanallaştırmada bu teknolojiler arasında sayılabilir.

Ağ sanallaştırma; Ağ donanım ve yazılım kaynaklarını tek yazılım temelli yönetilebilir bir platforma dönüştüren sanallaştırma tipidir. OpenvSwitch, OPNFV bu tip sanallaştırmaya örnektir.

Depolama birimi sanallaştırma; fiziksel depolama kaynakları birleştirilerek tek bir depolama havuzuna, başka bir deyişle çoklu disk sürücüleri tek mantıksal girdiye dönüştürülür. Oluşturulan mantıksal depolama son kullanıcıya tek tip depolama birimi olarak sunulur. Open vStorage, Ceph, Swift projeleri bu tip sanallaştırmaya örnektir.

Uygulama sanallaştırma; Bir sunucu yazılımı platform bağımsız olarak herhangi bir masaüstü uygulaması kurulmaksızın çalıştırılmasını sağlar. Bu tip uygulamalar işletim sistemi üzerinde uygulamanın çalıştırılması için sanal bir ortam sağlar. Özellikle uygulamanın göç ettirilemediği durumlarda göç projelerinde kullanılmasından dolayı avantajları bulunmaktadır.

Masaüstü sanallaştırma; Sanal Masaüstü Altyapısı veya VDI merkezdeki bir sunucuda koşan bir sanal makinenin içinde kullanıcı masaüstünü çalıştırma işlemini ifade eder. Her bir ayrı kullanıcı için tamamen kişiselleştirilmiş masaüstleri sağlamaktadır. VMware, Citrix and Microsoft gibi ticari firmalar çeşitli lisanslama modelleriyle kendi VDI çözümlerini sunmaktadır. Bunun yanı sıra Xen, Amazon, WorkSpaces, Hyper-V gibi ücretli ve QVD, RAVADA, flexVDI, FOSS-Cloud gibi ÖY/AKK VDI çözümleri de bulunmaktadır.

VDI için geçici ve kalıcı olarak adlandırabileceğimiz iki ana yaklaşım vardır. Kalıcı VDI, her kullanıcıya, geleneksel bir fiziksel masaüstü gibi, gelecekteki kullanım için özelleştirilebilecek ve kaydedilebilecek kendi masaüstü görüntüsünü sağlar. Kalıcı olmayan geçici VDI, kullanıcıların gerektiğinde erişebilecekleri tek tip bir masaüstü havuzu sunar. Kalıcı olmayan olmayan masaüstü bilgisayarlar, kullanıcı her oturumu kapattığında orijinal durumlarına geri döner.

VDI kullanarak masaüstü bilgisayarlarının donanım güncelleme ihtiyacını en aza indirme şansında sahip olunur. İşlemci gücü gerektiren tüm hesaplamalar aslında sunucuda gerçekleştiği için yeni cihaz satın alma ihtiyacı en aza inmiş olur. Güvenlik açısından ele alacak olursak; verilerin uç noktalarda yani istemcilerde tutulmuyor olması sayesinde VDI kullanan bir dizüstü bilgisayarı çalan hırsız makineden veri bulunmadığından makineden herhangi bir veri alamaz. Özellikle geçici VDI masaüstü her seferinde sıfırlandığı için en az sayıda masaüstü seçeneği sunarak bakım ve destek ihtiyacını en aza indirmektedir.

Kalıcı VDI çözümlerinin en büyük dezavantajı ise depolama alanında ortaya çıkmaktadır. Masaüstü bilgisayar yerel kaynaklarla çalıştığında, işletim sistemi, uygulamalar, veriler ve ayarların tümü çoğunlukla bu bilgisayar üzerinde saklanır. Fazladan depolama maliyeti yoktur; disk yani depolama maliyeti masaüstü bilgisayarının fiyatı içinde yer alır. Bununla birlikte, kalıcı VDI ile işletim sistemi, her kullanıcı için uygulamalar, veriler ve ayarlar ana sunucuda depolanmaktadır. Kurum personel sayısı ve gereksinimlerin dikkatle belirlenmediği durumlarda depolama kapasite ihtiyaçlarını karşılamak için gereken bütçe maliyeti tahminlerin çok üzerinde gerçekleşebilir.

Geçici ve kalıcı VDI’nın ağ bağlantısı hızına bağlılığı diğer büyük dezavantajlar arasında yer almaktadır. Son yıllarda ağ bağlantı hızları teknolojik gelişmelere uygun olarak artsa da sanal masaüstlerine erişimde grafik yoğun uygulamalar ve yüksek işleme talepleri olan diğer yazılımlarda sorun yaşanmaktadır.

Sanallaştırma sistemi dönüşüm analizi yapılırken aşağıdaki sorulara yanıtlar bulunmalıdır:

  • Kurumsal işin yapılması ile ilgili teknik gereksinimler; kurum tarafından kullanılan sunucuların tespiti ve kaynak gereksinimlerinin neler olduğu,
  • Eğer mevcutsa, kapalı kaynak kodlu sanallaştırma sisteminin analizi, bu sistemden açık kaynaklı sanallaştırma sistemine taşınabilecek sunucuların hangilerinin olduğu,
  • Donanım üzerinde çalışan sistemlerin, açık kaynak sanal sistemlere taşınmasının nasıl olacağını,
  • Kapalı kaynak kodlu sanallaştırma sistemleri üzerinde çalışan sanal sistemlerin, açık kaynak sanal sistemlere taşınmasının nasıl olacağını,
  • Herhangi bir kesinti durumunda dayanılabilecek sürenin ne kadar olduğu,
  • Felaket kurtarma, yedekleme, yük dengeleme gibi kurumsal mimari isteklerin neler olduğudur.

Sanallaştırma sistemi göçü aşağıdaki adımlardan oluşmalıdır:

  • Analiz ve değerlendirme,

  • Kavram kanıtlama çalışması,

  • Pilot tasarım kurulum ve göç testleri,

    • Altyapısal isterlerin karşılanması için gerekli hizmet yazılımlarının seçilmesi

    • Kurulacak sanallaştırma altyapısının ileride büyüyebileceği öngörülerek gereken yapının tasarlanması

    • Altyapı için gereken donanım, ağ ve disk gereksinimlerinin belirlenmesi

    • İlk testlerin yapılması

      • Fiziksel veya başka bir sanallaştırma altyapısı üzerinden çalışan sanal sunucunun yeni sisteme taşınması
      • Pilot sanal sistem üzerinde, öncelikli olarak yönetici ve pilot ekibi tarafından gereken hizmetlerin çalışabilirliğinin kontrol edilmesi

  • Yaygınlaştırmanın yapılması,

    • Donanımsal veya eski sistemdeki sunuculardan uygun olanlarının açık kaynak sanallaştırma sistemi üzerinden çalışabilirliğinin sağlanması
    • Sistemi işletmeye alma planlaması
    • Sistem testleri
    • Regresyon testleri
    • Başarı ölçütleri ve testleri
    • Sistemin işletmeye alınması
    • Sistem başarımının takibinin yapılmasıdır.

Sanallaştırma hizmeti dönüşümünde riskler:

  • Sanal sunuculara gereken altyapısal bileşenlerinin sağlanamaması ( eksik ağ donanımı, görüntü işlemci vb ),
  • Yedekli yapının tam olarak tasarlanmadan devreye alınmasıdır.

5.9   Yerel Depo Hizmeti

Yerel depo oluşturmak ve yönetmek için aptly ve apt-mirror olmak üzere iki depo yönetim aracı kullanılmaktadır. Kurumların ihtiyaçlarına göre uygun olan tercih edilerek ilerlenmektedir. Bunların özelliklerini şu şekilde özetleyebiliriz;

apt-mirror
  • Pardus deposu olduğu gibi kopyalanır ve değişiklik yapılmadan yayınlanabilir.
  • Kullanımı ve yönetimi basittir.

aptly

  • Pardus deposu kopyalanır ve bu depoya kuruma özel harici uygulamalar ile birlikte mevcut uygulamalarda yapılan değişiklikler, geliştirmeler, özelleştirmeler de eklenilerek özel yeni bir depo oluşturulabilir.
  • Anlık görüntüler ile yedekler oluşturularak önceki tarihlere dönüş sağlanılabilir.
  • Depoda hiçbir değişiklik yapılmadan apt-mirror gibi de kullanılabilir.
  • Kullanımı ve yönetimi apt-mirror’a göre daha karmaşıktır.

Her iki depo yönetim aracı da şunları kapsamaktadır;

  • Kullanıcıların depo ile ilgili işlemlerinde daha hızlı sonuç almalarını sağlayacaktır.
  • Kurumdaki sistem yöneticilerinin gelen güncellemeleri önceden kontrol edip daha sonra kullanıcılarına aktarmasını sağlayacaktır.
[Bazargan2013]Bazargan, Fatma & Yeun, Chan & Zemerly, Jamal. (2013). State-of-the-Art of Virtualization, its Security Threats and Deployment Models. International Journal for Information Security Research. 3. 10.20533/ijisr.2042.4639.2013.0039
[SolidIT2018]Solid IT, “DB-Engines Ranking”, Ekim 2018. Erişim Tarihi: 22 Ekim 2018 [Online]. https://db-engines.com/en/ranking