Gelişen teknolojiye paralel olarak her geçen gün farklı farklı çözümler hayatımıza girdi. Artık uygulamalarımızı, servislerimizi, network altyapımızı, veri depolama sistemlerini hatta iş istasyonlarımızı sanallaştırır bir noktaya geldik. Değişen bu kadar şeye rağmen yıllardır üzülerek gözlemlediğim ve bana göre hala devam eden en önemli hatalardan biri ise çalışan sistemleri kendi haline bırakmak ve sadece problem yaşandığında müdahale etmek. Problem yaşandığı zaman o problemi çözmek elbette ki bizim işimiz var fakat bence asıl önemli olan problem yaşanmadan, önleyici bakım ve kontroller ile bunun önüne geçebilmek. Günümüzün popüler deyimi ile proaktif çalışmak.

Sanallaştırma platformları için ciddi maddi yatırımlar yapıyoruz. Satın alınan sunucular üzerinde, birçok parametreyi hesaplayarak mimariler kurguluyoruz. Bu mimariler üzerinde ise iş kritik onlarca uygulama ve sunucu barındırıyoruz. Sanallaştırma platformları eğer düzenli olarak kontrol edilerek takip edilmez ise Vmware özelinde meşhur mor ekranı görme olasılığınız çok yüksek. Özellikle belli başlı performans metriklerini ve eğer Over Provisioning yapıyorsanız utilizasyon yani kaynak kullanım çıktılarını doğru analiz etmeniz gerekiyor.

Yazımızın temeli Vmware tabanlı Sanallaştırma Platformları üzerinde ücretsiz, yani açık kaynak kodlu uygulamalar olan Grafana, InfluxDB ve Telegraf kullanarak performans ve kapasite analizi yapmak ve bunu anlamlı Dashboard’lar ile görselleştirip istediğimiz zaman geriye dönük performans ve kapasite takibi yapabilmek üzerine. Performans Datalarını almaya başladığınız andan itibaren geriye dönük isterseniz son bir yıl için bile kullanım verilerinizi görebilirsiniz.

Dashboard’u daha detaylı görüntülemek isterseniz Buraya tıklayabilirsiniz. Jorge de la Cruz Mingo adında ispanyol bir arkadaşın hazırlamış olduğu ve çok beğendiğim bir Dashboard.

Telegraf kullanarak çalışan Production Vmware sistemleriniz üzerinden aşağıdaki bütün metrik verilerini toplayabilirsiniz. En önemlisi ise bunları sadece 3 adet Açık Kaynak Kodlu uygulama kullanarak tamamen ücretsiz olarak yapacağız.

Önce uygulamalardan kısaca bahsedelim.

Telegraf:
Google tarafından geliştirilen GO programlama dili ile yazılmış, onlarca farklı sistem üzerinden performas metriklerini hızlı ve sistemlerinizi yormadan çekerek birçok farklı datastore üzerinde sakmalanızı sağlayan bir ajan. 2018 yılının son çeyreğinde offical olarak Vmware platformları üzerinden performans metriklerini toplamak için oldukça başarılı bir Plugin yayınladı. Bugün bizde Telegraf ile oldukça basit bir şekilde Vmware üzerinden performans verilerini çekeceğiz.

InfluxDB: InfluxData firması tarafından yine GO programlama dili yazılmış ve genellikle IOT cihazlar tarafından toplanan veriler, performans ve analiz verilerini saklamak için kullanılan bir Database. Telegraf ile topladığımız verileri InfluxDB üzerinde saklayacağız.

Grafana: Kibana ile beraber belki de en popüler Dashboard oluşturma uygulamalarından biri. Data Source olarak birçok farklı Database türünü destekliyor. Telegraf ile topladığımız ve InfluxDB üzerine aktardığımız verilerimizi Grafana ile oluşturduğumuz Dashboard lar üzerinde görüntüleyeceğiz.

3 adımda uygulamalarımızı kurarak sistemlerimizi monitör etmeye başlayabiliriz.

Kurulum için Altyapı Gereksinimleri: İşletim sistemi olarak CentOS 7.5 kullanacağız. Aşağıdaki kaynaklara sahip bir sunucu yeterli olacaktır. İleride yapınız büyürse kaynaklarınızı buna paralel arttırmanızı öneririm. Diğer bir önemli konusu ise tarih ve saat bilgilerinizin güncel olması gerekiyor NTP yükleyerek gerekli konfigürasyonu kesinlikle yapmalısınız. Aksi takdirde Grafana ve Vmware tarafında zaman farkı olacağından dolayı aslında database ‘de bulunan son 5 dakikalık Data’yı görmek istediğinizde boş bir sayfa ile karşılaşabilirsiniz.

  • 2 Core Vcpu
  • 4 GB Memory
  • 50 GB disk alanı

Grafana Kurulumu 

Kurulum yapmadan önce ilgili Repository bilgisini eklememiz gerekiyor.

$ vi /etc/yum.repos.d/grafana.repo 

Dedikten sonra açılan sayfa içerisine aşağıdaki bilgileri kaydederek çıkış yapın.

[grafana] name=grafana
baseurl=https://packagecloud.io/grafana/stable/el/7/$basearch
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packagecloud.io/gpg.key https://grafanarel.s3.amazonaws.com/RPM-GPG-KEY-grafana
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt 

Artık kuruluma başlayabiliriz. Sırasıyla aşağıdaki komutları çalıştırarak kurulumu tamamlayın. Daha sonra servisi Start ederek Enable duruma getirin.

$ sudo yum install grafana
$ sudo service grafana-server start
$ sudo systemctl enable grafana-server.service 

Servisin olması gerektiği gibi çalıştığını kontrol edelim

$ systemctl status grafana-server 

Uygulama ilk kurulduğunda default 3000 portu üzerinden çalışacaktır. Internet Explorer üzerinden http://ipadresiniz:3000
adresine giderek kullanıcı adı ve şifre olarak admin\admin kullanıp Login olabilirsiniz.

InfluxDB Kurulumu 

İlk önce ilgili Repository bilgisini girerek başlıyoruz. Aşağıdaki komut setinin hepsini kopyalayıp konsol üzerinden direkt olarak çalıştırabilirsiniz.

cat <<EOF | sudo tee /etc/yum.repos.d/influxdb.repo
[influxdb] name = InfluxDB Repository – RHEL \$releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
EOF 

Aşağıdaki komutları kullanarak InfluxDB yüklemesini tamamlayalım ve Status diyerek servisin çalıştığından emin olalım.

$ sudo yum install influxdb
$ sudo systemctl start influxdb
$ sudo systemctl status influxdb

Telegraf Kurulumu 

Aşağıdaki komutları kullanarak Telegraf kurulumu yaptıktan sonra servisi Start edelim ve çalışıp çalışmadığını kontrol ediyoruz.

$ sudo yum install telegraf
$ sudo systemctl start telegraf
$ sudo systemctl status telegraf 

Telegraf tarafından toplanan metrikleri saklamak için İnfluxDB üzerinde Telegraf adında bir adet Database ve kullanıcı oluşturacağız.

$ influx
$ create database telegraf
$ create user “telegraf” with password ‘Password123!’ with all privileges
$ exit 

Telegraf içerisinde bulunan yapılandırma dosyasına InfluxDB üzerinde yeni oluşturduğumuz Database – Kullanıcı Adı ve Kullanıcı şifresi bilgilerini girmemiz gerekiyor.

$ vi /etc/telegraf/telegraf.conf 

Sarı ile işaretlediğim satırların başında bulunan işareti kaldırarak bilgileri girebiliriz.

Tekrar telegraf.conf dosyası içerisine girerek Vsphere Plugin ile ilgili kısımların başında bulunan # işaretlerinin hepsini kaldırın.

$ vi /etc/telegraf/telegraf.conf 

Sarı ile işaretlediğim alanlara Vcenter adresinizi, kullanıcı adı ve şifre bilgilerini girin. Ben direk Administrator hesabını tanımladım fakat yeni bir user oluşturup en tepeden sadece “Read Only” yetkilendirerek buraya tanımlayabilirsiniz. Yanlışlık yapmak istemiyorsanız aşağıdaki link içerisinde paylaştığım konfigürasyonu örnek alabilirsiniz. Bu konfigürasyon içerisinde # işaretleri konulmadan paylaşılmış versiyonu mevcut. Telegraf.conf dosyası içerisindeki versiyonu silip buradan kopyaladığınız şekli ile yapıştırabilirsiniz.

https://github.com/influxdata/telegraf/tree/release-1.8/plugins/inputs/vsphere

Telegraf Vsphere SDK’ya HTTPS üzerinden bağlanacak. SSL hatası almamak için Vcenter CA Root sertifikalarını sunucumuza yüklememiz gerekiyor. Web Browser üzerinden Vcenter adresine giderek ana sayfa üzerindeki “Donwload trusted root CA Certificates” ‘e tıklayarak root CA sertifikasını indirin

İndirdiğiniz download.zip dosyası içerisinde bulunan sertifikaları CentOS üzerinde;

/etc/pki/ca-trust
/etc/pki/ca-trust/source
/etc/pki/ca-trust/source/anchors

Altına kopyalayarak aşağıdaki komutu çalıştırın.

$ update-ca-trust extract 

Telegraf uygulamasını Restart edip, servisin durumunu kontrol ettikten sonra herhangi bir sertifika hatası almadığımızdan emin olalım.

$ systemctl restart telegraf
$ systemctl status telegraf 

Artık Grafana üzerinden oluşturduğumuz InfluxDB Database’imizi Data Source olarak ekleyebiliriz.

  1. Name kısmına herhangi bir isim verin.
  2. Type olarak InfluxDB seçin
  3. URL kısmı aşağıdaki ekranda gözüktüğü gibi ayarlayın
  4. Database adı, username ve şifre kısmına InfluxDB üzerinde oluşturduğunuz kullanıcı ve DB bilgileri girerek “Save&Test” butonuna basın.

Aşağıda linklerini paylaştığım hazır Dashboard’ları import edin. İmport ederken “influxdb” kısmına daha önceden oluşturduğumuz ve Vmware metriklerini tutan Database in seçili olduğu Datastore u seçin.

  • https://grafana.com/dashboards/8159
  • https://grafana.com/dashboards/8162
  • https://grafana.com/dashboards/8165
  • https://grafana.com/dashboards/8168

Yeni eklediğiniz Dashboard un üzerine geldiğinizde, Dataların yavaş yavaş geldiğini görebilirsiniz.

TAGs: Grafana Nedir?, Grafana Kurulum, Telegraf Nedir?, Telegraf Kurulum, InfluxDB nedir?, InfluxDB Kurulum, Vsphere Raporlama, Vsphere Kapasite Planlama, Vsphere Dashboard, Vsphere Performans, Vmware Kapasite

Event Viewer yıllardır hepimizin belki de en çok kullandığı Windows ara yüzlerinden bir tanesi. Teknolojinin yıllar içerisin de geldiği noktaya bakarsak 2019 yılında hala o küçük gri ekran üzerinden analiz yapmak benim için her zaman sevimsiz bir eylem olmuştur. Sizde samanlıkta iğne aramaktan yorulduysanız, bence bu yazı oldukça ilginizi çekebilir. Dosya sunucuları üzerinde Auditing operayonu genelde atlanan fakat ihtiyaç anında eğer düzgün bir şekilde yapılandırılmış bir loglama metodolojiniz bulunmuyorsa IT personellerine ciddi geri dönüşleri olabilecek, oldukça önemli bir konu. Günümüzde Dosya Sunucularına özel Audit hizmeti veren birçok uygulama mevcut. Bir kısmı gerçekten benimde çok beğendiğim uygulamalar fakat bu uygulamaların kaliteli olanlarının teknik yetenekleri hariç ortak paydalarından biri de pahalı olmaları.

Açık kaynak kodlu yazılımlar dünya genelinde oldukça popüler ve bir çok IT profesyoneli tarafından hiçbir karşılık beklenmeden yıllardır geliştirilip, ücretsiz bir şekilde hepimizin kullanımına sunuluyor. Ortada bu kadar emek varken ben kişisel olarak bu tarz ürünlere para vermenin yanlış olduğunu düşünenlerdenim. Bugün amacım tamamen ücretsiz bir şekilde, yine birkaç açık kaynak kodlu uygulama kullanarak anlamlı ve tamamen ihtiyaçlarımıza yönelik güzel görseller ile desteklenmiş bir loglama mekanizması kurmak ve istediğimiz anda belki de aylar öncesine ait milyonlarca kayıt içerisinden gerekli olan veriye saniyeler içerisinde ulaşmak.

Hepsi tamamen Open Source olan Elasticsearch, Kibana ve Winlogbeat kullarak sizde aşağıdaki gibi bir Dashboard üzerinden Dosya Sunucunuzu takip edebilir, görmek istediğiniz kayıtlara hızlıca ulaşabilirsiniz. Görsel’in büyük halini görmek isterseniz Buraya tıklayın.

Kurulum için Altyapı Gereksinimleri: İşletim sistemi olarak CentOS 7.5 kullanacağız. Aşağıdaki kaynaklara sahip bir sunucu yeterli olacaktır. İleride yapınız büyürse kaynaklarınızı buna paralel arttırmanızı öneririm.

  • 2 Core Vcpu
  • 4 GB Memory
  • 50 GB disk alanı

Elasticsearch kullanabilmeniz için sisteminizde Java yüklü olması gerekiyor. Burada dikkat etmemiz gereken nokta Versiyon 9 \10 desteklenmiyor, bende yazıda zaten Java 8 üzerinden ilerledim fakat yine de ayrıca belirtmekte fayda var. Ayrıca reverse Proxy görevi görmesi için Nginx kurulumu da yapacağız. Ayrıca her zamanki gibi Nano editör yükleyerek, Firewall ve Selinux ‘ü Disable etmeniz gerekiyor.

3 Aşamalı bir kurulum ve yapılandırma planı hazırladım. Bu şekilde parçalara ayırarak daha net bir şekilde aklınız da yer etmesini istiyorum aslında, sadece komut setlerini takip ederek yani tam olarak sindiremeden kurulumu tamamlanmanızı tavsiye etmem.

  1. Elasticsearch ve Kibana Kurulumu
  2. File Server Audit Policy aktivasyonu, Winlogbeat Agent kurulumu ve Konfigürasyonlarının yapılması, loğların aktarılması
  3. İndex ayarları, Görseller için query dizayn edilmesi ve Dashboard

Elasticsearch ve Kibana ve Kurulumu

Ön gereksinimler kısmında belirttiğimiz gibi ilk önce Java 8 kurulumu ile yapmamız gerekiyor. Aşağıdaki komutu çalıştırarak Java kurulumunu yapın ve versiyonu kontrol edin.

Ön Gereksinimler ile başlayalım

$ sudo yum install java-1.8.0-openjdk
$ java –version

Elasticsearch package spoofing yapılmaması için güvenlik adına ayrı bir KEY ile paketleri imzalanmış durumda. Bu yüzden ilk önce Elasticsearch public GPG key’i download ederek Repository ye eklememiz gerekiyor.

$ sudo rpm –import https://artifacts.elastic.co/GPG-KEY-elasticsearch

Kurulum için gerekli repository’imizi ekleyelim. Editor üzerinden elasticsearch.repo dosyasını oluşturun.

$ sudo vi /etc/yum.repos.d/elasticsearch.repo

Aşağıdaki repo bilgilerini girdikten sonra kayderek çıkış yapın.

[elasticsearch-6.x]
name=Elasticsearch repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

Elasticsearch
Kurulumu

Artık hazırız. Elasticsearch’ü yükleme aşamasına geçebiliriz. Aşağıdaki komutu çalıştırarak yüklemeyi tamamlayabilirsiniz.

$ sudo yum install elasticsearch

External bir kaynaktan erişebilmek için yapılandırma içerisinde birkaç parametreyi değiştirmemiz gerekiyor. YML dosyasını açarak;

$ vi /etc/elasticsearch/elasticsearch.yml

Aşağıdaki satırı Uncomment duruma getirin. Network.host kısmını localhost’dan 0.0.0.0 a çekin. Aşağıdaki resimde gösterildiği şekilde gözükmesi gerekiyor.

Servisi Start ettikten sonra ve eğer sunucu yeniden başlarsa otomatik olarak Start olması için Enable duruma getirelim.

$ sudo systemctl start elasticsearch

$ sudo systemctl enable elasticsearch

Servisin çalıştığından emin olmak için basit bir request gönderek test edin, aşağıdaki gibi bir çıktı almanız gerekiyor. Eğer ilk seferde response alamaz iseniz lütfen Firewall ve Selinux’un kapalı ve Disable olduğundan emin olun. Eğer her şey yolunda ise bir süre bekleyerek tekrar deneyin.

$ curl -X GET “localhost:9200”

Kibana Kurulumu

Kibana ya dışarıdan erişim için Reserve Proxy olarak kullanmak ve erişim yapacak kişiler için Web Interface üzerinden kullanıcı adı\şifre talep ederek doğrulama yapmak üzere Nginx kurulumu yapmamız gerekiyor.

Nginx i yükleyebilmemiz için ilk önce EPEL repository’i eklememiz lazım.

$ sudo yum install epel-release

Artık Nginx i yükleyebiliriz,aşağıdaki komutu çalıştırabilirsiniz.

$ sudo yum install nginx httpd-tools

Nginx üzerinden Kibana ya erişirken kullanmak üzere username\password belirleyelim. Komutu çalıştırdıktan sonra şifrenizi girerek doğrulayın, çıktıları kaydedin.

$ echo “kibanawebuser:`openssl passwd -apr1`” | sudo tee -a /etc/nginx/htpasswd.users

Nginx üzerinde Virtual Host yapılandırmamızı yaparak devam ediyoruz. Uzaktan erişim için bir FQDN belirleyin. Ben bu örnekte “fileserveraudit.demo.com” olarak belirledim, burayı isteğinize göre değiştirebilirsiniz.

$ sudo vi /etc/nginx/conf.d/fileserveraudit.demo.com.conf

Aşağıdaki konfigürasyonu yapıştırın, Server_name kısmını bir önceki aşamada belirlediğiniz FQDN’i girerek kendinize göre düzenleyin, kayderek çıkış yapın.

server {
listen 80;

server_name fileserveraudit.demo.com;

auth_basic “Restricted Access”;
auth_basic_user_file /etc/nginx/htpasswd.users;

location / {

proxy_pass http://localhost:5601;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection ‘upgrade’;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;

}

}

Resimde gösterildiği gibi bir konfigürasyona sahip olmanız gerekiyor.

Konfigürasyonda herhangi bir hata var mı diye kontrol ediyoruz.

$ sudo nginx –t

Test is successfull mesajını görmek önemli.

Servisi Start ve Enable ederek kurulumu bitiriyoruz.

$ sudo systemctl start nginx

$ sudo systemctl enable nginx

Repo’yu daha önce eklediğimiz için hızlıca Kibana kurulumuna geçiyoruz. Kurulum sonrası her zamanki gibi servisi Start ederek, Enable duruma getiriyoruz.

$ sudo yum install kibana

Yükleme bittikten sonra yine birkaç konfigürasyon değişikliği yapmamız gerekiyor.

$ nano /etc/kibana/kibana.yml

Aşağıda belirtilen satırları Uncomment ederek, kaydedip çıkış yapın.

server.port: 5601
server.host: “localhost”
elasticsearch.url: “http://localhost:9200”

$ sudo systemctl start kibana

$ sudo systemctl enable kibana

http://fileserveraudit.demo.com adresi üzerinden Kibana arayüzüne erişebiliriz. Tabi ki siz burada ne belirlediyseniz o adres üzerinden giriş yapabilirsiniz, DNS kaydını local kullanıyorsanız bağlanmak istediğiniz istemci ve Centos üzerinde HOSTS dosyasına ilgili ip adresi ve FQDN’i girmeyi unutmayın. Ngnix kurulumu sırasında belirlediğiniz ( username: kibanawebuser olacak set etmiştim ben) kullanıcı adı ve şifre ile login oluyoruz.

File Server Audit Ayarları ve Winlogbeat Kurulum\Konfigürasyonu

File Server Audit Ayarları

File server üzerinden logları alabilmeniz için ilk önce Audit Policy üzerinde bir kaç konfigürasyon yapmanız gerekiyor. Domain Controller üzerinden GPO ile de halledebilirsiniz fakat ben size local group policy üzerinden nasıl yapabilirsiniz onu göstereceğim. Sunucu üzerinde Start/RUN dedikten sonra   gpedit.msc yazarak entera basın . Object Access kategorisi içerisinde Audit File System’i seçerek Configuration the following events diyerek “Success” i işaretleyin, istediğinize göre “Failure” eventlarıda loglayabilirsiniz.

Global Object Access Auditing kategorisi altında; File System’e tıkladıktan sonra “Define the Policy Settings” i işaretleyin ve “Configure” e tıklayarak karşınıza çıkan ekran üzerinde “Add” butonuna basın. “Everyone” için kategori “success” olacak şekilde loglanmasını istediğiniz aksiyonları işaretleyin. Ben sadece hangi dosyaları kimin sildiği ile ilgilendiğim için silinen dosyalar ve permission değişikliklerinin loglanması için ilgili seçenekleri seçtim

Winlogbeat Kurulum ve Konfigürasyon

Bu çalışmaları loğlarını almak istediğimiz file server üzerinde yapacağız. Buraya tıklayarak ilgili dosyaları indirin.

  1. İndirdiğiniz dosyaları zip’ten çıkartın
  2. C:\Program Files\ altında “winlogbeat” diye bir folder oluşturarak dosyaları buraya kopyalayın.

Notepad++ yüklü değilse öncesinde yüklemenizi öneririm.

  1. Winlogbeat.yml dosyasını notepad++ ile açın

Winlogbeat.event.logs: altında bulunan değerleri resimdeki gibi düzenleyin.

– name: Security
– name: System
– name: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational

Oputput.elasticsearch: altındaki host bilgisini kendi ip adresiniz ile düzenleyerek Uncomment edin. Dosyayı kaydererek çıkın.

  1. Powershell üzerinden winlogbeat path’ine giderek;

.\install-service-winlogbeat.ps1 diyerek servis olarak yüklemeyi yapın.

  1. Services altından Winlogbeat servisini start edin

Index eklenmesi, Query Dizayn ve Dashboard Hazırlanması

Index Eklenmesi

Management sekmesinden “Index Patterns” ‘e girin.

Create İndex Pattern” butonuna basın. Sağ alt tarafta resimde olduğu gibi winglogbeat üzerinden gönderilen loğların tarih bilgisi ile beraber gözüküyor olması gerekli. Hemen gelmez ise bir süre bekleyin ve sayfayı yenileyerek tekrar bakın. Sağ alt tarafta “winglobeat-6.5.4-XXXX” ‘i görene kadar index pattern oluşturamayacaksınız.

Açılan ekran üzerindeki kutucuğa “winlogbeat*” yazarak Next e tıklayın. Bir sonraki ekranda “@timestamp” i seçtikten sonra index eklemeyi tamamlayabilirsiniz.

Discover ekranı üzerinden kontrol ettiğinizde loğların yavaş yavaş gelmeye başladığını görebilirsiniz. Tebrikler, loğlarınız başarılı bir şekilde elasticsearch üzerinden depolanıyor.

Query Görsellerinin hazırlanması\Yüklenmesi

Viualize sekmesi altından istediğiniz birçok farklı formatta anlamlı görseller hazırlayabilirsiniz. Windows file server özelinde hazırladığım query’ler ile düzenlediğim dashboard görsellerini Buraya tıklayarak indirin. JSON dosyasını zip’ten çıkatarak; Management\Saved Object\Import seçenekleri üzerinden import edin.

Dashboard Hazırlanması

Dashboard menüsü üzerinden yeni bir dashboard ekleyerek “Add Panel” dedikten sonra biraz önce import ettiğimiz görselleri seçin.

Artık sonucu görmek için hazırız.

Yeni bir Mirai botnet çeşidi, işletmeler tarafından kullanılan WePresent WIPG-1000 Kablosuz Sunum Sistemlerini ve LG Supersign TV‘leri hedefliyor.

Araştırmacılar, Ocak ayından bu yana kurumsal kablosuz sunum ve görüntüleme sistemlerindeki güvenlik açıklarını hedef alan ünlü Mirai IoT botnet‘in yeni bir türünü keşfetti.

Palo Alto Network’ün Birim 42 araştırmacıları, Mirai’nin bu yeni çeşidinin özellikle farklı olduğunu belirterek, hassas, tüketici IoT (Internet of Things) cihazlarının aksine kurumsal odaklı cihazları hedef aldığını; yani, WePresent WIPG-1000 Kablosuz Sunum Sistemleri’ni ve LG Supersign TV’leri hedef aldığını belirtti.

Her iki sistemin de kurumsal işletme ortamlarında sıklıkla kullanıldığı bilinmektedir.

Yeni Exploit’ler

LG Supersign TV’ler için, birçok TV’de yerleşik olarak bulunan LG SupersignEZ CMS, yanlış parametre işleme nedeniyle yapılan uzaktan kod yürütme saldırılarının (CVE-2018-17173) çalıştırılmasına neden oluyor. WePresent WIPG-1000 için ise bu yeni çeşit Mirai, command injection saldırısını hedefliyor.

WePresent ve LG şirketlerinden zafiyetlerle ilgili henüz bir açıklama gelmedi.

Bu ticari yazılımların yanında, yeni çeşit Mirai, router’lar (Linksys E1500/E2500 ve ZTE ZXV10 H108L) gibi çeşitli gömülü donanımları, ağ depolama aygıtlarını, NVR‘ler ve IP kameraları (Netgear ReadyNAS Surveillance 1.4.3-16 ve NUOO NVRMini cihazları) bunlara karşı birçok exploit’i kullanarak hedef alıyor.

Araştırmacılar, yeni Mirai çeşidinin 11‘i yeni olmakla beraber toplamda 27 tane exploit içerdiğini belirtti.

Araştırmacılar Pazartesi günü yayımlanan yazıda, “Bu yeni özellikler botnet’e geniş bir saldırı yüzeyi sağlıyor. Özellikle, kurumsal bağlantıların hedeflenmesi aynı zamanda, daha geniş bant genişliğine erişilmesine izin veriyor ve DDoS saldırıları için botnet’in daha fazla saldırı gücü ortaya çıkarmasına neden oluyor” dedi. “Botnet’in kurumsal güvenlik açıklarını hedeflediğini gözlemlediğimiz örnekler ise, Apache Struts ve SonicWall‘a karşı yapılan exploit’lerin de saldırılara dahil edilmesiydi” diye eklediler.

Mirai, 2016‘da büyük websitelerine saldırı yapmak amacıyla 300.000‘den fazla IoT cihazını kullanan büyük, eşi benzeri görülmemiş bir DDoS saldırısında kullanılmasıyla tanınıyor.

Brute Force Taktikleri Gelişiyor

Yeni istismarların yanı sıra, Mirai’nin yeni çeşidi, cihazlara yönelik brute force saldırılarına wordlist‘ine eklediği yeni, varsayılan kimlik bilgileriyle devam ediyor.

Varyantın daha fazla incelenmesinin ardından, araştırmacılar, bu yeni çeşit botnet’te daha önce rastlamadıkları olağan dışı bir brute force referansı kullanıldığını söylediler.

Cihazlar saldırıya uğradığında, kötü amaçlı yazılım, değişiklikler için Mirai payload’ını çekiyor ve cihazı botnet’lerin arasına ekliyor. Böylece, HTTP flood kullanılarak yapılan DDoS saldırılarında kullanılmak için zombi cihaz hazır hale geliyor.

Araştırmacılar, varyantın, shell script payload‘ının hala aktif olduğunu ve ilginç bir şekilde Kolombiyada bulunan “elektronik güvenlik, entegrasyon ve alarm izleme” işleri için oluşturulmuş bir web sitesinde barındırıldığını söyledi.

Araştırmacılar, IoT/Linux botnet‘lerin, ya daha fazla cihaza ulaşmak ve ağlarına eklemek için daha farklı exploit’ler kullandığını ya da daha çeşitli varyasyonlar denemek için oluşturulan wordlist’lerle brute force saldırıları yaptığını belirtti. Ayrıca, kurumsal güvenlik açıkları hedeflenerek, tüketici cihaz bağlantılarından daha büyük bant genişliğine ulaşarak, DDoS saldırıları için daha fazla saldırı gücü sağlanıyor denildi.

Siber suçlular, savunmasız bir şekilde çoğalan IoT cihazlarıyla orantılı olarak Mirai’nin farklı türevlerini ortaya çıkarmaya devam ediyorlar…

Yazan: İsmail SAYGILI (Eczacıbaşı Bilişim)

İnsan faktörü herhangi bir işletmedeki en büyük güvenlik açığıdır. Çalışanlar bir şirketin en önemli varlığı olsa da, aynı zamanda en büyük güvenlik riskini oluşturmaktadır.

Son yıllarda ortaya çıkan güvenlik ihlallerine bakıldığında, yanlışlıkla veya kasıtlı olarak kötü amaçlı yazılım girişi yapılıp yapılmadığına bakılmaksızın, insan faktörü güvenlik açığı açısından en önemli tek başarısızlıktır. Donanım veya işletim sistemleri güncellenirken, açıklar yamalarla kapatılmakta ve güvenlik riskleri ortadan kaldırılmaktadır. Benzer şekilde, çalışanlar da sürekli güncellemeli ve ortaya çıkan yeni saldırılardan nasıl kaçınacağı konusunda bilinçlendirilmelidir.

Çalışanlar işletmelerin varlıkları olduğu için onlara sürekli yatırım yapılmalıdır. Yüzlerce çalışanı olan bir şirkette bir kişinin güvenlik konusunda yetersiz olması, bütün çalışanları etkileyebilecek sonuçların doğmasına sebep olabilmektedir.

Keepnet Labs iş birliğiyle hazırlanan bu yazıda, tüm çalışanların siber riskleri ve en iyi uygulamaları anlamalarına yardımcı olacak ipuçlarını bulabilirsiniz:

1. Egzersiz yaparak gerçek saldırılara hazırlanın.

Günümüzde yapılan en iyi eğitim, kullanıcılara özgü hazırlanan simülasyon çalışmalarıdır. Bu tür saldırılar “canlı” ve tecrübe sağlayan eğitim niteliğindedir. Keepnet Labs, siber güvenlik platformu ücretsiz olarak kullanıcılara “özelleştirilebilir” simülasyon kampanyaları hizmeti vermektedir. Buradan çalışanlarınızı gerçek senaryolarla eğitebilirsiniz. Hazırlayacağınız bir güvenlik departmanından gelen mesaj ya da bir satıcı tarafından düzenlenen bir saldırı senaryosuyla çalışanlarınızı gerçek bir riski yaşatarak, bundan ders almalarını sağlayabilir ve bu saldırıdan öğrendikleri dersleri ve iş üzerindeki etkilerini, kişisel yaşamlarında görmelerine yardımcı olabilirsiniz. Çalışanlar, bu deneyimleri daha sonra iş arkadaşlarıyla paylaşabilirler.
Düzenli phishing testleri gerçekleştirilerek, kurum içerisinde kaç kişinin oltaya düştüğü ölçülebilir. Ardından, sorunlu kişi veya dapartmanlara eğitim verilebilir ve şirketin ilerlemesi değerlendirilebilir.

2. İşe başlayanların ilk önce siber farkındalık hakkında eğitim almalarını sağlayın

Çalışanlar ilk defa işletmelerin kapısından girer girmez güvenlik eğitimi alırlarsa, bu yönde zihniyetlerini geliştireceklerdir. Bu kişiler, gerekirse tüm gün eğitilmelidir. Bu şekilde işe başlayan çalışan stabil bir şekilde çalışma hayatına devam edecektir.

3. Değerlendirmelerde bulunun

Kurumunuzun ne kadar savunmasız olduğunu öğrenmek için, hem çalışanların hem de sistemlerin değerlendirmelerini yapmaktan çekinmeyin. Bunu yapana kadar güvenlik durumunuzun ne kadar kötü ya da iyi olduğunu bilmezsiniz.

4. İletişim kurun

Tüm çalışanların siber güvenlik bilgilerini nasıl en iyi şekilde iletebileceğini sağlayan bir plan hazırlayın. Siber güvenlik konusunda birimler, departmanlar ve kişiler kolayca iletişim kurabilmeli. Bunu sağlayabilen bütüncül bir süreç yönetimi tertip edin.

5. Resmi bir plan oluşturun

IT ekipleri, saldırı vektörleri ve diğer risklerle ilgili en yeni bilgilerle resmi planlarını güncellemeli ve siber güvenlik eğitimi için bu planı sık sık güncellemelidir.

6. Siber güvenlik kültürü oluşturun

Her bölümünde siber güvenliği savunan ve bunu iyi bilen birisinin olması gerekir.Bu kişiler çalışanları eğitebilir ve onları motive edebilir. Bu, sıklıkla göz ardı edilen bir durumdur. Bu tür kaynakları kullanmaktan çekinmeyin.

7. Sürekli eğitim sağlayın

Siber güvenlik eğitimi, işletmelerin her kademesinde, her çalışanın işine özel olarak yıl boyunca devam etmelidir. Son kullanıcılar maruz kalabilecekleri saldırı türleriyle ilgili eğitim almalıdır. Örneğin e-postanıza yapılan saldırılar veya bulunduğunuz iş türüne yönelik saldırılar gibi.

8. İş güvenliği hem evde hem de iş yerinde sağlanmalı

Çalışanlar sadece iş yerinde değil, aynı zamanda evde de siber hijyeninin sağlanmasının önemini anlamalı. Kullanıcılara gizlilik, güvenlik konusunda eğitimler verilmeli; işte öğrenilen derslerin evde ve kişisel yaşamlarında uygulanması sağlanmalı. Alınan eğitimlerin sadece işyerinde değil her zaman uygulamaları vurgulanmalı.

9. Çalışanları ödüllendirin

Zararlı e-postaları bulan kullanıcıları ödüllendirmek ve kullanıcıların siber saldırılara nasıl engel olduğa ilişkin hikayeleri paylaşmak önemlidir. Aynı zamanda hata yapanlarla empati kurmak gereklidir. Birçok çalışan, günde yüzlerce e-posta gönderip alabilmektedir. Bu nedenle bunlardan birini kaçıranlara empatiyle yaklaşmak gerekir.

Yazan: İsmail SAYGILI (Eczacıbaşı Bilişim)

İlk kez Ocak 2018‘de tanıştığımız MeltdownSpectre ve Foreshadow gibi işlemci bazlı zafiyetlere bir yenisi daha eklendi. Graz Teknoloji Üniversitesi’nden bir grup araştırmacı, Intel işlemcilerde saldırganların CPU bellek alanlarında işlenen verileri almasına izin verebilecek yeni bir güvenlik açığı sınıfı keşfetti. CPU bazlı saldırıların artmasıyla beraber artık bu tip saldırılarda karakterlerine göre sınıflandırılmaya başlandı. Yeni işlemci zafiyetine ise Zombieload, RIDL, Fallout saldırıları adı verildi.

Tıpkı ilk üç zafiyette olduğu gibi, Zombieload, RIDL ve Fallout da Intel’in veri işleme hızlarını ve performansını iyileştirmek için CPU’larına eklediği bir optimizasyon tekniği olan spekülatif yürütme işleminden (speculative execution process) yararlanarak faydalanıyor.

Modern bilgisayar mimari organizasyonunda işlemciden depolama alanlarına gidildikçe kapasite artar ve maliyet düşer. Bununla paralel olarak ise daha yavaş bir çalışma performansı ortaya çıkar.

Bu piramide göre işlemci hafıza alanları, en hızlı hafıza birimi olmaktadır.

3.0 GHz bir işlemci ortalama saniyede 3 milyar kez hafıza alanlarına erişebilir.

Piramitte aşağıya doğru gidildikçe daha az pahalı olan L1, L2, L3… türü ön belleklerde işlenecek veriler tutulur. İşlemci tarafından işlenecek komut setleri hiyerarşiye göre hafıza alanlarına erişilerek işlemciye getirilir ve işlenilir.

Buradaki önemli olan ve işlemciler için yazılımsal olarak hız optimizasyonlarının yapılması ihtiyacı doğuran kısım, işlemcilerin nano saniyeler bazında işlem yapması. İnsanoğlunun algılarına 1 s gelebilen bir işlemci işlem zamanı bilgisayar nezdinde 0.3 ns gibi kısa bir sürede yapılmaktadır. İnsan için 1 s de gerçekleşen bu işlem, zaman olarak insanlar için çok küçük görülse de bilgisayarlar için büyük bir kayıp olarak atfedilebilir. Buna bağlı olarak günümüz modern işlemcilerinde veriler nano saniye boyutlarında işlendiği için maliyet kaybı yaşanmaması amacıyla pipelining (borulama – üst üste bindirme) vb. işlemci veri işleme optimizasyonları yapılmaktadır. Pipelining işlem biter bitmez ardışık başka bir işlemin belli parçasının zaman kayıpsız alıp işlenmesine dayanan bir optimizasyon tekniğidir.

Spekülatif yürütme işlemi ise işlemcinin ihtiyaç duyulmayacak bazı görevleri yerine getirdiği bir optimizasyon tekniğidir. İşin gerçekte gerekli olup olmadığı bilinmeden önce, gerekli olduğu bilindikten sonra işi yaparak gerçekleşmesi gereken bir gecikmeyi önlemek için yapılır. Sonuç olarak iş gerekli olmadıysa, işin yaptığı değişikliklerin çoğu geri döndürülür ve sonuçlar göz ardı edilir. Burada hedeflenen amaç işlem için ilave kaynaklara daha fazla eş zamanlılık sağlamaktır. Bu spekülatif yaklaşım pipeliningdeki değer tahminleri, bellek ve dosyaları önceden ayarlayıp tahsis etme, veri tabanı sistemlerinde eş zamanlılık kontrolü gibi alanlarda kullanılır.

Spekülatif yürütmeyi gerçek hayatla örtüştürecek olursak, X kentine 1 günlük iş için gittiğimizi düşünelim. X kentinde bahar olduğunu ve hava geçişlerinin sık olduğunu düşünelim. Anlık değişimlerle yağmurlu ya da güneşli olma durumları mümkün. Güneşli ve yağmurlu hava için birer kombini valizde götürmek, her hava değişiminde evimizi X kentine götürmekten daha hızlı ve pratik bir yol. Bilgisayar açısından bakacak olursak işlemci X kentindeki anlık hava değişimini beklemeden zamandan tasarruf etmek için giydirme işlemini nano saniyeler mertebesinde gerçekleştirecektir. Çünkü zaman kaybı işlemci açısından maliyet demektir. Zafiyetin ortaya çıkış noktası da tam olarak bu durumdan kaynaklanmaktadır. İşlemcinin spekülatif tahminleri ve tercihleri manipüle edilmektedir.

Spekülatif yürütmenin istekli (eager), predictive (öngörü) ve tembel (lazy) işletme olmak üzere 3 çeşit varyantı bulunmaktadır.

Akademisyenler Meltdown zafiyetinin keşfinden sonraki zaman süreci içerisinde spekülatif yürütme sürecinin bileşenlerine odaklanmış durumdaydılar. İşlemci tampon bellek bölgeleri ve veri işleme adımlarından nasıl veri sızdırabilecekleri üzerine yoğunlaşmış, Spectre ve Foreshadow gibi yeni zafiyetler keşfetmişlerdi.

Spekülatif yürütme işlemi üzerinden keşfedilen yeni zafiyetler ise Microarchitectural Data Sampling (MDS)ve Zombieload saldırıları olarak adlandırıldı. Depolama tampon bellek alanlarını hedef alan (CVE-2018-12126aka Fallout), yükleme tamponlarını hedef alan (CVE-2018-12127), satır dolgu tamponlarını hedef alan (CVE-2018-12130, aka RIDL) ve önbelleğe alınamayan bellek alanlarının istismarı (CVE-2019-11091 aka Zombieload) olmak üzere 4 farklı MDS saldırı tipi keşfettiler. Zombieload diğerlerinden daha fazla hassas ve kritik veriye erişebileceği için diğer MDS saldırılarına göre en tehlikeli durumda.

Programlar normalde yalnızca kendi verilerini işlerken, spekülatif yürütmeyi istismar eden saldırganlar başka işlemlere ait tarayıcı geçmişi, web sitesi içeriği, kullanıcı anahtarları ve şifreler/parolalar gibi kullanıcı düzeyinde bilgiler veya disk şifreleme anahtarları gibi sistem düzeyindeki bilgilere erişebiliyor. Zombieload saldırısını gerçekleştirecek saldırgan uygulamalar arasında var olan etkin gizlilik korumalarını atlatabileceği (bypass) edebileceği anlamına gelmektedir.

  • RIDL leaking root password hash
    https://www.youtube.com/watch?v=JXPebaGY8RA
  • RIDL leaking Linux kernel data
    https://www.youtube.com/watch?v=UV9GDcOWeeI
  • RIDL from JavaScript
    https://www.youtube.com/watch?v=KAgoDQmod1Y
  • Zombieload Attack
    https://zombieloadattack.com/public/videos/demo_720.mp4

Araştırmacılar bu zafiyetlerden 2011’den beri piyasaya sürülen tüm Intel işlemcilerin etkilendiğini belirttiler. Ayrıca masaüstü bilgisayar, mobil işlemciler (laptop işlemcisi) ve sunucu işlemcilerinin etkilendiği iletildi.

Öte yandan iyi haber olarak Meltdown ve Spectre zafiyetlerinden sonra üretilen Intel işlemcilerde (8. & 9. Nesil Core işlemciler ve 2. nesil Xeon işlemciler) spekülatif yürütme saldırılarına karşı koruma mekanizmaları geliştirildi ve optimizasyonlar yapıldı. Ancak Intel bu işlemciler içinde saldırı etkilerini azaltmak için bir öneri yazısı paylaştı. https://www.intel.com/content/www/us/en/architecture-and-technology/mds.html

Intel ise etkilenen işlemci versiyonları için yeni bir mikro servis kod güncellemesi yayınlaması bekleniyor. Ancak bu mikro kod güncellemelerinin optimizasyonlar üzerinde ciddi değişiklikler yaptığı için işlemcilerde performans kayıplarına sebep olacağı aşikâr. 8 ve 9 nesil işlemciler için yayınlanan etki azaltma öneri yazısında, BIOS’tan devre dışı bırakılması önerilen özelliklerin performansa etkileri olduğu gözüküyor.

Yakın gelecekte de işlemci türü zafiyetlerle fazlaca karşılaşacağız gibi gözüküyor. Araştırmayla ilgili yayınlanan makalelere ve Intel’in yayınladığı mikro kod güncelleme listelerine linklerden erişebilirsiniz.

  • https://cpu.fail/
  • https://zombieloadattack.com/
  • https://labs.bitdefender.com/2019/05/yet-another-meltdown-a-microarchitectural-fill-buffer-data-sampling-vulnerability/
  • https://mdsattacks.com/
  • https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html
  • https://www.intel.com/content/dam/www/public/us/en/documents/corporate-information/SA00233-microcode-update-guidance_05132019.pdf
  • https://www.intel.com/content/www/us/en/architecture-and-technology/engineering-new-protections-into-hardware.html
  • https://access.redhat.com/security/vulnerabilities/mds
  • https://support.google.com/faqs/answer/9330250
  • https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/adv190013
  • https://support.apple.com/en-us/HT210107

Kaynak: https://h4cktimes.com/guvenlik-aciklari/intel-zombieload-ve-mds-side-channel-saldirilari.html

Yazan: İsmail SAYGILI (Eczacıbaşı Bilişim)

Bir iş akışı sistemi, rutin iş süreçlerinin en yüksek verimlilik ile yürütülebilmesi, kuruluş iş süreçlerinin ve verilerinin dijital ortamda ilerletilmesi, saklanması ve izlenmesi için geliştirilmiş uygulamalardır.

Geleneksel iş süreçleri basılı formlar aracılığıyla elden taşınarak işletilir. Bu hem kâğıt israfına yol açmaktadır hem de süreçlerin takibini zorlaştırmaktadır. Bu karmaşa ve verimsizliği önlemenin yollarından en önemlisi süreçleri dijital ortama -doğru bir şekilde- aktarmaktır.

Son dönemde çokça karşılaştığımız kanban gibi, en basit agile uygulama yöntembilimi uygulayan uygulamalar, kendini iş akış yönetim aracı olarak tanıtabiliyor. Gerçek bir iş akışı uygulaması için, süreçleri dijitalleştirirken cevaplanması gereken konulara değineceğiz.

Süreç Sorumlusunun Belirlenmesi

Sürecin nasıl olması gerektiğinde son kararı verecek kişidir. Yeni özellikler, süreç eğitimi, yayılması ve kullanımı konusunda sorumludur. İş süreçleri yönetim sistemlerinde en kritik görevlerden biridir. Genellikle iş sürecini en iyi bilen, raporlayan ve süreç hakkında karar verici olan iş birimi çalışanı olur.

İş Akışı Diyagramı

Görselleştirmenin gücü üzerine konuşmamıza gerek yok sanırım. Grafik olarak akış kime gidecek, kimler onaylayacak uçtan uca çizilmelidir.

Akışların bazıları birbirini takip edebilir ancak bir birinden bağımsız yani birbirine bağımlı olmayan paralel akışlarda burada ayrıca belirtilmeli ve değerlendirmelidir.

Form Modelleme

Süreçte yer alan form ve ya formların bölüm ve alanların tek tek yazılması gereken bölümdür.

Alanları oluştururken aşağıdaki kurallara dikkat edilmelidir;

  1. Alanların tipi nasıl olmalı? (tarih, sayı, yazı, checkbox, listeden seçmeli)
  2. Çoklu ekleme olacak mı?
  3. Alanlar grafiksek görsel çizim alanı da göz önünde bulundurularak hangi adımlarda görünecek, değiştirilebilir olacak veya gizlenecek?

Rol Bazlı Erişim

Birçok iş akışı, sadece bazı kişilerin görmesi gereken hassas bilgiler içerir. Her İş Akışı Yönetim Sistemi, her kullanıcının görebileceği ve düzenleyebileceği formları özelleştirmenize izin vermelidir.

Süreci kim başlatacak, hangi kişiler onaylayıcı, hangi kişiler bilgilendirmede olacak sorularının yanıtlanması gerekmektedir.

Rol-Kullanıcı Delegasyonu

Bir rolde görev değişikliği olduğunda ve ya bir kişi işten ayrıldığında sürecin aksamaması için delegasyon tanımlarının da belirli olması gerekmektedir. Sürecin bu değişiklikleri yönetebileceği bir yapıda kurgulanması olası süreç hatalarının önüne geçecektir.

Bu yönetim parametre süreçleri dediğimiz yardımcı süreçler ile yönetilebilir. Parametre süreçlerinin de kim ya da kimler tarafından yönetilebileceği önceden planlanmalıdır.

Parametre Yönetimi

Süreç içerisinde yer alan parametrelerin statik değerler mi olacağı yoksa bir yardımcı süreç ile mi yönetileceği önceden belirlenmelidir. Parametre değişikliklerinde geliştiriciye ihtiyaç duyulmadan değişiklik gerçekleştirebilmelidir.

Farklı sistemlerle entegrasyonlar olacak ise bunun planlaması da süreç planlaması sırasında yapılmalıdır.

Süreç Raporları

Süreç çıktısı olarak bir rapor isteniyor mu, isteniyor ise hangi değerler raporda görülmek isteniyor sorusu İş Birimi tarafından yanıtlanmalıdır. Eğer mevcut rapor ile bu talep karşılanamıyor ise özel bir rapor geliştirilecek mi ya da harici bir rapor uygulaması kullanılacak mı soruları da yanıtlanmalıdır.

Rapor filtreleri belirlenmeli, rapor başlıkları tek tek belirtilmedir.

Yine aynı şekilde raporların da kimler tarafından görüntüleneceği belirlenmelidir.

SLA — Servis Süresi

İyi bir iş akışı yönetim sistemi, kuruluştaki tüm temel süreçler için tek adres olacaktır. Bu nedenle, iş akışı aracınız herhangi bir zamanda çalışan 30’dan fazla iş akışına sahip olabilir. Bunların hepsini bir gösterge tablosunda görüntülemeyi düşündüğünüzde, tüm görevlerinizde güncel kaldığınızdan emin olmanız için bir yol gerekir.

Akış tasarlanırken, adımlarda hatırlatma başlangıç süreleri, hatırlatmanın ne sıklıkla yapılması gerektiğinin belirlenmesi gerekmektedir.

Bir adım ne zaman zaman aşımına uğramalı veya yöneticisine delege edilmeli gibi konuların netleşmesi gerekmektedir.

Akış Karar Dallanmaları

Akış tasarlanırken eğer farklı dallanmalar olacak ise(fiyat veya rol gibi hangi parametreye bağlı olacağı) kuralların belirtilmesi gerekmektedir.

Entegrasyon

İş süreçleri sistemleri farklı uygulamalarla kolayca entegre olabilecek sistemlerdir. Bazen bir HUB görevi görürler. RPA uygulamaları, IOT ve Raporlama sistemleri, SAP gibi tüm diğer uygulamalardan veri alabilir veya gönderebilirler.

Yapılacak entegrasyonlar için mümkün ise her iki uygulamanın danışmanının birlikte hareket etmesi gerekmektedir. Entegrasyonlar iş süreçlerinde en çok hata alınan noktalardır. Bu nedenle kurgulanırken en çok hassasiyet gösterilmesi gereken alan olmalıdır.

Ayrıca mükerrer veri gönderimlerini önlemek için kurgunun bu konuları da önleyecek şekilde yapılması gerekmektedir.

Süreç Dokümanları

Süreçlerde doküman eklenmesi olmazsa olmazdır. Eklenen dokümanların akıbetinin de süreç kurgulanırken planlanması gerekmektedir. Dokümanlar versiyonlanacak mı? Nerede saklanacak? Kullanıcılar süreç sonlandıktan sonra dokümanlara nasıl erişecek gibi temel bir takım soruların yanıtlanması gerekmektedir.

İstisnai Durumlar

Süreçler tasarlanırken kuruluşlara özel olan istisnai durumlar da mutlaka göz önüne alınmalıdır. Örneğin; Yönetim Kurulu veya CEO, YKB gibi rollerde süreç nasıl davranmalı? Bu tip istisnai durumların önceden belirlenmesi daha sonra süreçlerin tekrar tekrar düzenlenmesinin önüne geçecektir. Ayrıca istenmeyen durumların da önüne geçecektir.

E-posta

E-posta ile gelecek bildirimlerde hangi bilgiler olacak. Hangi adımlarda ek bilgilendirmeler olacak sorularının cevaplanması gerekmektedir.

Sonuç

Dijital dönüşüm ve dönüşümün de değişimi her geçen zaman daha farklı boyutlara erişiyor. İş birimlerinin istekleri sürekli artıyor ve BT tek başına, sistemlere cevap verebilecek kadar büyüyemiyor. Dolayısı ile hepimizin bu dönüşümün yükünü paylaşmamız gerekiyor.

BT’nin projelere ayırdığı analiz süreleri proje süresinin neredeyse yarısını kapsıyor. Kaldı ki BT’nin süreç analizine dâhil olmadığı durumlarda ortaya çıkan projeler kullanılmayan sistemler yaratıyor.

İş süreçleri otomasyonu araçlarının en önemli getirisi de bu dönüşümde oyuna herkesi katabiliyor ve iş birimleri seviyesine inebiliyor olmasıdır.

İş süreçleri, teknolojinin doğru seçilmesinin yanında, kültür ve BT felsefesini de kapsadığından dolayı doğru çıktılar üretmek için bütünsel olarak iyileşmelere gidilmelidir.

SAP’nin 25 Ekim 2018’de düzenleyeceği forum ile birlikte (artık SAP Forum değil SAP Now demektedir) geçmişte üzerine yoğunlaştığı “Digital Transformation” kavramı yerine “Intelligent Enterprise” kavramını dile getirmeye başlayacak.

Intelligent Enterprise’ı temel olarak aşağıdaki görselde aktarmaya çalışacak. Aşağıdaki diyagramda şunu anlatıyor; en altta veri yönetimi ve bulut platformu (Digital Platform), yukarıda iş uygulamaları (Intelligent Suite) ve ortada ise akıllı teknolojiler AI, ML, IoT ve Advanced Analytics yer almaktadır. Özetle bulut üzerinde tüm uygulamalarınızı akıllı teknolojilerle destekleyerek yeni bir ortam sunmaya çalışıyor. Yapay zeka, makine öğrenimi, nesnelerin interneti (IoT), büyük veri, ileri analitik ve blockchain gibi teknolojiler daha yaygın ve kullanılır hale geldi, şirketler ya adapte olmalı ya da geride kalmanın riskini almalı demektedir.

Biraz geçmişe gidersek, 2017 yılında SAP Leonardo ile aşağıda görüldüğü gibi ticari/operasyonel işlemleri akıllı içgörüler ile birleştirdiği, dijital dönüşüm süreçlerini destekleyen bir gelişim platformu sunduğunu anlatmıştı (anlatmaya çalışmıştı). Makine öğrenimi ile dijital iş planını, blockchain ile lojistik işlemlerini, büyük veri ile inovasyonu, IoT ile üretimi ve analitik ile operasyonu eş zamanlı destekleyeceği bir platformdan bahsediyordu. 2018 ‘de ise bu anlattıklarını daha belirgin bir yapıda ve özellikle bulutun önemini ön plana çıkararak sunmaya çalışmaktadır.

Sonuç olarak “Digital Transformation” geride kaldı artık “Intelligent Enterprise” var diyor. 25 Ekim’de gerçekleşecek SAP Now etkinliğinde çokça duyacaksınız. Şirketleri bulut platformuna taşımaya çalıştığı için tüm önemli geliştirmeleri öncelikle bulut üzerinde sunacaklar. Görünen o ki belki 10 sene sonra bulut üzerinde daha sade ve dünyadaki best practice ‘lere uygun yapıda süreçlerle ilerleyen çok fazla şirket olacak. S/4 ‘un ismine de yerleştirdiği gibi sadeleşerek gereksiz ve fazla yüklerden kurtulmayı önermektedir. Bu nedenle bulut ile ilgili yapılan çoğu açıklamalarda öncelikle organizasyonların bakış açılarını değiştirmesi gerektiğini vurgulamaktadırlar.

SAP’nin 2017 ‘den 2018 ‘e yaklaşımında nelerin değiştiğini ve yeni nesil iş modelleri için önerdiği yönü kısaca aktarmak istedim.

SAP NOW’da görüşmek üzere.

Yazan: Mehmet KURTARAN (Eczacıbaşı Bilişim)

Microsoft System Center Operation Manager 2007/2012/2016 uygulaması bildiğimiz üzere uçtan uca monitoring yapabileceğimiz bir uygulamadır. SCOM 2007/2012/2016 ürünü istediğimiz Server,Uygulama ,Network Cihazları vb. Uygulamaları izleyebilmek için Management Packlere ihtiyaç duymaktadır. Bu management packler ise uygulamaları geliştiren firmalar tarafından yazılmış ve yayınlanmış olması gerekmektedir. Eğerki elinizde izlemek istediğimiz uygulama için bir management pack var ise SCOM 2007/2012 uygulaması içerisine Import edilir ve monitoring işine başlayabilirsiniz.

Pekala elimizde bir ürün ya da uygulama var fakat management pack yazılmamışsa ne olacak?

Bu makalemde sizlere ihtiyaç duyduğumuz ama management packi bulunmayan bir durumda nasıl custom bir management pack oluşturabiliriz bunu anlatmaya çalışacağım.

Bir management Pack oluşturabilmek için bazı temel kavramlar vardır ve bu kavramları gerçekten iyi anlamak gereklidir. Bu kavramları başka bir makalede anlatıyor olacağım.

Yeni ve Custom bir management pack oluşturabilmek için aşağıdaki linkte bulunan System Center Operation Manager 2007 R2 Authoring Tool ihtiyacımız bulunmaktadır.

http://www.microsoft.com/en-us/download/details.aspx?id=18222

Öncelikle oluşturacağımız management pack için ihtiyaçlarımızı gerçekten iyi bir şekilde belirlememiz gerekmektedir. Management Pack oluşturmak için öncelikle senaryomuzu oluşturalım.

Senaryo :

  • Mevcut yapımda bir adet System Center Operation Manager 2012 bulunmakta.
  • SCOM 2012 uygulaması ile sunucular monitor edilmekte ve üzerlerinde antivirüs yazılımı olarak Symantec Endpoint Protection Manager bulunmakta.
  • Sunucular üzerinde Symantec AV uygulamasının aktif olup olmadığını aynı zamanda veritabanının güncelliğini kontrol etmek istiyorum (Servis Takibi,Veritabanı güncelliği,vb)

Evet yukarıda örnek bir senaryomuz var bizde bu senaryoya uygun olarak bir management pack oluşturacağız ve takibine başlayacağız.

Bunun için öncelikle kurulumu yaptığımız SCOM 2007 R2 Authoring Consol’e açıyoruz ve yeni bir proje başlatıyoruz.

Bunun için öncelikle File ve New seçenekleri ile Empty Management Pack seçimi yapıyoruz. Yeni oluşturacağımız management pack için birde isim veriyoruz ve Next ile geçiyoruz.

Display Name kısmına Management pack için display name tanımlamasını yaparak Create ile management pack oluşturmuş oluyoruz.

Management Packimiz için Service Model tabına geçiyoruz ve yeni bir Class oluşturacağız. Class nedir,neden class oluştururuz gibi konuları bir başka makalede yazıyor olacağım.

Class tanımlamak için resimdede görüldüğü gibi önce New ardından da senaryomuz göre localde çalışan bir uygulama için kurduğumuzdan Windows Local Application seçimini yapıyoruz.

Oluşturmaya başladığımız class için bir ID tanımı ve class için Display Name tanımını yapıyoruz ve Next ile ilerliyoruz.

Gelen pencerimizde herhangi bir key tanımı yapmıyoruz ve Finish diyerek yeni Classımızı oluşturmuş oluyoruz.

Yukarıda da görüldüğü üzere classımız oluşmuş durumda. Ancak Classımız ile işimiz bitmedi. İzleyeceğimiz ve senaryomuza göre takibini gerçekleştireceğimiz alanlarımızı tanımlamamız gerekiyor.Bunun için oluşturmuş olduğumuz Classımız üzerinde sağ klik yapıyoruz ve Properties kısmını seçiyoruz.

Gelen ekranda Properties tabına geçiyoruz ve System Entity altında yine sağ klik yaparak Add Property seçimini yapıyoruz.

Senaryomuza göre bizler takibini yapacağımız yani izleyeceğimiz alanlarımızı burada tanımlamalarını gerçekleştiriyoruz. Bizler Version,Uygulamanın adını ve bağlı olduğu servisin takibini yapacağımızı öncesinde belirtmiştik. Tanımlamalarımızı buna göre yaptıktan sonra uyguluyor ve işimizi burada da bitirmiş oluyoruz.

Class ile işimizi bitirdikten sonra sırada önemli olan bir başka ayrıntımız Symantec Endpoint Protection uygulamamızın kurulu olduğu sunucuları keşfetmekde. Bunun için yukarıda ki resimde görüldüğü üzere Health Model tabı altında Discoveries seçimini yapıyoruz.

Sağ taraftaki alanda sağ klik ile New ve Registry (Filtered) seçimini yapıyoruz. Bu noktada yukarıdaki resimde de görüldüğü üzere farklı discovery seçimleri mevcut kendinize uygun olan seçimi yaparak farklı yollarda deneyebilirsiniz. Hele powershell ‘e hakimseniz yapılamayacak şey bulunmuyor desek yeridir.

Yeni bir Discovery oluşturma kısmında yine bir ID ve display name tanımını yapıyoruz.Target olarak Windows Server Computer olarak belirliyoruz ve Next ile ilerliyoruz.

Oluşturacağımız keşfetme (Discovery) için ne kadar sürede bir kontrol edeceğini yani ne sıklıkta keşfe çıkacağını belirliyoruz. Bu tanımı yaptıktan sonra Next ile bir sonraki adıma geçiyoruz.

Açılan ekranda Next ile bir sonraki ekrana geçiyoruz.

Discovery tanımını yaparken Registry (Filtered) seçimini yapmıştık. Bu adımda aslında ilk başta oluşturduğumuz Classımızda tanımladığımız Property leri keşfederek dolduruyor olacağız. Aynı zamanda Symantec Endpoint Protection uygulamasının yüklü olduğu sunucuları keşfetmek içinde bu adımdan faydalanacağız.

Register altında Symantec Endpoint Protection uygulaması yüklü ise

HKLM\SOFTWARE\Symantec\Symantec Endpoint Protection

Anahtarı bulunmakta bende keşif yaparken bu anahtarı kullanıyor olacağım. Yukarıdaki resimde görüldüğü gibi key için tanımlamaları yaptım. Diğer alanlar içinde aynı yolu kullanabilirsiniz.

Gerekli tanımlamaları yaptıktan sonra Next ile bir sonraki adıma geçiyoruz.

Bu penceremizde ise bir önceki adımda tanımladığımız registry değerleri için eşitleme seçeneklerini yapıyor olacağız. Ben bu adımda Symantec Endpoint Protection uygulaması için keşif işlemi yapmak istediğimden yine bir önceki adımda tanımladığım anahtar değerinin varlığını kontrol ettim. Eğerki bahsedilen anahtar sunucudaki registry altında var ise Symantec Endpoint Protection bulunduğu anlamına geliyor. Next diyerek bir sonraki adıma geçiyoruz.

Gelen ekran aslında bizim için en önemli ekranlardan bir tanesi. Oluşturmuş olduğumuz Class ı seçiyoruz. Seçtikten sonra yine Class içerisinde oluşturduğumuz property ler burada görünüyor.

Yukarıdaki resimde de görüldüğü üzere ve register altından sorguladığımız değerlerimizi gerekli yerlere map edeceğiz.

Bunun için

Version bilgisi için $Data/Values/Version$

Application Name için $Data/Values/ApplicationName$

Service Name için $Data/Values/ServiceName$

Bilgilerini giriyoruz ve finish ile işimizi bitiriyoruz.

Oluşturmuş olduğumuz management packimizi System Center Operation Manager 2012 uygulamamıza Export edeceğiz.Oluşturmuş olduğumuz management packi kaydederek manuel olarakda Import edebiliriz.Ben SCOM 2012 sunucumun olduğu ortamda çalıştığım için direk Authoring Tool consoleden Export işlemini yapacağım.Bunun için Export MP to Management Group seçimini yapıyorum.

ve scom2012 uygulamamın kurulu olduğu sunucuya yukarıda ki resimde görüldüğü üzere connection sağlayacak ve managament packi uyguluyor olacak.

Management Pack yüklendikten sonra SCOM 2012 uygulamamız da Monitoring tabına geçiyoruz. Monitoring tabı altında bulunan Discovered Inventory alanını seçiyorum.Sağ tarafta bulunan Task panelinden Change Target Type seçimini yapıyorum.Gelen Search ekranında oluşturmuş olduğumuz management pack’i seçerek ok diyoruz.

Yukarıdaki resimde görüldüğü üzere Symantec Endpoint Protection yüklü olan sunucular keşfedilmiş ve bizlerin tanımlamış olduğu Propertylerde dolmuş durumda.

İşimiz elbetteki bitmedi bizler şu anda symantec endpoind protection uygulamasının yüklü olduğu sunucuları sadece keşfettik herhangi bir monitoring(izleme) yapılmamakta. Makalemizin ikinci bölümünde managament pack içerisinde Monitoring,Rule ,Presentation gibi kısımları tanımlıyor olacağız.

Yazan: Yenal TIRPANCI (Eczacıbaşı Bilişim)

System Center Configuration Manager 2012 ile birlikte hayatımıza giren yeniliklerden bir taneside Software Update Automatic Deployment Rule dir. Bu özelliğimiz biz sistem yöneticilerini ciddi bir yükten kurtarmakta. Daha önceki sccm uygulamalarında software update dağıtımı yaparken izlediğimiz adımları gözümüzün önüne getirdiğimizde. Öncelikle dağıtımını yapacağımız güncelleştirmeleri için search folder oluşturup daha sonra bu güncelleştirmeler için paketler yapıp daha sonrada deployment paketlerini oluşturuyorduk. Sadece bu kadarla bitmiyordu microsoft tarafından yayınlanan ve dağıtımları yapılmamış güncelleştirmeleri bulup paketleri içerisine yeniden eklememiz gerekmekteydi . Buda şu demekti her ay rutin kontroller edilmeli çıkan updatelerin kontrolü sürekli yapılması gerekliydi.

SCCM 2012 ile birlikte bu yükün fazlalığının farkına varılmış ve Automatic Deployment Rule kavramını bizlere sunmuştur. Automatic rule ile bizler bir kere gerekli tanımlamaları yapıyoruz. Yani WSUS ile senkronize olma zamanını senkronizasyon sonrasında yeni gelen güncelleştirmeleri otomatik olarak paket içerisine dahil edip yine belirttiğimiz collection için dağıtımını gerçekleştirmesini sağlayabilmekte. Bununla birlikte bir kere konfigürasyonu gerçekleştirdikten sonra tekrar tekrar kontrol etmeye ve paketler oluşturmaya gerek kalmamakta.

Peki şimdi Automatic Deployment Rule oluşturmaya başlayalım.

Öncelikle Software Library – Software Update – Automatic Deployment Rules üzerinde sağ klik ve Create Automatic Deployment Rule seçimini yapıyoruz.

Gelen ekranımız isimlendirmemizi yapıyoruz. Template kısmına default kurulumla birlikte gelen templateleri kullanabilir ya da herhengi bir seçim yapmadan kendimiz spesifik değerleri tanımlayabiliriz.Ben burada default kurulumla gelen Definition Updates template kullanıyorum.Collection seçiminide gerçekleştiriyorum. Bir önceki makalemizde oluşturduğumuz collection yapısını kullanacağım.

Definition template seçimini yaptığımda Add to existing Software Update Group seçimini zaten kendisi yapmakta. Bu şu demek var olan bir paketimiz bulunmakta ve dağıtımı gerçekleştirilen bu pakete içerisine yeni gelen ya da bulduğun paketleri ekle demek. Eğer hiç böyle bir paketiniz yok ise Create a new software update seçimini yapabilirseniz. Bu adımlarımın hepsini tanımladıktan sonra Next ile ilerliyorum.

Dağıtım paketlerinde oluşacak başarılı yada hatalarla ilgili detay tanımını gerçekleştiriyorum ve next ile ilerliyorum.

Gelen ekranımızda bizler ilk olarak var olan pakete ekle seçimini yapmıştık.işte burada o pakete hangi kriterlerde bir search yapacağız ve bu kriterlere göre schedule olarak tanımladığımız zaman aralıklarında bu tanımlamalara göre paket içerisine güncelleştirme paketlerini ekleyecektir. Gerekli tanımlamaları yaptıktan sonra next ile ilerliyorum.

Bu penceremizde ise oluşturduğumuz Automatic Deployment Rule ne zaman çalışacak bilgilerini tanımladığımız alanımız. Ben Run the rule on a schedule seçimini yapıyor ve Custom olarak zaman değerlerini tanımlamaya başlıyorum.

Custom zaman olarak ben her ayın ikinci Perşembe gününü seçiyorum ve saat olarak gece 01:00 olarak tanımladım.

Burada önemli olan parametre ayın ikini haftası. Çünkü Microsoft güncelleştirmeleri her ay ve her ayın ikinci Salı günü yayınlamaktadır. Bundan dolayı bu kuralında her ayın ikinci haftası ve Salı gününden sonra çalışmasını tanımladım.

Gerekli tanımlamaları yaptıktan sonra bu adımıda sonlandırıyorum.

Gerekli zaman değerlerini tanımladıktan sonra next ile ilerliyorum.

Gelen penceremizde ise güncellemeleri bulduktan sonra bir saat sonra dağıtıma başlaması gerektiğini tanımladım. Bunun nedeni ise bulmuş olduğu yeni güncelleme paketlerini distribution pointlere kopyalarını göndermesi için gereken zaman opsiyonu için bu şekilde tanımladım. Sizler As soon possible diyerek en uygun anında gönderebilirsiniz.

Deadline olarak herhangi bir zaman tanımını gerçekleştirmedim. Bunun nedenide gören her client anında yüklemesini istediğim için bu seçimi gerçekleştirdim. Bir diğer nedende collection içerisine yeni atanmış bir sunucu ya da clientın o update paketlerini yüklemesini istediğim içindir.

Gerekli tanımları gerçekleştirdikten sonra ilerliyoruz.

Yine bir önceki makalemizden hatırlayacağınız üzere notification bilgilerini ve sunucu ya da clientların yükleme sonrasında restart işlemini engellemek için gerekli seçimleri gerçekleştirdik ve next ile ilerliyoruz.

Gelen ekran üzerinde alertler ile ilgili olarak herhangi bir seçim yapmıyorum ve ilerliyorum.

Collection içerisinde bulunan ve tanımladığımız güncelleştirme paketlerinin download etmesi gerektiğini belirtiyor ve ilerliyoruz.

Bu ekranımızda ise deployment package oluşturacakmıyız yoksa var olanımı kullanacağız. Bizler zaten dağıtımını gerçekleştirdiğimiz bir dağıtımımız vardı bundan dolayı yeni bir paket oluşturmak yerine var olanın içerisine dahil ediyoruz ve ilerliyoruz.

SCCM uygulamamız WSUS ile senkronize olduktan sonra ve bizim tanımladığımız kriterlere göre yeni bir güncelleştirme bulmuş ise bunu internetten indirmesi gerektiğini belirtiyor ve ilerliyoruz.

İhtiyacımız olan güncelleştirme paketleri için dil ya da dilleri seçiyor ve ilerliyoruz.

Yine bir özet ekranı herhangi bir problem görmüyor isek next ileilerleyebiliriz.

Ve artık sona geldik. Close seçimi ile kuralımızı oluşturmuş ve Automatic deployment rule artık belirlediğimiz kurallara göre çalışmaya başlayacaktır.

Yazan: Yenal TIRPANCI (Eczacıbaşı Bilişim)

System Center Configuration Manager 2012 uygulamamız bizlere sunucu ve istemci tarafında bir çok yönetimsel avantajlar ve kolaylıklar sağlamaktadır. SCCM uygulamamız ile yazılım dağıtımı , işletim sistemi dağıtımı ,envanter yönetimi gibi ve bunun gibi bir çok yönetimsel başlıklar sayabiliriz. Bizler bu yazımızda Software Update yönetimini ve nasıl dağıtım yapacağımızı ele alacağız.

Organizasyonumuz için temel işlerden biride software updateleri ve bunların en önemlisi security updatelerinin olduğunu hepimiz biliyoruz. Daha önceki SCCM 2007 ile software update dağıtımları ile ilgili makalemizdede detaylıca belirttiğimiz gibi SCCM ile software update dağıtımı sayesinde esnek güncelleştirme dağıtımları ve bu dağıttığımız güncelleştirmelerle ilgili olarak bizlere raporlar sunması, istemcilerimizin ihtiyaçlarını belirlemesi,uyumluluk istatistiklerini alabilmekteyiz.

Software Update dağıtımını ve yönetimini yapabilmek için öncelikle SCCM 2012 konsolu üzerinde organizasyonumuzun ihtiyaçlarına ve yönetimsel olarak da biz sistem yöneticilerine bundan sonraki adımlarda kolaylık olması açısından collection yapımızı oluşturmakla başlayalım.

SCCM 2012 konsolu üzerinde Assets and Compliance tabına geçiyoruz. Bildiğiniz üzere SCCM 2012 ile birlikte klasör yapısıda biz sistem yöneticilerinin karşısına çıkmıştı.Ben öncelikle klasörlerimi oluşturdum ve oluşturmuş olduğum klasör üzerinde sağ klik yaparak Create Device Collection seçimini yapıyorum.

Gelen ekranda öncelikle oluşturacağım collection için isim veriyorum ve next ile ilerliyorum.

Collection içerisinde hangi üyeler olmasını istiyor isek üye olarak ekliyoruz. Dikkat ederseniz ilk oluşturduğum collection bir test collectioni. Dağıtımı yapacağım software update lerinin etkilerini bilmiyoruz. Bunun için öncelikle test collection oluşturmakta fayda var.Üye eklerken query based ya da direk sunucu ya da istemci ekleyebiliriz. Ben şu anda eklemedim ama sizler ekleyebilirsiniz. Next ile bir sonraki adıma geçelim.

Collection isimlendirme ve collectiona ait açıklamalarla ilgili olarak bir özet ekranı. Herhangi bir değişiklik yapmayacak isek next ile ilerliyoruz.

Ve collection yapımızı oluşturmuş olduk. Close ile collection oluşturma işlemimizi tamamlamış oluyoruz.

İhtiyacımız olan ve dağıtımı hangi collection üzerinde gerçekleştireceğimizi tanımladık.Böylelikle ilk adımı bitirmiş olduk.

Şimdi ikinci adımda ise hangi updateleri dağıtımını yapacağımızı belirleyeceğiz.

Yine SCCM 2012 konsolumuz üzerinde Software Library – Software Updates tabımıza geçiyoruz. All Software Updates seçimini gerçekleştiriyoruz ve bu pencerede WSUS uygulamamız ile senkronize olduktan sonra bizlerin dağıtımını gerçekleştireceğimiz updateleri görmekteyiz. Ben Collection oluştururken Windows Server 2008 isimlendirmesini yapmıştık. Bu şu demek collection içerisinde sadece Windows Server 2008 ve R2 sunucuları barınacak bu sunular içinde tabiiki Windows Server 2008 işletim sistemine sahip güncelleştirmeleri dağıtımını gerçekleştirmeliyiz. Search bar üzerinde istediğim kriterleri girerek filtreleme yapabiliyor olmamızla birlikte daha detaylı kriterler belirleyebiliriz. Daha fazla uzatmadan ve örnek olması açısından sadece bir tane Security Update seçimini yapıyorum ve sağ klik ile Software Update Groups oluşturuyorum.

Resimde görüldüğü üzere Software Update Group ismi olarak da Windows Server 2008 olarak tanımladım. Create diyerek onaylıyoruz ve grubumuzu oluşturmuş oluyoruz.

Evet artık grubumuzu oluşturduk ve grup içerisine almış olduğumuz update için toolbar üzerinden Download seçimini gerçekleştiriyoruz.

Download seçimini yaptıktan sonra açılan penceremizde yeni bir Deployment Package oluşturacağız. Deployment Paketi için isimlendirme bilgisini tanımladıktan sonra bir önceki adımda seçimini yaptığımız güncelleştirmeyi nereye download edeceği bilgisinide giriyoruz ve next ile ilerliyoruz.

Bir sonraki penceremizde ise dağıtımı yapacak fakat bu dağıtımı yapacağı paketleri hangi distribution point üzerinden gerçekleştireceğiz. Bunun için Add diyerek Distribution Point Group ya da sadece tek bir Distribution Point seçimini yapabiliriz. Gerekli seçimleri gerçekleştirdikten sonra Next ile ilerliyoruz.

Burada ise paketlerin Distribution Pointleri gönderirken önceliğini tanımlıyoruz. Default olarak Normal gelmekte ben makalemde ve kendi yapımda yüksek öncelik vererek ilerliyorum.

Güncelleştirmeyi internet üzerinden download etmesini istiyorum ki ilk kurulum konfigürasyonumda zaten buydu. Next ile ilerliyoruz.

Güncelleştirme paketini download edecek fakat hangi dilde ya da dillerde ihtiyacınız varsa onun seçimini yapıyoruz. Seçimi yaptıktan sonra next ile ilerliyoruz.

Yine bir özet ekranı herhangi bir değişiklik yapmayacak isek next ile ilerliyorum.

Artık dağıtımını yapacağımız software update download etmiş bulunmaktayız. Download edilen dosyayı belirttiğimiz dizin altında görebiliriz.Close diyerek bu adımımızıda sonlandırıyoruz.

İkinci adımımızda bizler hangi güncelleştirmenin dağıtımını yapacak isek ona göre bir grup oluşturduk. Oluşturduğumuz grup içerisine dahil ettiğimiz güncelleştirmelerin indirme işlemlerini gerçekleştirdik.

Şimdi ise bu indirmiş olduğumuz güncelleştirmenin dağıtımını gerçekleştireceğiz.

Dağıtım yapabilmek için yine Software Update Groups altında bulunan ve bir önceki adımda oluşturduğumuz grubumuzu seçiyor ve toolbar üzerinden bu kez Deploy seçimini gerçekleştiriyoruz.

Açılan penceremizde dağıtım yaparken kullanacağımız isim bilgisini giriyorum. Görüldüğü gibi Software Update Group tanımı resimde görülmekte. İlk adımda oluşturduğumuz ve dağıtımı hangi collection üzerinde gerçekleştireceğimizin seçimini yapıyoruz.Next ile ilerliyoruz.

Bu penceremizde ise güncelleştirmeyi dağıtırken bunun zorunlu olarakmı yüklenecek yoksa available olarak seçerek kullanıcıya mı bırakacağız. Bu bir yazılım paketi olsa idi belki kullanıcıya bırakılabilirdi fakat güncelleme ve bu güncelleme bir security güncellemesi ise zorunlu seçimi yapılması mantıklı. Resimde görüldüğü gibi Required seçimini yapıyor ve Next ile ilerliyorum.

Gelen yeni ekranımızda ise güncelle dağıtımının ne zaman başlayacağı ve bir deadline yani yükleme işlemini yapmasını yapmayan clientlar için ise belirtilen tarihte force edileceğini tanımlıyorum ve next ile ilerliyorum.

İlk seçimde notification yani kullanıcı uyarıları ile ilgili tanımları yaparken sunucu ya da istemcinin güncelleştirme yüklemelerini gerçekleştirdikten sonra restart işleminin yapılmasını engellemek için seçimleri gerçekleştiriyoruz ve next ile ilerliyoruz.

Gerekli alert seçimlerini gerçekleştirebileceğimiz ekranımız. Herhangi bir değişiklik yapmıyorum ve next ile ilerliyorum.

Güncellemeleri yüklemek için istemcilerin gerekli yükleme dosyalarını lokalinde bulunan Windows altında bulunan ccmcache dizinine download edecektir. Eğerki network yavaş ise bu download işleminin nasıl davranması gerektiğini seçimini gerçekleştireceğimiz ekranımız.Next ile ilerliyoruz.

Yine bir özet ekranı herhang bir değişiklik yapmayacaksak ve bütün adımlar istediğimiz gibimi kontrollerini gerçekleştirdikten sonra next ile ilerliyoruz.

Bu pencere üzerinde bulunan Save As Template seçimini yaparsak

Resimde görüldüğü üzere kaydedebiliriz ve bütün bu adımları bir sonraki oluşturduğumuz paketlerde kullanabiliriz.

Ve artık son penceremiz. Close ile oluşturduğumuz güncelleştirme paketinin dağıtımını tanımladığımız collectionlar üzerinde dağıtımını gerçekleştirmiş olduk.

Yazan: Yenal TIRPANCI (Eczacıbaşı Bilişim)

Bir çok kurum,işletme mevcut organizasyonlarının güncelliğini korumak ve merkezi yazılım güncellemeleri için Windows Server Update Service (WSUS) uygulamasını kullanmaktadırlar.Bu güncellemeler neler olduğundan bahsedecek olur isek Güvenlik Güncellemeleri,Yazılım Güncellemeleri,Service Pack Paketleri ve Güncelleme paketlerinden bahsedebiliriz.System Center tarafında ise bizler WSUS entegrasyonu yapmamıza olanak sağlamaktadır.SCCM ile yazılım ve hizmet güncelleme paketlerini yönetmek için WSUS entegrasyonu yapabilmekteyiz.

Peki WSUS ile SCCM 2007 entegrasyonunun yapılmasının bizlere geri dönderdiği kolaylıkları ve avantajlardan bahsetmek gerekirse…

  • Esnek Güncelleme dağıtımı …Software Update yeteneği ile güncellemelerin taranması taranan bu güncelleştirmelerin onaylanması ve istemciler için dağıtım zamanlaması yapılabilirliği,Bütün bunlara ek olarak SCCM diğer yazılım güncellemelerini içerebilmektedir.Daha da ileri gider isek SCCM diğer istenen donanım ve yazılım yönetimi sayesinde Collection Based ( Kolleksiyon tabanlı ) güncelleme dağıtımı yapabiliyor olması en büyük yeteneklerinden biridir…
  • SCCM 2007 ile birlikte WSUS entegrasyonu sonrasında yazılım güncelleştirmeleri Internet ve Intranet tabanlı yönetim sağlamaktadır.
  • Gelişmiş raporlama ile uyum istatistikleri,Dağıtım raporlaması yapılabilmektedir.
  • Ağ erişim koruması için destek vermektedir.Windows NAP ( Network Access Protection ) ile entegre olabilmesi mümkündür.Clientların hangi yazılım güncelleştirmelerine ihtiyacı olduğunu sorgulamak ve SCCM tarafından gereken güncelleştirme paketlerini verebilmesi erişimin mümkün olması gerekmektedir. Organizasyon yapımızda bulunan clientların NAP üzerinde bulunan sağlık politikalrına uyumlu hale gelebilmek için yazılım güncellemelerini gönderebilmekteyiz.

WSUS Kurulumunun yapılabilmesi ve SCCM ile entegrasyonu yapılabilmesi için minumum gereksinimler…

  • WSUS 3.0 SP1 veya üzeri
  • WSUS 3.0 Administration Console SP1 veya üzeri
  • Windows Update Agent 3.0
  • Windows Installer 3.1
  • BITS Hizmeti

Olması gerekmektedir…

Öncelikle Windows Software Update Service Kurulumundan başlayalım…

Windows Server 2008 R2 üzerinde kurulu olan System Center Configuration Manager sunucusu üzerinde

Server Manager — Roles — Add Roles penceresini açıyoruz…

Windows Server Update Services Rolünü seçiyoruz ve Next ile ilerliyoruz…

Karşılayan penceremiz WSUS kurulum sihirbazıdır …

Microsoft un klasik Lisans anlaşma sözleşmesi…Kabul ediyor ve Next ile ilerliyoruz…

Karşılayan ekranımız Windows Update paketlerinin tutulacağı dizini sormakta.Ben D sürücüsünü ve klasör olarak da WSUS olarak tanımladım…

Database için internal database seçimini yaptım ister isek SQL Server üzerinde de tutabiliriz.Next ile ilerliyorum…

Karşılayan ekranımız bizim için son derece önemli var olan IIS sunucusu üzerinde mi Update dağıtımı yapacağız yoksa IIS üzerinde yeni bir dizin mi açacağız…SCCM sunucumuz üzerine kurulum yaptığımızdan Managament Pointte bu sunucu üzerinde olduğunda ben yeni bir dizin oluşturmasını ve port olarakda default olarak kendisinin 8530 ve SSL portu olarak 8531 nolu porttan yayın yapmasını gerektiğini seçimini yaparak Next ile ilerliyorum…

Karşılayan ekranımız bize özet sunmakta eğer herhangi bir problem görünmüyor ve gözden kaçırdığımız bir şey yok ise Next ile ilerliyorum…

Ve Finish ile kurulumu sonlandırıyorum…

Role ekranımızda ise kurulumun başarılı bir şekilde kurulumunun yapıldığını görmekteyiz…Close seçimini yapıyoruz ve WSUS sunucumuzun hazır olduğunu görüyoruz…

Not: Burada normal şartlar altında WSUS sunucusunun kurulumu yapılırken bizleri Wizard ekranı karşılar ve hangi ürünlerin Update alacağı hangi dil güncelleştirmelerinin yapılacağı,hangi saatler arasında Microsoft sitesine gideceği ve senkronizasyon yapacağı gibi bilgileri tanımlamamız gerekirdi.SCCM için bunu yapmaya gerek görmüyoruz çünkü SCCM tarafında bizler bu konfigurasyon bilgilerini zaten çektiriyor olacağız…

Yazan: Yenal TIRPANCI (Eczacıbaşı Bilişim)

Bu makalemizde System Center Operation Manager üzerinde oluşturmuş olduğumuz User Account Control isimli Rule ile lock olan kullanıcıların durumlarını monitor ediyorduk. Oluşturduğumuz bu monitor bir Alert Rule idi ve Alert Rule ler Alert Monitorler gibi closed duruma otomatik olarak geçmezler.Bizler altyapımızda kullanmış olduğumuz servis hesaplarımız bulunmakta. Bilindiği üzere Windows Server 2008 R2 ile birlikte servis accountlarını kullanmamış isek servislerde ya da uygulamalar içerisinde epey bir yönetimsel zorluk bizi bekliyor demektir. İşte bu noktada ortamımızda bulunan servis hesaplarının lock durumlarını System Center Orchestrator ürünü ile Unlock duruma getiriyor olacağız. Peki unlock yapabilmemiz için bizim lock olan hesaplarıda biliyor olmamız gerekmekte. İşte önceki makalelerde oluşturduğumuz ve System Center Operation Manager 2012 uygulamamız üzerinden bunları monitor ettiriyorduk ve oluşan bütün lock durumlarını monitor ediyorduk yani sadece servis hesapları gibi bir ayrım yapmamıştık. İşte bu noktada system center orchestrator ile bizler sadece servis accountlarını unlock duruma getiriyor olacağız.

İş bu noktada öncelikle System Center Orchestrator uygulamamız üzerinde bu işleme başlayacağız.

Orchestrator sunucusu üzerinde yeni bir folder ve yeni bir Runbook oluşturmakla işe başlıyoruz.Bunun için oluşturduğumuz klasör üzerinde sağ klik yaparak new runbook oluşturuyoruz.

SCOM 2012 Integration packi içerisinden Monitor Alert itemini kullanacağız.Bu adımda system center operation manager 2012 üzerinde oluşan alertleri monitor edeceğiz.Operation Manager üzerinde oluşacak alert bu item sayesinde Orchestrator uygulamamız tarafından monitor edilecek.

Monitor Alert itemi için SCOM 2012 sunucusu için connection bilgilerini tanımlayacağız. Connection parametresini http://www.mssystem.info/2012/12/system-center-orchestrator-ile-system-center-operation-manager-2012-entegrasyonu-2/ daha önceki makalemizde oluşturmuştuk.

Connection parametresini tanımladıktan sonra Filter alanında yine bir önceki makalemizde oluşturduğumuz Rule olan User Account Control alertini filtreliyor olacağız.Bu şu demek oluşan her alert değil bizim istediğimiz alerti monitor edeceğiz. User Account Control ile ilgilide bir alert oluşursa Orchestrator üzerinde oluşturduğumuz runbook çalışmaya başlayacak.

Monitor Alert itemini yapılandırdıktan sonra şimdi de istediğimiz alert monitor edildi ve User Account Controlle ilgili bir alert oluştuğunda yapılacak işlem ya da alınacak aksiyonu tanımlıyor olacağız. Bunun içinde System altında Run Program itemini ekliyor ve monitor Alert itemi ile birleştiriyoruz.

Bizim yapmak istediğimiz işlem lock olan fakat servis ya da uygulama içerisinde kullanılan hesabın lock olması durumunda bu hesabı yeniden unlock edilmesini istiyoruz. Bu işlem için birden fazla yol bulunmakta. Powershell ilede bu işlem yapılabilirdi fakat ben mevcut yapımda kullandığım microsoft toolu olan ve ücretsiz unlock.exe uygulamasını kullanarak bu işlemi gerçekleştireceğim.Yukarıda ki resimde de görüldüğü üzere Orchestrator sunucusu üzerinde ve C :\Tool\ dizininde bulunan Unlock.exe nin yolunu tanımlıyorum ve gerekli komut parametrelerini giriyorum.

Evet unlock.exe için gerekli parametreleri tanımladık dc01 isimli sunucu üzerinde unlock edilecek fakat hangi hesabın lock olduğunu biz bilmiyoruz fakat ilk adımda monitor alert üzerinde yine bir önceki makalemizde oluşturduğumuz custom field 1 alanından faydalanacağız.

Lock olan kullanıcı için bu işlem gerçekleştirilecek.Bunu da bize bildiren Monitor Alert itemi. Bunun için Command alanı içerisinde sağ klik Subscribe – Published Data seçimini yapıyorum.

Gelen ekranımızda Monitor Alert ;yani hemen Run Program itemi öncesinde çalışacak olan ,Monitor Alert itemi tarafından bizlere döndürülen ve Custom Field 1 alanında bulunan değer kullanılacak.

Evet böylelikle gerekli değerleri ve komut parametrelerini tamamlamış olduk.Bu aslında şu demek oluşacak her User Account Control alertini Monitor edeceğiz ve lock olan hesabı her seferinde biliyor olacağız.

Evet şimdiye kadar olan işlemlerimiz öncelikle lock olan ve servis yada uygulama tarafından kullanılan hesapların lock bilgisini aldık. Alınan bu kullanıcı hesabı ikinci adımda Run Program itemi sayesinde unlock duruma getirildi. Şimdi yapmamız gereken ise SCOM 2012 üzerinde oluşan Alert Rule çözümlenmiş olarak update etmemize . Çünkü Rule otomatik olarak alertini kapatmaz.Bunun içinde yine SCOM 2012 integration packi içerisinde Update Alert itemini alıyoruz ve Run Program sonrasında bağlıyoruz.

Yine ilk adımda olduğu gibi scom 2012 connection parametresini tanımlıyoruz. Bununla birlikte hangi alertin durumunu update edeceğimizi yine monitor alert itemi sayesinde öğreneceğiz.Bunun için Alert ID içerisinde sağ klik yapıyoruz ve Subscribe – Published Data seçimini gerçekleştiriyorum.

Açılan pencerede Aktivite olarak yine Monitor Alert içerisinden gelen değeri alacağız.Bunun içinde ID seçimini gerçekleştiriyorum.

Yukarıda görüldüğü üzere SCOM 2012 üzerinde ve Monitor Alert sayesinde oluşan alertin ID numarasını referans olarak alıyoruz ve select fields seçimini yapıyoruz.

Bizim yapmak istediğimiz iş oluşan ve open durumda olan Alertin durumunu Kapalı konuma getirmek yani closed olarak değiştirmek.çünkü biz zaten oluşan lock durumunu unlock durumuna getirdik.Çözümlenmiş olan probleminde açık olarak kalmasını istemeyiz. Bunun için gelen ekrandan Resolution State seçimini gerçekleştiriyorum.

Yukarıda görüldüğü üzere ResolutionState durumunu Closed değerini atıyorum. Bu artık scom 2012 üzerine gidecek ve ID numarasını bildiği alertin durumunu çözümlendi olarak değiştiriyor olacak.

Bu adımda ise bilgilendirme yapmak isteyebiliriz. E-Mail altında Send-E-Mail itemini Update Alert itemine bağlıyorum ve gerekli bilgilendirme e-mailini hazırlıyorum.içerisine istediğimiz bilgileri ekleyebiliriz ve bir kaç kişiyi bilgilendirebiliriz.

İşimiz henüz bitmedi başında aslında bu işi yapma amacımızın servis yada uygulamalarımızın kullandığı hesaplar için bu işleyişi sağlamaktı amacımız. Bunun içinde Monitor Alert iteminden Run program itemini bağlayan link üzerinde sağ klik yapıyor ve properties seçimini gerçekleştiriyorum.

Yukarıdaki resimdede görüldüğü üzere default olarak bu adım başarılı bir şekilde çalışırsa diğer adıma geç demekte biz buradaki adımı değiştireceğiz.Bunun içinde Custom Field alanından faydalanacağız.Monitor Alert seçimini yapıyorum ve açılan pencereden Custom Field alanını seçiyorum.

Görüldüğü gibi Custom Field1 alanı seçilmiş ve devam eden kısmında Temp olarak başlayan kelime gelirse bu adımın çalışacağını belirtiyorum. Neden Temp çünkü biz yapımızda servis hesaplarını belirli bir formatta isimlendiriyoruz. Temp ismi sadece örneklemek amacı ile tanımladığım bir değer.Sizlerde buraya gerekli formatlar için rule oluşturup bu adımın çalışmasını sağlayabilirsiniz.

Yazan: Yenal TIRPANCI (Eczacıbaşı Bilişim)