Citrix daha önce haberini yaptığımız “ haberde “ Citrix, Citrix Application Delivery Controller (ADC) ve Citrix Gateway ürünlerindeki zafiyetleri kapatmak için ilk güncellemeleri yayınladı.
Zafiyet kodu CVE-2019-19781 ile izlenebilen zafiyetler için ilk güncellemeler gelmeye başladı. Citrix ADC ve Citrix Gateway sürüm 11.1’i (ürün yazılımı güncellemesi Refresh Build 11.1.63.15 ile) ve 12’yi (ürün yazılımı güncellemesi Refresh Build 12.0.63.13) için yamaları yayınladı.
Yazılımın her alanında olduğu gibi SQL Server üzerinde de en sık yapılan işlemler string işlemleridir. Bu yazımızda SQL Server içerisinde kullanılan string fonksiyonlarını işliyor olacağız.
ASCII
Parametre olarak aldığı stringin ilk harfinin ASCII karşılığını verir.
SELECT ASCII('ABC') AS A, ASCII('B') AS B,
ASCII('a') AS a, ASCII('b') AS b,
ASCII(1) AS [1], ASCII(2) AS [2];
CHAR
ASCII fonksiyonunun tersine parametre olarak aldığı int değerinin karakter karşılığını vermektedir.
CHAR fonksiyonu kullanılarak yeni satır, tab, satır başı gibi kontrol karakterleri de insert dilebilir. Örneğin aşağıdaki örnekte kişinin adı ve soyadı araya enter karakteri eklenerek alt alta yazıyor.
Verilen iki parametreden ilk verilen değeri ikinci parametre içerisinde arar ve bulduğu ilk indeksi verir. Üçüncü parametre de isteğe bağlı ve verilmesi durumunda verilen indekten sonrası için arar. Aranan değer bulunmaz ise 0 değerini döner.
Concat fonksiyonu ile aynı şekilde çalışır ancak fark olarak stringleri birleştirirken araya ilk parametreyi koyar. Örneğin aşağıda yukarıdaki örneği “,” ile birleştiriyor.
İki parametre alır. İlk parametre bir string değer alır, ikinci parametre olarak bir int değer alır. Sonuç olarak int değeri kadar harfi stringin solundan döndürür.
Üç parametre alır. İkinci parametrede verilen string değeri birinci parametrede verilen string içerisinde arar ve üçüncü parametrede verilen değer ile değiştirir. Örneğin aşağıdaki örnekte “sai1orhan1” string değerinde geçen “1”leri “2” olarak değiştiriyor.
Select sorgusunda birinci parametre olarak kendisine verilen kolon değerini ikinci parametrede verilen karakter ile bölerek gösterir. Aşağıdaki örnekte Code alanını arasına “,” koyarak gösteriyor
SELECT STRING_AGG(Code, ',') from DocsTypes
--Sonuç
-- EN,FR,KA,LS,OR,PL,PR,PS,SE,ST,TL,TS
STRING_SPLIT
Birinci parametrede verilen metni ikinci parametrede verilen karaktere göre ayrıştırır. Geriye value adında kolon barındıran ve satırlarında karaktere göre ayrıştırma sonucunu tutan bir tablo döner.
SELECT * from STRING_SPLIT('Bu metin boşluk karakterine göre ayrıştırılacak', ' ')
SUBSTRING
String içerisinden belli bir bölümü döndürür. Üç parametre alır. İlk parametrede işlem yapılacak string değeri, ikinci parametrede alınacak alt parçanın başladığı index değeri ve son parametre olarak da alınacak alt parçanın uzunluğunu alır.
SELECT SUBSTRING('Bu metin boşluk karakterine göre ayrıştırılacak', 1, 4)
SELECT SUBSTRING('Bu metin boşluk karakterine göre ayrıştırılacak', 5, 10)
SELECT SUBSTRING('Bu metin boşluk karakterine göre ayrıştırılacak', 25, 1000)
--Sonuç
-- Bu m
-- etin boşlu
-- ine göre ayrıştırılacak
TRIM
LTRIM ve RTRIM ile aynı çalışır. Farkı stringin hem sağ hem solundan boşlukları siliyor olmasıdır.
UPPER
LOWER ile aynı çalışır. Verilen stringin tamamını büyük harfe çevirir.
Biz veri tabanı yöneticileri olarak veri tabanımız üzerinde en çok efor sarf ettiğimiz konulardan bir tanesi sürekli insert , update yada delete alan tablolarda oluşan boyut problemleridir. Oracle veri tabanı mimarisi gereği bir tabloda oluşan DML işlemlerinde eklenen verilerde tablo sürekli büyür fakat silinen veri olursa tabloyu küçülmez, bunun yerine oluşan fragmantasyondan dolayı ilgili tabloda siz ne kadar veri silsenizde blok kaldığı yerden yazmaya devam edeceği için tablo boyutunun her halukarda büyüyeceğidir.
Oracle tablolarda SQL sorgularındaki cost değeri hesaplamak yada mevcut tabloya full table scan bir sorgu geldiğinde hangi veri bloğuna kadar okuyacağını anlamak için High Water Mark isimli özelliği kullanır. Bir tablo ilk defa oluşturulduğunda HWM otomatik olarak bir başlangıç değeri atar ve her insert işleminde bu değer yükselir.Aşağıdaki örnekte görüldüğü gibi tablo insert almaya devam ettikçe pointer otomatik olarak yükselecek ve tabloda buna bağlı olarak değişimler oluşacaktır. Delete işleminde ise mantık olarak bu pointer noktasının düşmesi gerekirken Oracle mimarisi gereği düşmemektedir.
Bu pointer noktasının aynı yerde kalması öncelikli olarak sistem üzerinde gereksiz I/O yaptıracak ve sorgu performansını kötü bir şekilde etkileyerek aynı zamanda disk üzerinde gereksiz bir alan işgal edilmesini sağlayacaktır. Bir tabloda delete işlemi olmasına rağmen neden boyutun küçülmediği anladığımıza göre yazımıza devam edebiliriz.
Shrink edilecek tablolarda dağılmış olan blokların bir araya getirilmesi ve bu sayede tablo boyutlarının küçültülmesi için bilmemiz gereken bazı önemli durumlar mevcut.
Compress özelliği olan bir tablo shrink edilemez. Tablo önce nocompress duruma alınmalı shrink işlemi gerçekleştikten sonra tekrar compress özelliği aktif edilmelidir. Eğer compress özelliği olan bir tabloda shrink yaparsanız ORA-10635: Invalid segment or tablespace type hatası alırsınız.
Tabloda row movement özelliğinin enable edilmesi gerekir.
Bir tablo shrink edilirken Lock edilir, bundan dolayı tabloda ile ilişkili olan durumlarda wait oluşur.
Shrink için işlemlere başlayabilir.
SQL> alter table TBL_LOKUM enable row movement
Table altered
Tablomuzda row movement özelliğini aktif ettik. Şimdi işlerimizin kolaylaşması için basit bir sorgu ile fragmente olan tabloları bulalım ve listeleyelim.
SELECT DISTINCT owner ownr,
‘alter table ‘
|| owner
||’.’
|| segment_name
|| ‘ shrink SPACE CASCADE;’ seg_name, segment_type seg_type, tablespace_name tbs_name, file_id dbf_number FROM dba_extents WHERE (
(
block_id + 1
)
*
(
SELECT value
FROM v$parameter
WHERE upper (name) = ‘db_block_size’) + bytes
)
> (10000 * 1024 * 1024)
AND
segment_type = 'table'
AND
owner = 'ABUZER'
SELECT DISTINCT owner ownr,
‘alter TABLE ‘
|| owner
||’.’
|| segment_name
|| ‘ shrink SPACE CASCADE;’ seg_name, segment_type seg_type, tablespace_name tbs_name, file_id dbf_number FROM dba_extents WHERE (
(
block_id + 1
)
*
(
SELECT value
FROM v$parameter
WHERE upper (name) = ‘db_block_size’) + bytes
)
> (10000 * 1024 * 1024)
AND
segment_type = 'table'
AND
owner = 'ABUZER'
--Sorgu çıktısı --
OWNR SEG_NAME SEG_TYPE TBS_NAME DBF_NUMBER
Alter table ABUZER.TBL_LOKUM shrink space cascade;
Fragmente olan ve shrink edeceğimiz tablolar listelendi. Şimdi shrink işlemine başlayabiliriz.
SQL> alter table ABUZER.TBL_LOKUM shrink space cascade;
Table altered.
Eğer tablomuzda Compress açık halde ise bu adımları yapmanız gerekir.
SQL> alter table TBL_LOKUM enable row movement;
Table altered
SQL> alter table ABUZER.TBL_LOKUM nocompress;
Table altered.
SQL> alter table ABUZER.TBL_LOKUM shrink space cascade;
Table altered.
SQL> alter table ABUZER.TBL_LOKUM compress;
Table altered.
Bu yazımızda Oracle veri tabanında bulunan tabloların nasıl küçültüleceğini anlattık. Yeni yazılarımızda görüşmek dileğiyle.
Bu web seminerimizde SAP altyapılarının tasarımında dikkat edilmesi gereken hususlar ve iş sürekliliği çözüm önerilerini siz değeri katılımcılarımız ile paylaşacağız. Temel olarak inceleyeceğimiz konu başlıkları aşağıdaki gibidir;
– Kapasite planlaması
– İş sürekliliği ve felaket kurtarma seneryoları
– Şifre, sistem adı ve numaralarının etkin kullanımı
– Sap sistemlerinde yükdağılımının önemi, esnek büyüyebilme
Microsoft bugün akıllı, güvenilir bulut hizmetlerini yerel bir veri merkezi bölgesi aracılığıyla sunmak için şirketin İsrail’deki ilk bulut bölgesini kurmayı planladığını duyurdu. Bu yatırım, Microsoft küresel bulut altyapısını 21 ülkede 56 bulut bölgesine genişletirken, yeni İsrail bölgesinin 2021’de Microsoft Azure’dan başlayarak Office 365 ile birlikte kullanıma sunulması bekleniyor. Yeni İsrail bölgesi Microsoft’un güvenilir bulut ilkelerine bağlı kalacak ve halihazırda bir milyardan fazla müşteriye ve 20 milyon işletmeye hizmet veren dünyanın en büyük bulut altyapılarından birinin parçası olacak.
Azure, bilgi işlem, ağ iletişimi, veritabanları, analitik ve Nesnelerin İnterneti (IoT) hizmetleri sunan, sürekli genişleyen bir bulut hizmetleri kümesidir. Yeni bir İsrail veri merkezi bölgesine yapılan yatırım, müşterilerin en ileri teknolojileri kullanmasını sağlayacak. İsrail’de veri depolamak için veri ikamet gerekliliklerine uymasını sağlayacaktır. Microsoft’un bulut hizmetleri de Avrupa Birliği’nin Genel Veri Koruma Yönetmeliği (GDPR) ile uyumludur. Sektör lideri uluslararası güvenlik ve gizlilik standartları portföyü için onaylanmıştır. Azure, yerel İsrail ekosisteminin buluttaki en son gelişmeleri ve kuruluşların dijital dönüşümlerini yönlendirmelerine yardımcı olacak. Dünyanın önde gelen bulut tabanlı üretkenlik çözümü olan Office 365, yeni veri merkezi bölgesinden edinilebilecek. Müşterilerin modern çalışma ortamını etkinleştirmelerine ve güvenlik, uyumluluk ve şirket içi hizmetlerini koruyacak. Gerçek zamanlı işbirliği ve bulutla çalışan zeka ile çalışanlarını güçlendirmelerine yardımcı olacak.
Neden İsrail?
Microsoft Avrupa, Orta Doğu ve Afrika Başkanı Michel van der Bel; “EMEA genelindeki müşterilerle konuştuğumda, bulut gücünün rekabet gücü için çok önemli olduğu açıktır. Bölgeye önemli altyapı yatırımları yaptık ve bu duyuru ile İsrail’deki planlanan bölgemiz, Almanya, Norveç, Güney Afrika ve İsviçre de dahil olmak üzere son zamanlarda artan sayıda EMEA pazarına katılacak. Microsoft Azure ve Office 365’i İsrail’deki bir veri merkezi bölgesinden sunmak, altyapı kamu sektörü kurumlarının ve işletmelerinin sahip olması gereken teknoloji yoğunluğu için önemli bir yapı taşı olduğundan, yatırımın ve başlangıç ülkesine katılımımızın önemli bir parçasını oluşturuyor. ” Yeni veri merkezi bölgelerinin kurulması, önemli miktarda kaynak yatırımı gerektirmektedir ve bu duyuru Microsoft’un İsrail pazarına sürekli bağlılığını güçlendirmektedir. Şirket 1989 yılında İsrail’de yerel bir şube açarak yolculuğuna başladı. 1991 yılında Microsoft, ABD dışındaki ilk büyük teknoloji şirketlerinden biri olan İsrail Ar-Ge merkezini kurdu. Ayrıca, 2020 yeni bir Microsoft İsrail kampüsünün başlatılmasıyla yerel pazara bir başka önemli yatırım daha ekleyecek. Microsoft’un İsrail teknoloji ekosistemiyle derin bir ilişkisi var. Bir iş kolu, bir Ar-Ge Merkezi, bir Risk Sermayesi Fonu ve Startups için Microsoft programları yürütüyor.
Bugün Azure Backup Agent update yaparken alınan 1603 hatası ile ilgili çözüm adımını uygulayacağız.
Bildiğiniz üzere Azure Backup Agent aralıklarla güncelleniyor ancak güncellemeyi alamadığı durumlarda sizlere bir pop-up çıkartarak güncellemeyi manuel olarak yapmanızı istiyor.
Bu sıralar en çok karşılaştığım sorunlardan biri olan 1603 Error kodu ile ilgili aşağıdaki adımları yaparak sorunu giderebilirsiniz.
Güncelleme sırasında aldığımız hata aşağıdaki gibidir.
Bu hatayı aldıktan sonra agent güncelleme penceresini kapatalım.
Sonrasında “C:\Program Files\Microsoft Azure Recovery Services Agent\Temp” yoluna gidelim ve Temp dosyasının içerisindeki dosyaları silelim.
Bu dosyada geçici update ve backup schedule bilgilerini tutuyor ve sonrasına siliyor.
Microsoft, 5-31 Aralık tarihleri arasındaki Müşteri servis kayıtlarının bulunduğu veritabanındaki bir yanlış yapılandırılması sonucu veri sızıntısı olduğunu kabul etti.
Web browser üzerinden erişebilecek seviyeye gelen kayıtlar Bob Diachenko’ya göre, yaklaşık 250 milyon Müşteri Hizmetleri ve Destek kayıtlarından oluşuyor. Veri sızıntısının ise 2005 yılından bu yana oluşan kayıt geçmişi olduğu tahmin ediliyor.
Diachenko Raporlarının içerisinde şu kayıtların ifşa olduğu belirtiliyor.
Hukuk bürosu DLA Piper’a göre , AB’nin Genel Veri Koruma Yönetmeliği’nin yürürlüğe girmesinden bu yana , Avrupa veri koruma yetkilileri 160.900’den fazla veri ihlali raporu aldı.
GDPR’nin 25 Mayıs 2018’de tam olarak yürürlüğe girmesinden bu güne kadar, AB veri koruma yetkilileri gizlilik yönetmeliği kapsamında, hepsi veri ihlallerini içermeyen çok çeşitli ihlaller için 114 milyon € (126 milyon $) para cezası verdi.
DLA Piper, “Fransa, Almanya ve Avusturya sırasıyla 51 milyon € [57 milyon $], 24.5 milyon € [27 milyon $] ve 18 milyon € [20 milyon $] ‘dan biraz fazla olan GDPR cezalarının toplam değeri sıralamasında ilk sırada yer alıyor.” Diyerek şöyle devam etti: “Hollanda, Almanya ve Birleşik Krallık, her biri 40.647, 37.636 ve 22.181 bildirimle düzenleyicilere bildirilen veri ihlali sayısı tablosunda en üst sırada yer aldı.”
Bugüne kadar uygulanan 114 milyon € ‘luk toplam ceza tutarı, GDPR kapsamında verilebilecek potansiyel maksimum para cezalarına kıyasla nispeten düşüktür, bu da işin çok başında olduğumuzu gösteriyor” diyor Ross McKean.
“GDPR, Avrupa genelinde oldukça farklı bir şekilde yorumlanmaktadır. Aynı hukuki metin olmasına rağmen, ilke temelli ve yoruma açık olduğu için, uygulamalarda değişiklik gösterebiliyor ” Bazı denetçiler, bildirimleri diğer denetleyicilerden daha düşük bir seviyede yorumlayabiliyor. İngiltere’de, ayda 1.000’den fazla ihlal bildirim almasına rağmen diğer ülkelerde değişiklik gösterebiliyor. “
Gerçekten de bazı ülkeler nüfuslarına göre nispeten düşük sayıda ihlal bildirilmektedir. “ Kişi başına düşen bildirimlerin 62 milyondan fazla nüfusa sahip olan ve yalnızca 1.886 veri ihlali bildirimi bildiren bir ülke olan İtalya gibi ” diyor.
Bu şunu gösteriyor, GDPR hala emekleme aşamasında ve olgunlaşması zaman alacak gibi duruyor.
Merhaba, yazının başlığına bakıp SQL Server’ın standart Audit yapısını anlatacağımı düşünüyorsanız sizi bir sürpriz bekliyor. Doğru audit anlatacağım ama bildiğimiz anlamda standart audit değil. Daha iyisi.
SQL Server’da Data Audit anlamında kullanılan bazı teknolojiler var.
Bunlardan birincisi SQL Server Audit. Temel anlamda bir tablo üzerindeki hareketleri loglamamızı sağlayan ve uluslararası denetleme kuruşlarının da kabul ettiği bir standart. Örneğin tablodan şu şekilde bir kayıt sildiğimizi düşünelim.
DELETE FROM WEB_ITEMS WHERE CODE=’93794′
Sistemimizde SQL Server Audit çalıştırıyorsak şayet, bu işlemi şu şekilde loglayabiliriz.
Resimde görüldüğü gibi tabloda hangi sql cümlesinin, ne zaman ve kim tarafından çalıştırıldığı bilgisini gösterir. Buradaki sorun şudur. Sistem belli konuları kayıt altına almakta belli konuları alamamaktadır.
Aşağıdaki tabloda Audit ile kayıt altına alınabilen işlemler listelenmiştir.
Bir diğer loglama teknolojisi SQL Server Change Data Capture (CDC) işlemidir. Bu konu ile alakalı da inşallah ilerleyen zamanlarda bir makale yazacağım.
Change Data Capture için tablomuza baktığımızda ise durum aşağıdaki gibidir.
Gördüğümüz gibi bu iki teknoloji de bizim taleplerimizi tam olarak karşılamamaktadır.
Bu durumda yapılan silme/değiştirme işlemini kayıt altına almak için trigger kullanmak mantıklıdır.
Trigger’lar bildiğiniz üzere herhangi bir veri maniplüasyonu olduğu zaman (insert, update, delete) otomatik çalışacak yapılardır.
Burada yapılacak işlem şudur.
1-Logların tutulacağı bir Log db oluşturma.
2-Log kaydını tutmak istediğimiz tablo için aynı isimde ve aynı formatta bir tablo oluşturma.
3-Bu tabloda otomatik artan alan var ise log database inde oluşturacağımız tabloda bu alanı otomatik artan yapmama. Çünkü bir ID ye sahip bir kayıt birden fazla update işlemi göreceği için aynı ID li kayıt birden fazla loglanacaktır.
5-Kayıt altına almak istediğimiz tablo için bir delete/update trigger’ı oluşturma. Insert trigger neden oluşturmuyoruz? Derseniz, buna gerek yok derim. Çünkü insert edilen bilgi zaten asıl tabloda var. Biz delete ve update ler ile ilgileniyoruz.
6-Bir de içerisinde 200’den fazla kolon içeren tablolar var. Bu tablolarda pratik bir şekilde hangi kolonun değiştiği bilgisini hızlıca görebilmemiz gerekir.
7-Bir çok uygulama geri tarafta çalışırken kullandığı Object Oriented Programming yapıları sebebi ile gereksiz update ler yapabilmektedir. Yani aslında değişen hiçbir şey yokken SQL Server’a aynı değerler ile update gönderebilmektedir. Bu durumda trigger gereksiz yere çalışır ve gereksiz yere log üretir. Bunun da önüne geçecek şekilde trigger yazılmalıdır.
Görüldüğü üzere trigger yazmak zahmetli,riskli ve dikkatli yapılması gereken bir işlemdir. Sadece 1 tablo için burada 7 adım yazdık. Ayrıca trigger’lar transaction’ın bir parçası olduğu için dikkatli yazılmaz ise, trigger’da bir yerlerde bir hata olduğunda yapılan işlem otomatik olarak Rollback yapılır.
Biraz gözünüzü korkuttuktan sonra aşağıdaki tabloyu gösterip tekrar bir motivasyon vereyim.:)
Şimdi sırayla bu işlemleri bir tablo için yapalım. Sonrasında ise yüzlerce tablo işin bu işi otomatik yapacak scripti de paylaşacağım.
Önce CRM isimli bir veritabanı oluşturuyorum.
Bu veritabanının altına CUSTOMERS isimli bir tablo ekliyorum.
INSERT INTO CUSTOMER (CUSTOMERNAME,CITY,DISTRICT,BIRTHDATE,GENDER)
VALUES('ÖMER ÇOLAKOĞLU','İSTANBUL','FATİH','1980-01-01','E')
Artık elimizde bir veritabanımız, bir tablomuz ve bir de kaydımız var.
Şimdi log veritabanımızı oluşturalım.
Ve Customer tablosu için log tablosu oluşturalım.
USE CRM_LOG
CREATE TABLE [dbo].[CUSTOMER](
[ID] [int] ,
[CUSTOMERNAME] [varchar](100),
[CITY] [varchar](50),
[DISTRICT] [varchar](50),
[BIRTHDATE] [date],
[GENDER] [varchar](10),
[_LOG_DATE] [datetime] NULL, --LOG TARIHI
[_LOG_USERNAME] [varchar](500) NULL,--İŞLEMİ YAPAN KULLANICI
[_LOG_HOSTNAME] [varchar](500) NULL,--İŞLEM YAPILAN BİLGİSAYAR
[_LOG_ACTIONTYPE] [varchar](10) NULL,--İŞLEM TÜRÜ UPDATE/DELETE
[_LOG_PROGRAMNAME] [varchar](500) NULL,--İŞLEMİN YAPILDIĞI UYGULAMA
[_LOG_SQL] [varchar](max) NULL,--İŞLEM YAPILAN SQL CÜMLESİ
[_LOG_UPDATEDCOLUMNS] [varchar](max) NULL--DEĞİŞİM GÖREN KOLONLAR
)
Şimdi trigger ımızı yazıyoruz.
Trigger’ın içerisinde elimden geldiğince açıklamaları yorum satırında yazdım.
CREATE TRIGGER TRG_LOG_CUSTOMER ON CUSTOMER
AFTER UPDATE,DELETE
AS
BEGIN
/*
SQL SERVER DA TRIGGER İÇERİSİNDE DELETED VE INSERTED TABLOLARI OLUŞUR.
DELETE İŞLEMİNDE SİLİNEN KAYITLAR DELETED TABLOSUNDA TUTULUR, INSERTED TABLOSU BOŞTUR.
INSERT İŞLEMİNDE EKLENEN KAYITLAR INSERTED TABLOSUNDA TUTULUR, DELETED İŞLEMİ BOŞTUR
UPDATE İŞLEMİNDE SATIRIN YENİ BİLGİSİ INSERTED TABLOSUNDA, ESKİ BİLGİSİ INSERTED TABLOSUNDA TUTULUR.
BU BİLGİLERE GÖRE İŞLEMİN INSERT MÜ, UPDATE Mİ, YOKSA DELETE Mİ OLDUĞUNU ANLAYABİLİRİZ.
*/
SET NOCOUNT ON;
DECLARE @DELETECOUNT AS INT=0
DECLARE @INSERTCOUNT AS INT=0
DECLARE @UNIONCOUNT AS INT=0
DECLARE @LOG_SQL AS VARCHAR(MAX)
DECLARE @LOG_ACTIONTYPE AS VARCHAR(20)
SELECT @DELETECOUNT=COUNT(*) FROM DELETED
SELECT @INSERTCOUNT=COUNT(*) FROM INSERTED
IF @DELETECOUNT=0 AND @INSERTCOUNT>0
SET @LOG_ACTIONTYPE='I' --INSERT
IF @DELETECOUNT>0 AND @INSERTCOUNT=0
SET @LOG_ACTIONTYPE='D' --DELETE
IF @DELETECOUNT>0 AND @INSERTCOUNT>0
SET @LOG_ACTIONTYPE='U' --UPDATE
/******************************************************
KULLANICININ SON YAPTIĞI İŞLEMİ YAKALAMAK İÇİN DBCC INPUTBUFFER(@@SPID) KOMUTUNU KULLANIRIZ.
BU KOMUT BİR TABLO DÖNDÜRÜR. BURADA EVENTTYPE,PARAMETERS VE EVENTINFO ALANI GELİR.
EVENTINFO ALANI ÇALIŞTIRILAN SQL CÜMLESİDİR.
BURADA BU BİLGİYİ YAKALAMAK VE DEĞİŞKENE ATAMAK İÇİN TEMP TABLE KULLANIRIZ.
******************************************************/
CREATE TABLE #INPUTBUFFER (EVENTTYPE VARCHAR(100),PARAMETERS INT,EVENTINFO NVARCHAR(MAX))
INSERT INTO #INPUTBUFFER EXEC ('DBCC INPUTBUFFER(@@SPID)')
SELECT @LOG_SQL=EVENTINFO FROM #INPUTBUFFER
/******************************************************
DİĞER LOGLAMAK İSTEDİĞİMİZ BİLGİLER ZATEN FONKSİYON İLE YAKALANABİLİR.
"PROGRAME_NAME()" FONKSİYONU SQL SERVER'A HANGİ UYGULAMA İLE BAĞLANILDIĞINI GÖSTERİR.
CONNECTION STRING İÇERİSİNDE APPLICATION_NAME ALANINDA YAZAN ATTRIBUTE LERİ BURADAN YAKALARIZ.
BURADA WEB ÜZERİNDEN GELEN KULLANICILAR İÇİN KULLANICI IP'Sİ GİBİ BAŞKA BİLGİLER DE EKLENİP
GÖNDERİLİRSE BUNLAR DA KAYIT ALTINA ALINABİLİR.
******************************************************/
/******************************************************
SUSER_NAME() SQL'E BAĞLANAN KULLANICI ADI
HOST_NAME() BAĞLANAN MAKİNENİN ADI
GETDATE() ANLIK TARİH SAAT BİLGİSİ
******************************************************/
/****************************************************
TABLODA UPDATE İŞLEMİ VAR İSE INSERTED TABLOSUNDAKİ KAYITLAR İLE DELETED TABLOSUNDAKİ KAYITLARI
UNION İLE BİRLEŞTİRDİĞİMİZDE ELDE ETTİĞİMİZ KAYIT SAYISININ INSERTED TABLOSUNDAN BÜYÜK OLMASI GEREKİR
BUNU DA BİR DEĞİŞKENE ATACAĞIZ, UPDATE KONTROLÜNDE LAZIM OLACAK
******************************************************/
SELECT @UNIONCOUNT=COUNT(*) FROM
(SELECT * FROM INSERTED
UNION
SELECT * FROM DELETED) T
/******************************************************
GERİYE UPDATE EDİLEN KOLONLARI YAKALAMAK KALDI. BU DURUMDA BİR KOLONUN UPDATE EDİLİP EDİLMEDİĞİNİ ANLAMAK
İÇİN YENİ VE ESKİ DEĞERLERİNİN KARŞILAŞTIRILMASI GEREKİYOR.
BUNUN İÇİN DE KOLON KOLON KARŞILAŞTIRMAK GEREKİYOR.
******************************************************/
--UPDATE İŞLEMİ İÇİN LOG TABLOMUZA İNSERT ATIYORUZ.
--BURADA @UNIONCOUNT>@INSERTCOUNT İSE EN AZ BİR KOLON GÜNCELLENMİŞTİR.
--AKABİNDE DEĞİŞEN KOLONLARI BULMAK İÇİN AŞAĞIDAKİ UZUN SQL CÜMLEMİZİ YAZIYORUZ.
IF @LOG_ACTIONTYPE='U' AND @UNIONCOUNT>@INSERTCOUNT
BEGIN
INSERT INTO CRM_LOG.DBO.CUSTOMER (
ID,CUSTOMERNAME,CITY,DISTRICT,BIRTHDATE,GENDER, _LOG_DATE, _LOG_USERNAME, _LOG_HOSTNAME, _LOG_ACTIONTYPE, _LOG_PROGRAMNAME, _LOG_SQL,_LOG_UPDATEDCOLUMNS)
SELECT D.ID,D.CUSTOMERNAME,D.CITY,D.DISTRICT,D.BIRTHDATE,D.GENDER
,GETDATE() AS _LOG_DATE,SUSER_NAME() AS _LOG_USERNAME,HOST_NAME() _LOG_HOSTNAME,@LOG_ACTIONTYPE _LOG_ACTIONTYPE,PROGRAM_NAME() _LOG_PROGRAMNAME,@LOG_SQL _LOG_SQL,CASE WHEN (I.ID<>D.ID) THEN 'ID,' ELSE '' END+CASE WHEN (I.CUSTOMERNAME<>D.CUSTOMERNAME) THEN 'CUSTOMERNAME,' ELSE '' END+CASE WHEN (I.CITY<>D.CITY) THEN 'CITY,' ELSE '' END+CASE WHEN (I.DISTRICT<>D.DISTRICT) THEN 'DISTRICT,' ELSE '' END+CASE WHEN (I.BIRTHDATE<>D.BIRTHDATE) THEN 'BIRTHDATE,' ELSE '' END+CASE WHEN (I.GENDER<>D.GENDER) THEN 'GENDER,' ELSE '' END
FROM DELETED D
LEFT JOIN INSERTED I
ON I.ID=D.ID
END
--DELETE İŞLEMİ İÇİN İŞİMİZ DAHA KOLAY. DOĞRUDAN LOG ATIYORUZ.
IF @LOG_ACTIONTYPE='D'
BEGIN
INSERT INTO CRM_LOG.DBO.CUSTOMER (
ID,CUSTOMERNAME,CITY,DISTRICT,BIRTHDATE,GENDER, _LOG_DATE, _LOG_USERNAME, _LOG_HOSTNAME, _LOG_ACTIONTYPE, _LOG_PROGRAMNAME, _LOG_SQL,_LOG_UPDATEDCOLUMNS)
SELECT D.ID,D.CUSTOMERNAME,D.CITY,D.DISTRICT,D.BIRTHDATE,D.GENDER
,GETDATE() AS _LOG_DATE,SUSER_NAME() AS _LOG_USERNAME,HOST_NAME() _LOG_HOSTNAME,@LOG_ACTIONTYPE _LOG_ACTIONTYPE,PROGRAM_NAME() _LOG_PROGRAMNAME,@LOG_SQL _LOG_SQL,''
FROM DELETED D
END
END
Gelin şimdi tablomuzu bir update edelim bakalım ne oluyor?
Şimdi de birden fazla alanı update edelim.
Şimdi aynı değerler ile tekrar update edelim bakalım trigger çalışacak mı?
Görüldüğü gibi değişiklik olmadığı için log atmadı.
Şimdi içeriye bir kayıt daha ekleyip sonra kaydı silelim.
Son durum bu şekilde.
Şimdi Hakan kaydını silelim.
Görüldüğü gibi kayıt silindi ve log tablosuna silinen değerler atıldı.
Şimdi dilerseniz bir de SQL Injection örneği yapalım.
Örneğin basit bir öneri formu uygulaması ve SQL Injection açığı olmuş olsun.
Bunun için bir tablo oluşturalım.
CREATE TABLE [dbo].[ONERI](
[ID] [int] IDENTITY(1,1) NOT NULL,
[ISIM] [varchar](100) NULL,
[ONERI] [varchar](max) NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
Basit bir asp.net uygulaması ile bu tabloya öneri kaydı yapacağız. Bu arada SQL Injection saldırısı yapacağız ve customer tablosundan kayıt sileceğiz. ASP. Uygulamamızda connection string ile SQL
Server’a bağlanırken Application Name attribute’üne Client’ın ip adresini de ekleyeceğiz.
Öneri toplama formu bu şekilde. Buraya bir SQL Injection saldırısı yapalım.
Gönder tuşuna bastıktan sonra sistem öneri formuna bir satır atarken geri tarafta bizim Customer tablosunun içini uçuruyor.
Görüldüğü gibi trigger’ımız bizim istediğimiz her alanı yakalamış durumda.
Şimdi bu yapının iş gördüğüne kanaat getirdikten sonra gelelim bütün tablolar için bu işi otomatik olarak yapma işine.
Bunun için de iki tane procedure ümüz var. Birincisi Log tablosunu oluşturuyor, ikincisi ise asıl tablonun altına trigger’ı ekliyor.
Şimdi bu procedure’lerimize bakalım. Canlı database üzerinde bu procedure leri create edeceğiz.
İlk procedure ümüz tabloyu oluşturuyor.
CREATE PROC [dbo].[CREATE_LOG_TABLE]
@TABLENAME AS VARCHAR(1000) ='CUSTOMER'
AS
DECLARE @DBNAME AS VARCHAR(1000)=''
DECLARE @SQL AS NVARCHAR(MAX)=''
DECLARE @COLUMNS AS VARCHAR(MAX)=''
DECLARE @COLUMN_NAME AS VARCHAR(200)
DECLARE CRS CURSOR FOR SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=@TABLENAME
OPEN CRS
FETCH NEXT FROM CRS INTO @COLUMN_NAME
WHILE @@FETCH_STATUS=0
BEGIN
IF @COLUMN_NAME='LOGICALREF'
SET @COLUMN_NAME='CONVERT(INT,0) AS LOGICALREF'
SET @COLUMNS=@COLUMNS+@COLUMN_NAME+','
FETCH NEXT FROM CRS INTO @COLUMN_NAME
END
CLOSE CRS
DEALLOCATE CRS
--SET @COLUMNS=SUBSTRING(@COLUMNS,1,LEN(@COLUMNS)-1)
SET @COLUMNS=@COLUMNS+'CONVERT(DATETIME,NULL) AS _LOG_DATE,'
SET @COLUMNS=@COLUMNS+'CONVERT(VARCHAR(500),NULL) AS _LOG_USERNAME,'
SET @COLUMNS=@COLUMNS+'CONVERT(VARCHAR(500),NULL) AS _LOG_HOSTNAME,'
SET @COLUMNS=@COLUMNS+'CONVERT(VARCHAR(10),NULL) AS _LOG_ACTIONTYPE,'
SET @COLUMNS=@COLUMNS+'CONVERT(VARCHAR(500),NULL) AS _LOG_PROGRAMNAME,'
SET @COLUMNS=@COLUMNS+'CONVERT(VARCHAR(MAX),NULL) AS _LOG_SQL,'
SET @COLUMNS=@COLUMNS+'CONVERT(VARCHAR(MAX),NULL) AS _LOG_UPDATEDCOLUMNS'
SELECT @COLUMNS
SET @SQL='IF NOT EXISTS (SELECT * FROM '+DB_NAME()+'_LOG.DBO.SYSOBJECTS WHERE XTYPE=''U'' AND NAME='''+@TABLENAME+''') SELECT TOP 0 '+@COLUMNS+' INTO '+DB_NAME()+'_LOG.DBO.'+@TABLENAME+' FROM '+@DBNAME+'.DBO.'+@TABLENAME
SELECT @SQL
EXEC SP_EXECUTESQL @SQL
Şimdi mevcut log tablomuzu silip bu procedure ile otomatik yeniden oluşturacağım.
Tablomuz artık gitti görüldüğü gibi.
Şimdi yenisini oluşturalım.
Şimdi sırada trigger’ı oluşturmak var. Onun için de aşağıdaki procedure’ü kullanacağız.
USE [CRM]
GO
/****** Object: StoredProcedure [dbo].[CREATE_LOG_TRIGGER] Script Date: 23.1.2020 17:30:11 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROC [dbo].[CREATE_LOG_TRIGGER]
@TABLENAME AS VARCHAR(200)='CUSTOMER'
AS
DECLARE @SQL AS NVARCHAR(MAX)
SET @SQL='IF EXISTS (SELECT * FROM sys.triggers where NAME=''TRG_'+@TABLENAME+'_LOG'') DROP TRIGGER TRG_'+@TABLENAME+'_LOG
'
EXEC SP_EXECUTESQL @SQL
DECLARE @PRIMARYKEYCOLUMN AS VARCHAR(255)
SELECT
@PRIMARYKEYCOLUMN=COLUMN_NAME
FROM
INFORMATION_SCHEMA.TABLE_CONSTRAINTS tc
JOIN
INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE ccu
ON tc.CONSTRAINT_NAME = ccu.Constraint_name
WHERE
tc.TABLE_NAME = @TABLENAME AND
tc.CONSTRAINT_TYPE = 'PRIMARY KEY'
SET @SQL='CREATE TRIGGER TRG_'+@TABLENAME+'_LOG ON '+@TABLENAME
SET @SQL=@SQL+'
AFTER UPDATE,DELETE'
SET @SQL=@SQL+'
AS'
SET @SQL=@SQL+'
BEGIN'
SET @SQL=@SQL+'
DECLARE @LOG_SQL AS VARCHAR(MAX)
DECLARE @LOG_ACTIONTYPE AS VARCHAR(20)
SET NOCOUNT ON;
DECLARE @INSERTCOUNT AS INT=0
DECLARE @DELETECOUNT AS INT=0
DECLARE @UNIONCOUNT AS INT=0
SELECT @INSERTCOUNT=COUNT(*) FROM INSERTED
SELECT @DELETECOUNT=COUNT(*) FROM DELETED
SELECT @UNIONCOUNT=COUNT(*) FROM
(SELECT * FROM INSERTED
UNION
SELECT * FROM DELETED) T'
SET @SQL=@SQL+'
IF @INSERTCOUNT>0 AND @DELETECOUNT>0
SET @LOG_ACTIONTYPE=''U''
IF @INSERTCOUNT=0 AND @DELETECOUNT>0
SET @LOG_ACTIONTYPE=''D''
IF @INSERTCOUNT>0 AND @DELETECOUNT=0
SET @LOG_ACTIONTYPE=''I''
'
DECLARE @COLUMNS AS NVARCHAR(MAX)
DECLARE @COLUMNS2 AS NVARCHAR(MAX)
SELECT @COLUMNS=(
SELECT
'D.'+COLUMN_NAME+','
FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=@TABLENAME FOR XML PATH('')
)
SET @COLUMNS=REPLACE(@COLUMNS,'<','<')
SET @COLUMNS=REPLACE(@COLUMNS,'≫','>')
SET @COLUMNS=SUBSTRING(@COLUMNS,1,LEN(@COLUMNS)-1)
SELECT @COLUMNS2=(
SELECT
'CASE WHEN (I.'+COLUMN_NAME+'<>D.'+COLUMN_NAME+') THEN '''+COLUMN_NAME+','' ELSE '''' END'++'+'
FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=@TABLENAME
FOR XML PATH('')
)
SET @COLUMNS2=REPLACE(@COLUMNS2,'<','<')
SET @COLUMNS2=REPLACE(@COLUMNS2,'≫','>')
SET @COLUMNS2=SUBSTRING(@COLUMNS2,1,LEN(@COLUMNS2)-1)
SET @SQL=@SQL+ 'CREATE TABLE #INPUTBUFFER (EVENTTYPE VARCHAR(200),PARAMETERS VARCHAR(1000),EVENTINFO VARCHAR(MAX))
INSERT INTO #INPUTBUFFER EXEC(''DBCC INPUTBUFFER(@@SPID)'')
SELECT @LOG_SQL=EVENTINFO FROM #INPUTBUFFER
DROP TABLE #INPUTBUFFER
'
SET @SQL=@SQL+ '
IF @LOG_ACTIONTYPE=''U'' AND @UNIONCOUNT>@INSERTCOUNT
BEGIN
DECLARE @LASTREF AS BIGINT
'
SET @SQL=@SQL+ 'INSERT INTO '+DB_NAME()+'_LOG.DBO.'+@TABLENAME+' (
'
SET @SQL=@SQL+REPLACE(@COLUMNS,'D.','')+', _LOG_DATE, _LOG_USERNAME, _LOG_HOSTNAME, _LOG_ACTIONTYPE, _LOG_PROGRAMNAME, _LOG_SQL,_LOG_UPDATEDCOLUMNS)
'
SET @SQL=@SQL+ 'SELECT '+@COLUMNS
SET @SQL=@SQL+ '
,GETDATE() AS _LOG_DATE,SUSER_NAME() AS _LOG_USERNAME,HOST_NAME() _LOG_HOSTNAME,@LOG_ACTIONTYPE _LOG_ACTIONTYPE,PROGRAM_NAME() _LOG_PROGRAMNAME,@LOG_SQL _LOG_SQL,'+@COLUMNS2
SET @SQL=@SQL+ '
FROM DELETED D
LEFT JOIN INSERTED I
ON I.'+@PRIMARYKEYCOLUMN+'=D.'+@PRIMARYKEYCOLUMN+'
END
'
SET @SQL=@SQL+ '
IF @LOG_ACTIONTYPE=''D''
BEGIN
'
SET @SQL=@SQL+ 'INSERT INTO '+DB_NAME()+'_LOG.DBO.'+@TABLENAME+' (
'
SET @SQL=@SQL+REPLACE(@COLUMNS,'D.','')+', _LOG_DATE, _LOG_USERNAME, _LOG_HOSTNAME, _LOG_ACTIONTYPE, _LOG_PROGRAMNAME, _LOG_SQL,_LOG_UPDATEDCOLUMNS)
'
SET @SQL=@SQL+ 'SELECT '+@COLUMNS
SET @SQL=@SQL+ '
,GETDATE() AS _LOG_DATE,SUSER_NAME() AS _LOG_USERNAME,HOST_NAME() _LOG_HOSTNAME,@LOG_ACTIONTYPE _LOG_ACTIONTYPE,PROGRAM_NAME() _LOG_PROGRAMNAME,@LOG_SQL _LOG_SQL,'''''
SET @SQL=@SQL+ '
FROM DELETED D
END
'
--------------------INSERT----------------
SET @SQL=@SQL+ '
IF @LOG_ACTIONTYPE=''I''
BEGIN
'
SET @SQL=@SQL+ 'INSERT INTO '+DB_NAME()+'_LOG.DBO.'+@TABLENAME+' (
'
SET @SQL=@SQL+REPLACE(@COLUMNS,'D.','')+', _LOG_DATE, _LOG_USERNAME, _LOG_HOSTNAME, _LOG_ACTIONTYPE, _LOG_PROGRAMNAME, _LOG_SQL,_LOG_UPDATEDCOLUMNS)
'
SET @SQL=@SQL+ 'SELECT '+@COLUMNS
SET @SQL=@SQL+ '
,GETDATE() AS _LOG_DATE,SUSER_NAME() AS _LOG_USERNAME,HOST_NAME() _LOG_HOSTNAME,@LOG_ACTIONTYPE _LOG_ACTIONTYPE,PROGRAM_NAME() _LOG_PROGRAMNAME,@LOG_SQL _LOG_SQL,'''''
SET @SQL=@SQL+ '
FROM INSERTED D
END
'
SET @SQL=@SQL+'
END
'
SELECT @COLUMNS,@SQL ,@COLUMNS2
EXEC SP_EXECUTESQL @SQL
Trigger’ı oluşturmak için mevcut trigger’ı siliyoruz.
Şimdi procedure ile yeniden trigger’ı otomatik oluşturuyoruz.
Şimdi de tüm tablolar için bu işlemi nasıl yapacağız ona bakalım. Benim tavsiyem bu işi tüm tablolar için yapmak yerine kritik gördüğünüz tablolar için yapmanız. Zaten o yüzden procedure leri tablo bazında yaptım.
Önemli gördüğünüz tabloların sayısı da bir miktar olabileceğinden bu işi en kolay yapmanın yolu tablo isimlerini excel’e çekerek yapmak.
Bunun için şu sql kodunu kullanabilirsiniz. Tabi burada ilk önce loglanacak tabloları oluşturuyoruz.
SELECT
'EXEC CRM.DBO.CREATE_LOG_TABLE '''+NAME+'''' AS SQL_,
NAME AS TABLENAME
FROM SYSOBJECTS WHERE XTYPE='U'
Bu sorgudan dönen cevap bu şekildedir.
Dönen sonucu Excel’e alıp içinden istediklerimizi temizleyebiliriz.
Excel’den de management Studio’ya yapıştırabiliriz.
Aşağıdaki işlem ile log tabloları oluşturuldu.
Aynı işlemi şimdi trigger için yapıyoruz.
SELECT
'EXEC CRM.DBO.CREATE_LOG_TRIGGER '''+NAME+'''' AS SQL_,
NAME AS TABLENAME
FROM SYSOBJECTS WHERE XTYPE='U'
Peki sistemimizde iki tablo değil de çok daha fazla tablo olsaydı. Örneğin bir Logo veritabanı olsun.
350 Tablo için log tablolarını otomatik oluşturacağız.
Tablolar oluştu.
Şimdi de trigger’ları oluşturalım.
Aşağıdaki gibi trigger oluştu.
Şimdi bu tabloda bir kayıt update edelim.
Bu da loglanan kaydın bilgisi.
Şimdi de bir kayıt silelim.
Görüldüğü gibi otomatik olarak tüm işimizi gören bir yapı oluşturduk. Burada örnek olsun diye update, delete işlemlerini Management Studio üzerinden yaptım. Başka uygulamalardan da örneğin Logo Tiger’ın kendi içinden yapsak da aynı şekilde yakalayabiliriz.
Uzun bir makale oldu. Buraya kadar geldiyseniz sabırla okuduğunuz için teşekkür ederim.
2.000’den fazla WordPress sitesi ziyaretçisi, istenmeyen tarayıcı bildirimi abonelikleri, sahte anketler, reklamlar ve sahte Adobe Flash indirmeleri içeren sahte sitelere yönlendiren saldırıya uğradı.
Bu saldırı, Ocak 2020’nin üçüncü haftasında WordPress eklentilerindeki güvenlik açıklarından yararlanan saldırganları ifşa eden güvenlik firması Sucuri tarafından tespit edildi.
Sucuri araştırmacısı Luke Leak, kötüye kullanılan savunmasız eklentilerin bazılarının “PayPal ile CP İletişim Formu” ve “Basit Alanlar” eklentileri olduğunu söyledi, ancak muhtemelen diğer eklentilerin de hedeflendiğini belirtti.
Bu güvenlik açıklarından yararlanıldığında sistemin, saldırganların admarketlocation [.] Com ve gotosecond2 [.] Com adreslerinden komut dosyalarını içeren JavaScript’i doğrudan sitenin temasına yüklemesine izin verdiği gözlemlendi.
Sucuri, JavaScript’i eklemenin yanı sıra , saldırganların güvenliği ihlal edilen sitelere daha fazla malware yüklemek için kullanılan sahte eklenti dizinleri oluşturduğunu da belirtti.
Sucuri bu olay sonrası WordPress kullanıcılarına bir öneride bulundu. “Bir WordPress sitesi yönetiyorsanız ve güvenliğin ihlal edilmiş olabileceğinden endişeleniyorsanız sitenizi ücretsiz SiteCheck araçları ile tarayabilirsiniz. Bu araçlar ile kötü amaçlı içerikler hakkında bir rapor elde edebilir ve bu rapora göre web sitenizdeki güvenlik açıklarını kapatabilirsiniz.”
Bu yazımızda Outlook uygulaması üzerine kurulan 3. parti yazılımların sürekli devre dışı kalmasının kalıcı çözümünü anlatıyor olacağız.
Outlook üzerinde aşağıdaki resimdeki gibi hatalar alabilirsiniz:
Bu hatalar sonucunda eklentiniz devre dışı kalır ve Outlook uygulamasını her başlattığınızda tekrar tekrar aktif etmeniz gerekmektedir.
Bu durumunda kurtulmak için kayıt defteri(regedit.exe) üzerinden aşağıdaki değişiklikleri yaparak Outlook eklentinizi sürekli olarak aktif edebilirsiniz. Bu eklentileri geliştiriciler eklenti yazdıkları esnada aşağıdaki değerleri yazılım üzerinde öncelikli olarak Kayıt Defteri değerini 3. seviyeye çekmektedirler ancak herhangi bir kontrol edilmeyen hata durumunda Outlook bu eklentileri sürekli olarak aktif olmayan eklentiler listesine eklemektedir. Bu durumda ilgili değer Kayıt Defteri üzerinde 0 a çekilmektedir. Aşağıda yapacağımız işlemlerle bu 0 a dönme olayını manuel olarak 3 e çekere sorunu gidereceğiz.
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\Resiliency\DoNotDisableAddinList DWORD: <ProgID of the add-in> Value: Hex değerini 1 den A ya kadar yazınız. Bu değer eklentinin neden devre dışı kaldığınız belirtmenize yarar sağlamaktadır.
0x00000001 Boot load (LoadBehavior = 3) 0x00000002 Demand load (LoadBehavior = 9) 0x00000003 Crash 0x00000004 Handling FolderSwitch event 0x00000005 Handling BeforeFolderSwitch event 0x00000006 Item Open 0x00000007 Iteration Count 0x00000008 Shutdown 0x00000009 Crash, but not disabled because add-in is in the allow list 0x0000000A Crash, but not disabled because user selected no in disable dialog.
Yukarıda yazılan x.0 sizin kullandığınız Office sürümünü belirtmektedir. (16.0 = Office 2016, 15.0 = Office 2013).
Yukarıda yapılan işlemin açıklaması şu şekildedir:
Key de belirtilen kayıt dizinine gidiniz,
İlgili kayıt dizini içerisinde Eklenti adınızı bularak DWORD değerini Crashten kaynaklı olduğunu belirtmek için 3 e çekiniz.
Bir sonraki crashlerde eklenti devre dışı kalmayacaktır.
Cisco Firepower Management Center ürünündeki zafiyet için güncelleme yayınladı. Firepower Management Center ürün ağ cihazlarını merkezi olarak yönetmeye yarayan bir ürün.
Zafiyet, kimlik doğrulaması yapmadan uzak sisteme erişmesine ve yönetici ayrıcalıkları almasına izin verebiliyor.
Zafiyet CVE-2019-16028 kodu ile izlenebilirken Cisco zafiyet için güncelleme yayınladı. Güncelleme linki
Cisco mühendisi Omar Santos , Cisco müşterilerini zafiyetten etkilenip etkilenmediklerini kontrol etmek için bir kaç öneride bulundu
Cisco FMC Yazılımının harici bir LDAP sunucusu aracılığıyla web tabanlı yönetim arabirimi kullanıcılarının kimliğini doğrulamak üzere yapılandırılıp yapılandırılmadığını kontrol edin.
Cihazda bir LDAP sunucusu kullanarak harici kimlik doğrulamanın yapılandırılıp yapılandırılmadığını kontrol edin (Sistem> Kullanıcılar> Harici Kimlik Doğrulama)
Oracle veri tabanı her yeni sürümle birlikte bizlere hayatı daha da kolaylaştıracak bir takım özellikleri sunmakta. Bu yazımızda öncelikle veri tabanı tarafında daha sonra işletim sisteminde otonom veri tabanı ilkesi hareket eden Oracle’ın biz veri tabanı yöneticilerinin işlerini kolaylaştıracak DBMS_AUTO_INDEX özelliğini tanıtacağız.
Bildiğimiz üzere her veri tabanın da verilere daha hızlı ulaşmak yada performans işlemlerinde index kavramı fazlası ile karşımıza çıkar. Index işlemleri avantajlı olduğu kadar dezavantajlıda olabilir. Doğası gereği index’ler fiziksel disk üzerinde yer kapladığı için hoyratça kullanılmaları durumda gereksiz bir alan kaplamaya ek olarak bizlere fazladan bakım gibi yükler getirebilmektedir.
Peki Oracle Automatic Indexing (DBMS_AUTO_INDEX) özelliği nasıl çalışır ?
Öncelikle tablo ve sütünların kullanım durumuna göre aday index olarak tanımlanan ” Candidate Indexes” belirlenir.
Güncel istatistikleri olan tablolar index işlemleri için hazırlanır. İstatistik bilgileri eski olan tablolarda otomatik index olmaz.
Aday indexler için ( candidate indexes ) SYS_AI ön eki ile invisible indexes oluşturulur. Invisible index oluştuğu için ilk etapta sql deyimlerinde kullanılmaz.
Çift taraflı olarak SQL performansları test edilir. Eğer SQL sorguları invisible indexler ile iyileşirse visible indexes durumuna geçilir.Bu sayede otomatik olarak oluşan indexler sql sorgularında kullanılır hale gelir.
Invisible olarak oluşan indexler eğer sql sorgularında yeterli performansı sağlamazsa unusable index olarak işaretlenir ve sql sorgusu kara listeye alınır.
Unusable olan index daha sonra silinerek kara listeye alınan sql sorgusunun tekrar otomatik index de kullanımı engellenir.
Oracle Automatic Indexing (DBMS_AUTO_INDEX) özelliği nasıl aktif edilir ?
Otomatik index özelliği DBMS_AUTO_INDEX prosedürünün işlenmesi ile kullanılır ve AUTO_INDEX_MODE konfig edilmesinden sonra aktif edilebilir. AUTO_INDEX_MODE aşağıdaki değerleri alabilir.
IMPLEMENT : Otomatik index özelliğini aktif eder. Invisible olan indexler, visible index hale gelir. Optimizer tarafından kullanılabilir.
REPORT ONLY : Otomatik index açılır fakat aday indexler invisible olarak kalır.
Otomatik indexler varsayılan olarak tablonun bulunduğu tablespace üzerinde bulunur. Otomatik olarak oluşacak indexler için farklı bir tablespace eklemek belirlemek isterseniz.
CREATE TABLESPACE AUTO_INDEXES_TS DATAFILE SIZE 1024M AUTOEXTEND ON NEXT 200M;
EXEC DBMS_AUTO_INDEX.CONFIGURE('AUTO_INDEX_DEFAULT_TABLESPACE','AUTO_INDEXES_TS');
Oracle Otomatik index özelliği aktif edildiği zaman standart olarak bütün şemaları dahil eder. AUTO_INDEX_SCHEMA özelliğini kullanarak eklenecek yada çıkartılacak şemaları TRUE paremetresi ile belirleyebilirsiniz.
/* Auto İndex Script B.PARLAYAN */
SELECT con_id, parameter_name, parameter_value
FROM cdb_auto_index_config
ORDER BY 1, 2;
Script Çıktısı
0 AUTO_INDEX_COMPRESSION OFF
0 AUTO_INDEX_DEFAULT_TABLESPACE
0 AUTO_INDEX_MODE OFF
0 AUTO_INDEX_REPORT_RETENTION 31
0 AUTO_INDEX_RETENTION_FOR_AUTO 373
0 AUTO_INDEX_RETENTION_FOR_MANUAL
0 AUTO_INDEX_SCHEMA
0 AUTO_INDEX_SPACE_BUDGET 50
Otomatik index ile ilgili aktivitileri gözlemlemek isterseniz aşağıdaki sorgudan yararlanabilirsiniz.
SELECT DBMS_AUTO_INDEX.report_activity() FROM dual;
GENERAL INFORMATION
-------------------------------------------------------------------------------
Activity start : 23-JAN-2020 02:44:55
Activity end : 23-JAN-2020 02:44:55
Executions completed : 0
Executions interrupted : 0
Executions with fatal error : 0
-------------------------------------------------------------------------------
SUMMARY (AUTO INDEXES)
-------------------------------------------------------------------------------
Index candidates : 0
Indexes created : 0
Space used : 0 B
Indexes dropped : 0
SQL statements verified : 0
SQL statements improved : 0
SQL plan baselines created : 0
Overall improvement factor : 0x
-------------------------------------------------------------------------------
SUMMARY (MANUAL INDEXES)
-------------------------------------------------------------------------------
Unused indexes : 0
Space used : 0 B
Unusable indexes : 0
-------------------------------------------------------------------------------
ERRORS
---------------------------------------------------------------------------------------------
No errors found.
---------------------------------------------------------------------------------------------
Bir yazımızın daha sonuna geldik. Otomatik index kavramını hakkında daha detaylı bilgi isterseniz benimde yararlandığım aşağıdaki kaynakları inceleyebilirsiniz.
Norveç’te bulunan ve olası bir küresel felaket durumunda bitki nesillerini devam ettirmek için kurulan ve içinde her bitkinin tohumunu bulunduran ambarı duyanımız vardır belki. Şimdi Microsoft’ta aynı senaryo için gelecek nesillere açık kaynak olarak geliştirilen projelerin bir kopyasını 1000 yıl dayanacağı söylenen bir depoya kopyalıyor. Açıklamada şuan GitHub’ta bulunan aktif açık kaynak projeler kopyalanacak.
02.02.2020 tarihinde alınacak olan GitHub kopyası Kuzey Kutbunda bulunan bir dağın 250 metre altında bulunan ve uzun zamandır kullanılmayan bir kömür madeninde saklanacak.
Peki bu veriler nasıl saklanacak:
100KB boyutundan büyük bütün aktif projeler ve aktif olmamakla beraber önemli projeler de buraya kopyalanacak. Kopyalanan her bir proje ayrı bir TAR dosyası olarak oluşturulacak ve her bir projenin konumunu ve nasıl kurulacağını açıklayan okunabilir bir kılavuz da oluşturulacak.
Merhabalar, 9 yıldır yazılım sektöründen kazandığım tecrübeleri tekrar sektöre kazandırmam gerektirdiğine inanıyorum. Ülkemizde ki ekosisteme bir şeyler kazandırmak ilerlememiz için hepimizin görevi aslında. Bende ilk yazımı paylaşmaktan mutluluk duyuyorum, faydalı olması dileğiyle.
Teknik borç (technical debt) uygulamamız içerinde yer alan gözle görünebilen, bir işi yaparken kullanılan nesne, bileşen, bağımlılık ve bazı desenlerin gereğinden eksik yada fazla kullanılması sonucunda ortaya çıkan bakım maliyetlerinin dışa vurumudur aslında. Bu borç verimsiz çıktıya, motivasyon düşüklüğüne, yeni geliştirmelerin uygulanmasına, bir şeyleri iyileştirmeye ve en önemlisi önceki yazılımcının kulaklarının çınlamasına sebep olur. Bu yazıda sizlere teknik borcun belkide en önemli maddelerinden bir olan bağımlılıkların yönetilmesi konusunda bir şeyler anlatmaya çalışacağım.
Yazılım geliştirdikçe karmaşıklaşan nesnelerin, bileşenlerin ve modüllerin bir birilerine olan bağımlılığının (coupling) arttığı bir şeydir. Bir nesnenin bazı iş süreçlerini sürdürmesi için başka bir nesneye olan ihtiyacı bağımlılığı doğrurur. Yazılımda gevşek bağımlılık (losely coupled) sürdürülebilirlik açısından önemlidir. Aksi takdirde sıkı bağlı (thight coupled) yazılımda yeni özellik eklemek, iyileştirme ve bakım çalışmaları çok zahmetli olur ve bir süre sonra bu uygulamayı yeniden yazalım fikiri doğar. Sıkı bağlılığı yüksek uygulamalarda genelde teknik borç fazladır. Çünkü zamanında yapılmayan yeniden düzenleme (refactoring), katlanarak büyümüş ve artık değiştirilemez koda sahip olunmuştur.
1960 yılında coupling ve cohesion Larry Constantine tarafından Structured Design parçası olarak yazılım kalite metrikleri kapsamına alınmıştır. – Wikipedia
İş ihtiyaçlarına yazılım ile çözüm üretirken sürdürülebilirliği (maintainability) göz önünde bulundurmalıyız. Yani günümüzde yazılmış olan bir uygulamanın yıllar sonra bile yeni bir özellik eklerken, var olanları değiştirirken yada bir şeyleri iyileştirirken bile çalışabilirliğinden ödün vermemeli. Evet, bunu yapmak mümkün. Aşağıda belirtilen prensipleri gözeterek yazılan uygulamalarda çok rahat hareket edebilirsiniz. Ayrıca Java dünyasınca çok güzel belgelenmiş şu sayfayı incelemenizi öneririm. Ben bu yazıda Dependency Injection hakkında bilgi vermeye çalışacağım.
Bağımlılıkların tersine çevrilmesi; ihtiyacı olan nesneye ihtiyaç duyduğu hizmeti oluşturmasına izin vermek yerine hizmeti istemciye dışarıdan vermek modelin temel gereksinimidir. Don’t call us, we’ll call you yöntemi ile çalışır. IoC yapabilmek için Factory Pattern, Service Locator Pattern, Dependency Injection, Contextualized Lookup, Template Method Pattern, Strategy Pattern kullanılabilir.
Inversion of Control Faydaları;
Programın modülerliğini arttırmak ve genişletilebilir hale getirmek
Bir modülü tasarlandığı göreve odaklamak
Modülleri diğer sistemlerin yaptıklarını nasıl yaptıklarıyla ilgili varsayımlardan kurtarmak ve bunun yerine sözleşmelere güvenmek
Bir modülü değiştirirken yan etkileri önlemek
Test edilebilirliği arttırmak
Aşağıdaki örnekle en yaygın kullanılan ve bazı framework’ lerin varsayınlan olarak desteklediği Dependency Injection yöntemi aktarmaya çalışacağım.
Dependency Injection; bir nesnenin başka bir nesne tarafından davranışları bilinmeden ve davranışlarından etkilenmeden kullanılabilmesi tekniğidir. Bu örnekte Order sınıfının Complete metodunda müşteriye e-posta atabilmesini gerçekleştirdiği varsaydım.
Dependecy Injection için 3 yöntem;
Constructor Injection En çok kullanılan Dependency Injection yöntemidir.
Property Injection İhtiyaç duyulan nesnenin değer atanabilir bir property üzerinden kullanılabilmesidir. Dikkat; NullLogger dışarıdan hiçbir değer atanması durumnda çıkabilecek NullReference hatasının önüne geçilmek için yapılmıştır.
Method Injection Her metot çağrımında değişen bir bağımlılık varsa bu yöntem faydalı olabilir.
Sonuç olarak,
Yazılım tarihinden bu yana halen ilkel veri tiplerini kullanmamıza rağmen biz geliştiriciler onu karmaşıklaştırıyoruz. Bu karmaşa bağımlılıkları ortaya çıkartır, zamanla geliştirilmeye devam yazılımın bağımlılıklarını iyi yönetmek için bazı yaklaşımlar uygulamalıyız. Bu yazıda uygulama için bağımlılıklardan bahsetmeye çalıştım. Peki ya diğer bağımlılıklar neler ?
Merhaba, günümüzde zamanının su gibi akmasına ek olarak sistemle de çık sık versiyonlar alıp yenilenerek karşımıza çıkmakta. Çalıştığımız mimariler içerisinde güvenlik, ek özellikler, ürünün eski versiyonundaki sorunlar gibi bir çok temel nedenden dolayı yapımızdaki donanımsal veya yazılımsal yapıları ara ara yükseltmek zorunda kalıyoruz. Üzerinde karmaşık işlemler barındıran sistemlerde bu gibi yükseltme işlerinden bazen kaçınabiliyoruz, bazen de bu operasyonlar kritiklik içerdiği için kara kara düşünüyoruz. Bu girişten sonra makalemizin konusu olan Windows Server 2012 R2 işletim sistemini Windows Server 2019 işletim sistemine yükseltme işlemini ele alıyor olacağız.
Yerinde yükseltme işlemi bir çok kişi tarafından pek tercih edilen bir durum olmasa da bazı durumlarda bu bizim için operasyon azaltıcı ve işlerimizi kolaylaştırıcı bir özellik olarak bizleri cezbedebiliyor.
Microsoft firması bu gibi yükseltmeler için genelde bir yol haritası yayımlar. Windows Server sistemler için takip edilecek olan yol haritası aşağıdaki gibidir. Görüldüğü gibi Windows Server ailesinde geçişler R2 versiyonlar dahil 2 versiyon yukarı yerinde yükseltmeye izin veriyor.
Makalemizde test amaçlı olarak Windows Server 2019 versiyonuna geçiş yapıyor olacağız. Yerinde yükseltme metodu ile Windows Server 2019’a geçiş yapabilmek adına en az Windows Server 2012 R2 versiyonuna sahip olmamız gerekmekte. Bu versiyondan daha önceki versiyona sahip sistemlerimiz ver ise yükseltme işini yukarıdaki resimde gözüktüğü gibi kademeler halinde yapmak durumundayız.
Bu gibi işlemlerde bazı durumlarda dikkatli olmak zorundayız. Bunları genel olarak aşağıdaki gibi özetlemek mümkün.
32-bit mimariden 64-bit mimariye doğru in-place yükseltme desteklenmez. Yalnızca 64-bit mimariden 64-bit mimariye doğru in-place yükseltme desteklenir.
Bir dilden farklı bir dile doğru in-place yükseltme desteklenmez.
Server Core ‘dan Server with GUI ‘ye direkt yükseltme desteklenmez. Ancak yükseltme tamamlandıktan sonra Server Core ile Server with GUI arasında geçiş yapmak mümkün.
Kritik rollere sahip sunucularda yerinde yükseltme (Active Directory Sunucu) pek tercih edilmese dahi bu yükseltme işleminin desteklendiğini teknik olarak, yerinde yükseltmeye mani bir durumun olmadığını da bilmemiz gerekir.
Başka bir makalemizde Windows Server 2012 R2 Active Directory Domain yapımızı, Windows Server 2019’a yükselteceğiz ancak biz sistem yöneticilerinin pek tercih ettiği bir durum olmadığından bu işlemi yerinde yükseltme metodundan farklı bir metotla yapıyor olacağız.
Şimdi adımlarımıza başlayalım. Öncelikle sistemimize göz atacak olursak elimizde bir Windows Server 2012 R2 işletim sistemi kurulu sunucumuz var. Yükseltme işlemine geçmeden önce donanım ve yazılımlarımızın yükseltilecek olan sisteme tam uyumlu olup olmadığını mutlaka teyit ediniz.
Sistemimiz üzerinde bazı verilerimiz ve örnek olarak çalışan bazı rollerimiz mevcut.
Sunucumuzun üzerindeki İşletim Sistemi, Makine İsmi ve lisans durumu aşağıdaki gibi.
Yükseltme işlemi için gerekli olan kaynağımızı sisteme bağlayalım. Ben iso olarak indirip DVD olarak yapıma mount ettim.
Yükleme medyamın içinde yer alan Setup dosyamı çalıştırıyorum.
Kurulum öncesinde gerekli olan güncellemeler var ise bunları internet üzerinden alıp devreye alması için “Download updates, drivers and optional features (recommended)” seçeneğini seçip Next ile ilerliyorum.
Bu ekranda elimizdeki lisans ve geçiş yaptığımız üründen, geçiş yapılacak yükseltme ürünü ile aynı olan versiyonu seçip Next ile ilerliyorum.
Bu ekranımızda lisans sözleşmesini Accept butonuna tıklayarak kabul ediyorum.
Bu ekranımızda yükseltme yapılacak olan işletim sistemimizdeki tüm dosyaların korunması gerektiği seçimini Keep personal files and apps radio butonunu tıklayarak belirleyip Next ile sonraki adıma ilerliyorum.
Yapılan denetim sonrasında dosyalarımızın korunması noktasında bir sorun bulunamadı. Kurulum adımlarına geçiş için Install butonuna tıklıyorum.
Kurulum işlemi başladı. Bu işlemler sırasında sistem birkaç kez otomatik olarak yeniden başlayacak.
Kurulum adımları sorunsuzca tamamlandı. Server 2012 R2 yerine artık Windows Server 2019 karşımızda.
Parolamızı girerek login olalım.
Sistemimiz açıldı dosyalarımız olduğu gibi duruyor.
Windows Server işletim sistemimizin versiyonu değişmiş durumda.
Windows Server 2019 üzerinde makalemizin başında örnek olarak ele aldığımı rol IIS versiyonu güncel ve çalışır durumda.
Eski sisteme ait dosyalarımız gereksiz yer kaplamakta.
Disk temizliği yaparak bu fazla ve yer kaplayan dosyalardan kurtulalım.
Temizlenecek olan tüm sistem dosyalarımızı seçelim.
Sistemimiz tertemiz olarak kullanıma hazır durumda.
Windows Server 2012 R2 sistemini yerinde yükseltme ile Windows Server 2019 versiyonuna geçmiş bulunuyoruz. Yaralı olması dileğiyle bir sonraki makalemizde görüşmek üzere.
Microsoft Türkiye tarafından bu sene 7. düzenlenecek olan Microsoft Teknoloji Zirvesi, bu yıl 26 Mart 2020 tarihinde İstanbul Haliç Kongre Merkezi’nde düzenlenecek.
Microsoft Türkiye tarafından olan açıklama;
Tarih: 26 Mart 2020, 08:30 – 17:00
Adres: Haliç Kongre Merkezi Sütlüce Mah. Karaağaç Cad. Haliç Kongre Merkezi Idari Bina No:19 Kat:2, 34445 Beyoğlu / İstanbul / Türkiye
Teknoloji dünyasındaki son yenilikleri iş dünyasının yaratıcı ve vizyoner kurumlarıyla buluşturduğumuz Microsoft Teknoloji Zirvesi’nin 7’ncisini, bu yıl 26 Mart 2020 tarihinde İstanbul Haliç Kongre Merkezi’nde düzenleyeceğiz.
Bilişim dünyasının kalbine dokunan konuları alanında uzman konuşmacılarla birlikte aktaracağımız zirvemizde, bu yıl da teknoloji dünyasının karar verici yöneticilerine ve teknoloji alanında faaliyet gösteren kurumlara zengin bir program sunacağız.
Her sene 2000’i aşkın ziyaretçiyi ağırladığımız zirvede, perakende, finans ve üretim başta olmak üzere, sektörlerin dijital dönüşüm dinamikleri, yeni nesil teknolojiler ve sektörel uygulamalar Türkiye’den ve dünyadan örneklerle aktarılacak. Bu sene de yatırımları ve başarılarıyla Türkiye’nin önde gelen şirketlerine yön veren liderleri bir araya getirdiğimiz CEO paneli katılımcılarla buluşuyor olacak. Ana sahnede demolarla dijital dönüşümün ilham verici örnekleri sunulurken, paralel oturumlarda sektörel sunumların yanı sıra akıllı iş uygulamaları, siber güvenlik, modern iş yeri, altyapı ve uygulamalar, veri ve yapay zeka gibi teknolojiler uzmanların gözünden aktarılacak. Etkinlik alanındaki deneyim ve stand alanlarında ise, katılımcılara bu teknolojileri yerinde deneyimleme fırsatı sunulurken, iş ortaklarımız ve ziyaretçilerimizin daha güçlü iş bağlantıları geliştirmesine olanacak sağlanacak.
Türkiye’deki büyük ve orta ölçekli firmaların üst düzey yöneticilerinin, karar vericilerinin, bilişim sektörünün öncü kuruluşlarının, start-up’ların ve bilgi teknolojileri profesyonellerinin bir araya geleceği Microsoft Teknoloji Zirvesi‘nde sizi de aramızda görmek isteriz.
Ajandalarınıza 26 Mart 2020 Perşembe gününü şimdiden kaydedin!
Araştırmacılar FortiSIEM üzeridenki “ tunneluser “ kullanıcıları için tanımlanan ssh anahtarının tüm cihazlarda sisteme gömülü ( Hardcoded ) ve aynı olduğunu tespit etti.
Bu şu anlama geliyor, eğer saldırgan başka bir cihaz üzerinden bu ssh keyi elde ederse diğer cihazlara erişim yapabilir.
Zafiyeti gidermek için bir çok çözüm sunulmuş
FortiSIEM sürüm 5.2.7 ve üstüne yükseltin
Geçici çözüm (FortiSIEM sürüm 5.2.6 ve altı için):
1. SSH to the Supervisor node as the root user.
2. Remove tunneluser SSH configuration file to disable listening on port 19999:
Hackerlar, Trend Micro OfficeScan’deki sıfır gün açığından faydalanarak Mitsubishi Electric firmasının sunucularına kötü amaçlı dosyalar yerleştirdi.
Yakın kaynaklardan edinilen bilgilere göre, Çinli bir hacker grubu Mitsubishi Electric’e saldırabilmek için Trend Micro OfficeScan antivirüsündeki sıfır gün açığını kullandılar.
Trend Micro bu güvenlik açığını düzeltti, ancak sıfır gün açığının Mitsubishi Electric firması dışındaki başka saldırılarda kullanılıp kullanılmadığı hakkında bilgi vermedi.
MİTSUBİSHİ ELECTRİC HACKLENDİ
Mitsubishi Electric 20.01.2019 tarihinde web sitesinde yayınladığı basın açıklaması ile geçen yıl saldırıya uğradığını belirtti.
Şirket, 28 Haziran 2019’da sistemlerinde bir saldırı tespit edildiğini, bir ay süren bir araştırma sonucunda bilgisayar korsanlarının yaklaşık 200 MB’lık bir dosya çaldığını ve sistemlerine erişebildiğini keşfettiklerini, ayrıca çalınan belgelerin çalışanlar hakkında bilgiler içerdiğini söyledi.
Mitsubishi’ye göre çalınan belgeler şunları içeriyordu:
1987 kişi için istihdam başvurusu verileri
Merkez ofisinden 4566 kişi tarafından doldurulan 2012 yılı çalışan anketi sonuçları
2007-2019 yılları arasında emekli olan 1569 Mitsubishi Electric çalışanı hakkında bilgi
Şirkete ait gizli teknik malzemeler, satış malzemeleri ve diğer dosyaları içeren dosyalar
SIFIR GÜN
Japon medyasında yayınlanan raporlara göre, hackleme ilk olarak Çin’de Mitsubishi Electric firmasına bağlı olan bir kuruluşta meydana geldi ve daha sonra şirketin 14 departmanına yayıldı.
Saldırının, Mitsubishi Electric personelinin şirketin sunucularından birinde şüpheli bir dosya bulmasının ardından tespit edildiği iddia edildi. Ancak bunların hiçbiri Japon şirketi tarafından onaylanmadı. Mitsubishi Electric hacklenme olayı ile ilgili tek teknik detay, bilgisayar korsanlarının şirketin kullandığı antivirüs programlarından birindeki güvenlik açığından yararlandığı gerçeğiydi.
Saldırıyı bilen bir kaynağa göre, bilgisayar korsanlarının Trend Micro OfficeScan antivirüsündeki bir dizin geçişi ve isteğe bağlı dosya yükleme güvenlik açığı olan CVE-2019-18187’yi kullandığını söyledi.
Trend Micro, müşterilerini CVE-2019-18187 yamasındaki güvenlik açığının bilgisayar korsanları tarafından aktif bir şekilde kullanıldığını belirterek uyardı.
Japon medyası, saldırının Çin devlet destekli bir siber casusluk grubu olan Tick tarafından yapıldığını iddia etti. Tick grubunun, son birkaç yıl içinde tüm dünyadaki çok sayıda hedefi hackleme kampanyası yürüttüğü biliniyor. Grubun OfficeScan sıfır gün açığını diğer hedeflere karşı da kullanıp kullanmadığı belirsizliğini korurken. Trend Micro bu iddialar için yorum yapmayı reddediyor.
ULAKBİM, Tubitak ve Türkiye Cumhuriyeti Sanayi ve Teknoloji Bakanlığı gibi kurumların projede yer aldığı Milli Siber Güvenlik Çözümü Ahtapot’un SIEM Modülü 2.0 olarak güncellendi.
Ahtapot, Pardus işletim sistemi üzerinde açık kaynak kodlu siber güvenlik bileşenlerinin entegre edildiği, bir merkezden yönetilebilecek, derinlemesine siber güvenlik çözümü oluşturmayı hedefleyen bir projedir.
Bu proje sayesinde:
Kamu kurumları ve askeri kurumların siber güvenlik çözümlerine olan ihtiyaçları karşılanabilecektir.
Bilgi sistemlerinde birbirine entegre bileşenlerle derinlemesine ve 360 derece güvenlik çözümleri üretilebilecektir.
Güvenlik cihazlarında PARDUS milli işletim sistemi dağıtımı kullanılması sağlanacaktır.
Açık kaynaklı olmayan ticari ürünler yerine her fonksiyonunun denetlenebileceği açık kaynak çözümlerle daha “güvenilebilir” siber güvenlik önlemleri alınabilecektir.
Gerektiğinde milli insan gücü ile destek ve danışmanlık hizmetleri verilebilecektir.
Açık kaynak ve açık standartların yaygınlaştırılması kapsamında açık kaynak kodlu siber güvenlik çözümlerinin ticari ürünlerin yerine kullanılabileceği görülecektir.
Bir sistemde gösterge niteliğindeki gidişatın sürekli ve otomatik olarak gözlemlenmesi, olağan dışı aktivitelerin farkına varılması, analiz edilmesi ve önlemler üretilmesi mümkün olacaktır.
Ağdaki birçok sunucu ve güvenlik bileşeni tarafından üretilen milyonlarca satır günlük kayıtlarının anlamlandırılabilmesi ve ilişkilendirilmesi sağlanacaktır.
Merkezi kurulum ve yönetim yoluyla daha az insan gücüyle daha kolay ve sağlam güvenlik önlemleri alınabilecektir.
sebep olur. Bu yazıda sizlere teknik borcun belkide en önemli maddelerinden bir olan bağımlılıkların yönetilmesi konusunda bir şeyler anlatmaya çalışacağım.
