Baglantilar

Yazar: | Kategori: Genel
Yorum: 2

SQL Server 2000 hem uygulama geliştiriciler, hem de firmalar açısından çok önemli kazanımlar sağlayan, rdbms alanında dönüm noktası olarak kabul edebileceğimiz bir ürün olarak hayatımızda varoldu.. Açıksözlü olmak gerekirse 27 Ekim 2005 tarihinde MSDN Subscriber’lara RTM’i dağıtılmaya başlanan SQL Server 2005 ürününü incelediğimizde, SQL Server 2000’den 2005’e geçişin çok hızlı olacağını düşünmüyorum. Ancak ürünü detaylı olarak inceledikçe, SQL Server 2005’in uzun vadede Microsoft’un rdbms alanında liderliğini perçinleyecek bir ürün olacağı yönündeki düşünceme katılıyor olacağınızdan eminim. SQL Server 2005’in uygulama geliştirme alanında bize sunduğu artıları ele almadan önce altyapıda ne gibi değişikliklerin ve yeniliklerin olduğunu ele almakta fayda görüyorum. Dolayısıyla bu dokumanda SQL Server 2005 ile birlikte veritabanı yönetimi alanında gelen yenilikleri veritabanı mimarisi ve sotorage engine, veritabanı yönetim ve geliştirme araçları ve süreklilik ve veri güvenliği şeklinde üç ana başlık altında ele alıyor olacağız.

Veritabanı Mimarisi ve Storage Engine
Microsoft SQL Server 7 ile geliştirdiği mimariyi sürekli olarak geliştirdi. Hepimizin bildiği ve doğruluğunu kabul ettiği kurala göre mevcut donanımların maliyeti düşerken, gücü ise her 18 ayda öncekine göre iki katına çıkıyor. SQL Server 2005 ile birlikte Microsoft’un öncelikli hedeflerinden biri, veritabanı motorunun mevcut donanım altyapısından ve geliştirilen Windows Server 2003 (ve sonrasında gelecek olan) işletim sisteminden mümkün olan en fazla oranda faydalanmasını sağlamak. SQL Server 2005 ile birlikte gelen yeni özellikler ve güncellemelerin diğer hedefleri ise kurumlar açısından yönetimi daha kolay ve şirkete daha çok değer katan bir veritabanı motoru oluşturmak. Bu bölümde SQL Server 2005 ile birlikte SQL Server mimarisindeki yenilik ve gelişmeleri, kurumumuza ve iş süreçlerimize ne gibi artılar katabileceklerini de ele alarak inceliyor olacağız.

Donanım Desteği
Donanım alanındaki gelişmeler ve hızla daha düşük seviyelere inan donanım maliyetleri, firmaların daha güçlü bilgisayar sistemlerine çok daha düşük maliyetlerle sahip olabilmesini mümkün kıldı. Özellikle sunucu alanında 32-bit sistemlerde yaşadığımız gelişmeler ve hızla yaygınlaşmaya başlayan ve donanım alanında bir dönüm noktası olarak nitelendirebileceğimiz 64-bit sistemler, donanım alanındaki sorunlarımızın neredeyse tamamını ortadan kaldırdı. Bellek, veritabanı performansında her zaman için en kritik unsurlardan biri olmuştur. 54-Bit platformunda UNIX tabanlı sistemler, non-clustered TPC-C performans testlerinde uzun süre liderliği elinde bulundurdu. Ancak SQL Server 2005, ilk 64-Bitlik sürümünde liderliği devraldı. Performans testlerine baktığımızda, 64-Bit SQL Server 2005’in, 64-Bit Windows Server 2003 üzerinde, Intel Itanium platformunda gerçekten çok çok başarılı sonuçlar sergilediğini görüyoruz.

64-Bit Desteği
SQL Server 2005, Windows Server 2003 for 64-Bit Itanium systems üzerinde Intel Itanium ve Itanium2 mikroişlemcilerini desteklemektedir. Windows Server 2003 for 64-Bit Extended Systems üzerinde ise AMD’nin 64-Bit Opteron platformunu ve Intel’in “Xeon with Intel Extended Memory 64 technology (EMT64” sistemlerini de desteklemektedir. SQL Server 2005, tüm ana bileşenleri (SQL Server Engine, Analysis Services, SQL Agent ve Reporting Services) için hem 32, hem 64-Bit platformları desteklemektedir. Veritabanı altyapımızı 64-Bit platformuna taşımanın bize sağlayacağı en önemli kazanım her ne kadar daha yüksek işlem gücü olarak görünse de gerçekte en önemli kazanım: artan adreslenebilir bellek oranıdır. Şekil 1:1’de SQL Server 2005’in 32-Bitlik ve 64-Bitlik sürümleri tarafından adreslenebilen bellek miktarlarının karşılaştırmasını görebilirsiniz.


Şekil 1:1 :: 32-Bit ve 64-Bit SQL Server 2005’in Bellek Adresleme Oranları

32-Bit mimarisi en fazla 4GB bellek adresleyebilmektedir. Windows altında bu oran işletim sistemi ve uygulamalar arasında paylaştırılır. Diğer bir deyişle 2GB işletim sistemi için rezerve edilirken kalan 2GB uygulamaların kullanımına tahsis edilmektedir. 32-Bit Windows üzerinde yer alan Advanced Windowing Extensions (AWE) desteğini kullanarak, 32-Bit SQL Server’ın 32GB’a kadar bellek adresleyebilmesini sağlayabilmekteyiz. Her ne kadar bahsettiğimiz artış yeterli gibi görünebilse de, yönetilebilen bellek sayfalarındaki limit değişmiş olmuyor. 64-Bit Platformu adreslenebilen bellek miktarını 32TB’a çekerek bu konudaki sıkıntıları uzun bir süre için ortadan kaldırıyor. Şu anda neredeyse hiç bir yerde bu oranda bellek kullanılmıyor olsa da, SQL Server 2005’in test edildiği en yüksek bellek miktarı 512GB’dır. Windows Server 2003 için gelecek bir sonraki Service Pack ile birlikte desteklenen en yüksek bellek miktarının 1TB’a çıkartılması hedefleniyor.

NUMA (Non-Uniform Memory Architecture) Desteği
Windows Server 2003’ü üstün kılan yeni özelliklerden biride Non-Uniform Memory Architecture (NUMA) desteğidir. NUMA, IBM ve Unisys gibi bazı sistem üreticileri tarafından kullanılan ve çok işlemcili sistemlerde işlemci ve bellek kullanımını SMP (Symmetric Multiprocessing) mimarisine göre çok daha etkin bir şekilde yöneten bir mimaridir. Standart SMP sistemlerde işlemcilerin hızı ve sayısı arttıkça, işlemciler arasında belleğe erişme amaçlı yaşanan rekabet gereksiz yoğunluğa neden olur. Bu da doğal olarak bazı gecikmelere neden olur. Bunun sonucunda SMP sistemler işlemci sayısının artışıyor orantılı olarak esneklik gösteremezler. NUMA mimarisi SMP sistemlerde yaşanan bu sorunları, işlemcilerin RAM üzerindeki verilere, RAM ve BUS’ın sağlayabileceğinden çok daha hızlı olarak erişmesine olanak tanıyarak ortadan kaldırmak amacıyla tasarlanmıştır. NUMA mimarisi işlemci ve belleği çoklu işlemcilerden oluşan yerel gruplara ayırır. Bu gruplar birbirlerine, gruplar arası veri trafiğinin aktarıldığı harici bus’lar ile bağlıdır. Bu grup sıralama mimarisi, belleğe erişmek için yarışacak işlemcilerin sayısını limitleyerek SMP sistemlerde yaşanan işlemciler arası rekabetin önünü kesmektedir. NUMA mimarisinin artılarından en fazla oranda faydalanmak için hem işletim sistemi, hem de uygulamalar gruplar arası veri trafiğini en aza indirgeyecek ve grup içi erişimi arttıracak, hızlandıracak şekilde tasarlanmalıdır. Eğer işletim sistemi ve uygulama doğru olarak tasarlanırsa, NUMA mimarisi işlemci sayısının artışına orantılı olarak esneklik sağlayacaktır. Windows Server 2003 ve SQL Server 2005 mimari gelişmeleri bünyelerinde birleştirerek işlemci ve bellekten en yüksek oranda faydalanmamızı sağlayacak şekilde tasarlanmışlardır.

Hyper-Threading Desteği
SQL Server 2005 aynı zamanda Microsoft’un Windows Server 2003’e eklediği hyper-threading desteği ile hyper-threading’in sunduğu avantajlardan da faydalanabilmektedir. Hyper-Threading, Intel tarafından geliştirilen ve sistem üzerindeki her bir fiziksel işlemci için iki mantıksal işlemci oluşturan bir teknolojidir. Her bir mantıksal işlemci eşzamanlı olarak farklı thread’leri işleyebilme yeteneğine sahiptir. Hyper-Threading’in asıl hedefi multithreading uygulanmış uygulamalarda veya aynı makina üzerinde çalışan birden çok sayıda uygulamaya daha iyi kaynak ayrımının daha verimli yapılmasını sağlamaktır.

SQL Server 2005, Windows Server 2003’ün Hyper-Threading desteğinden iki şekilde faydalanmaktadır. İlk olarak, Windows 2000’in aksine, Windows Server 2003 fiziksel işlemcileri sadece lisanslama amacıyla saymaktadır. Boylece hyper-threading kullanan bir işlemci, iki yerine bir işlemci olarak sayılıyor. Windows Server 2003, hyper-threading kullanan sistemlere yönelik gelişmiş thread scheduling desteği sunmaktadır. Bu değişiklikler SQL Server gibi multithread uygulamalarda çok daha iyi performans sonuçları alabilmemizi sağlıyor.

SQL Server Engine
İlk bölümde SQL Server 2005 ile gelen donanım desteğine biraz daha geniş açıdan baktık. Bu bölümde ise SQL Server veritabanı motorundaki yeniliklere daha detaylı bakıyor olacağız.

.NET Framework Entegrasyonu
SQL Server 2005 ile birlikte gelen en önemli yeniliklerin başında Microsoft .NET Framework entegrasyonu ve sağladığı avantajlar geliyor diyebiliriz. .NET Framework entegrasyonu SQL Server 2005’in esnekliğini stored procedure, user-defined function, trigger, aggregate ve user-defined type’ların, visual basic, c# veya j# gibi bir .NET dili ile geliştirilmesini mümkün kılarak arttırmaktadır. Sonraki bölümlerde bu entegasyonun çok daha derin ve detaylı olduğunu göreceğiz.

Geliştirilmiş Çoklu Instance Desteği
SQL Server 2005 Enterprise Edition’da bulunan bir diğer yenilik ise aynı anda çalıştırılabilecek instance sayısının 50’ye kadar arttırılabiliyor olması. SQL Server 2000’de eşzamanlı instance desteği 16 ile sınırlıydı.

Yeni Veri Türleri
SQL Server 2005 pek çok yeni veri türünü desteklemektedir. .NET Framework entegrasyonu kullanıcı tanımlı türlerin geliştirilmesini sağlarken, varbinary(max) ve XML türünde yeni veri türlerini de desteklemektedir. Varbinary(max) beri türü SQL Server’da LOB’ların kullanımı için yeni bir metod sunmaktadır. Image ve Text veri türlerinin aksine varbinary(max) veri türü bir değişken olarak kullanılabilir ve daha kolay ve tutarlı işlem yapmak için daha küçük veri türleri gibi işlem yapılabilir.

Yeni XML veri türü varbinary(max) veri türüne dayanmaktadır ve XML dokumanlarını veritabanında saklamamıza imkan verir. XML veri türü, XML formatındaki verilerin hızlı ve kolayca saklanması ve kullanılmasını sağlamak amacıyla geliştirilmiş ve XML dokumanlarının schema ile doğrulanmasına olanak vermektedir. SQL Server 2005’te yer alan XML ve diğer veri türlerini ileriki bölümlerde ele alıyor olacağız.

Database Snapshot’ları ve Mirroring
Database Mirroring veritabanı seviyesinde sunulan ve sürekliliği arttırmak, sağlamak için SQL Server 2005 tarafından desteklenen tüm donanımlar ile uyumlu çalışan bir özelliktir. Database Mirroring için primary server ve mirrored server arasında bir paylaşıma gereksinim ve herhangi bir uzaklık limiti bulunmamaktadır. Database Mirroring, transaction log’larını primary ve mirrored sunucu arasında ileterek çalışmaktadır, bu yapısından dolayı Database Mirroring özelliğini gerçek-zamanlı bir log-shipping uygulaması olarak kabul edebiliriz. Database Mirroring tek bir veritabanı ile kullanılabileceği gibi, çok sayıda veritabanı ile de kullanılabilir.

Database Snapshot’ları veritabanının istenilen bir anına yönelik read-only fotoğrafını verirler. Database Snapshot’ları raporlama amaçlı bir veritabanının istenilen zamana ait bir kopyasını oluşturmak veya istenilen zamanda roll-back yapmak için belirli bir anda yedek almak amaçlı kullanılabilirler. Database Snapshot’ları, Database Mirroring ile bir arada kullanılarak mirrored server üzerindeki verilere dayanan bir reporting server oluşturmak için kullanabilmekteyiz. Mirrored sunucu üzerindeki veri, bu sunucunun her zaman recovery mode’da olmasından dolayı doğrudan erişşilebilir değildir ancak Mirrored database üzerinde bir Database Snapshot yaratarak bu verileri (read-only olarak) raporlama amacıyla kullanabiliriz.

Native HTTP Desteği
SQL Server 2005 ile birlikte gelen en önemli yeniliklerden biri de SQL Server Engine’e eklenen native HTTP desteğidir. SQL Server’ın gelen HTTP taleplerini işleyebilmesi, SQL Server’a stored procedure’leri ve SQL ifadelerini SOAP protokolünü kullanarak çalıştırabilmesi anlamına geliyor. Bu aynı zamanda SQL Server 2005’in, IIS olmadan web servis taleplerini karşılayabilmesi anlamına geliyor. SQL Server aynı zamanda endpointler için web servislerini WSDL olarak yayınlama yeteneğine sahiptir. SQL Server’ın HTTP özelliği hem Windows hem de SQL Server authentication’ı, SSL ile birlikte desteklemektedir. Bu özelliğin artılarını özellikle uygulama geliştiriciler için daha da arttırmak için stored procedure’ler sonuç kümelerini ADO.NET dataset’leri olarak döndürebilme imkanını sunmaktadır.

Sunucu Olayları ve DDL Trigger’ları
SQL Server 2005 ile birlikte gelen Sunucu Olay ve Trigger özellikleri, sistemdeki değişikliklere karşı nasıl karşılık verileceğini programatik olarak belirlememizi mümkün kılmaktadır. Bu iki özellikte benzer işler yapıyor gibi görünse de, sunucu tarafında işlemleri farklı şekillerde gerçekleştiriyorlar. Standart DML trigger’larında olduğu gibi, DDL trigger’ları da stored procedure’leri çalıştıran senkronize olaylardır.

Sunucu olayları ise asenkrondur. Sunucu olay modelinde sunucu SQL Server Broker Service’e bir olay gönderir. Olayla ilgilenen bu olaya sonradan bağımsız olarak erişebilir. Olay XML formatında kaydedilir. Bir olayı geri alma imkanı yoktur ancak kimsenin o olaya erişmemesi durumunda ignore edilir. Olay gerçekleştiğinde sizi olayın veya opsiyonel olarak bir kodun çalıştırıldığından haberdar edebilecek sistem olayı tetiklenir. Aşağıdaki kod bir event notification oluşturulurken kullanılacak söz dizimini örneklemektedir:

CREATE EVENT NOTIFICATION MyDDLEvents

ON SERVER FOR DDL_STATEMENTS TO SERVICE MyDDL_log

Bu kod yeni bir event oluşturup “MyDDLEvents” şeklinde isimlendiriyor daha sonra oluşturduğu olayı DDL statement ile ilişkilendiriyor. TO SERVICE ifadesi MYDLL_log adlı SQL Server Broker Servisinin bu olayın alıcısı olduğunu belirtiyor. SQL Server Broker Servisini ilerleyen bölümlerde detaylı olarak ele alıyor olacağız.

Veritabanı Veri Dosyasındaki Yenilikler
SQL Server 2005, ALTER DATABASE komutu aracılığıyla veritabanının log ve veri dosyasının yerlerini değiştirme imkanı sunuyor. SQL Server 2000 tempdb veritabanı için dosyalarını taşımaya izin veriyordu ancak diğer veritabanları için izin verilmiyordu. Tahmin edebileceğiniz üzere SQL Server 2005 dosyaların taşınmasını sadece offline bir işlem olarak mümkün kılıyor. Aşağıdaki örnek, veritabanı dosyalarının yerini değiştirmeyi sağlayan ALTER DATABASE komutunun sözdizimini göstermektedir:

ALTER DATABASE <database_name>

MODIFY FILE(name=<‘veri_dosyasinin_adi’>, filename=<‘yeni_veritabani_dosyasi_yolu’>)

Data Partitioning
SQL Server 2005’te yer alan bir diğer özellikse veri bölümlendirmedir. Veri bölümlendirme tablo veya index gibi tek bir veritabanı nesnesini birden çok bölüme ayırma imkanı vermektedir. Veri bölümlendirme özelliğinin öncelikli hedefi, çok büyük tablo ve indexleri yönetmeyi daha kolay hale getirmektir. Bölümlendirme, uygulamalar tarafından algılanamamaktadır. Uygulama çalışırken sadece tek bir tablo görmekte ve SQL Server tarafından yönetilen alt bölümlerden asla haberdar olmamaktadır. Bölümler, veritabanının sürekliliğini etkilemeden oluşturulabilir ve silinebilirler. Ek olarak partitioning verileri, bir uygulama tarafından kullanılırken dahi uygulamayı etkilemeden bölümlendirmenize olanak tanımaktadır. Şekil 1.1 bölümlendirmenin yapısını basitçe örneklemektedir.
Şekil 1.1 :: Veri Bölümlendirme

SQL Server 2005 tablolar, indexler ve indexlenmiş view’lar için veri bölümlendirmeyi desteklemektedir. Satır, veri bölümlendirmenin en temel elemanıdır. Bölümler, satırların alanlarında bulunan değerlere göre oluşturulabilir. Bu işlem, horizontal partitioning olarak adlandırılmaktadır. Örneğin bir tablo, her yıl için bir bölüm olacak şekilde tarihe göre bölümlendirilebilir.

Veri bölümlendirme çok büyük veritabanlarında (Very Large Databases – VLDBs) bazı önemli avantajlar sağlamaktadır. Veri bölümlendirme, verilerin yönetimini kolaylaştırmaktadır. Örneğin tarihe göre bölümlendirilmiş büyük bir tabloda önceki yılları hariç tutarak sadece bu yılın yedeğini almak isteyebilirsiniz. Bir diğer avantaj ise çok işlemcili sistemlerde daha yüksek performans için hangi bölümün, hangi işlemci tarafından işleneceğini belirtebilirsiniz.

Veri bölümlendirmeyi gerçekleştirmek için atmamız gereken iki basit adım vardır. İlk olarak hangi nesneyi, ne şekilde bölümlendireceğimizi belirlememiz gerekir. İkinci olarak her bir bölüm için fiziksel bir depolama lokasyonu belirtmemiz gerekir. Farklı bölümler, tek bir dosya grubuna atanabilir veya farklı dosya grupları tanımlanabilir.

Aşağıdaki örnek basit bir partition function oluşturmayı ve tabloyu bir Range Partition kullanarak bölümlendirmek üzere planlamayı örneklemektedir:

CREATE PARTITION FUNCTION MyPF

(int) AS RANGE LEFT FOR VALUES (50, 100)

GO

CREATE PARTITION SCHEME MyPS

AS PARTITION MyPF TO (FileGroup1)

GO

CREATE TABLE MyTable (col1 int, col2 varchar(50))

ON MyPS(col1)

GO

İlk satır MyPF adlı bir partition oluşturuyor. int, bölümlendirmenin int türünde tanımlanmış bir sütuna göre yapılacağını belirtiyor. RANGE keyword’u Range bölümlendirmenin uygulanacağını belirtiyor. LEFT keyword’u kesin olmayan değerlerin hangi partition’da saklanacağını belirtiyor. VALUES ifadesi bölümler için sınır değerleri belirtmek için kullanılıyor. Bu değerlerin sınır değerleri olduğunu ve bölümlendirilmediklerini unutmamakta fayda var. Bu komut 3 bölümün oluşması ile sonuçlanacaktır. İlk bölüm negatif değerleri ve 50’ye kadar olan pozitif değerleri, ikinci bölüm 51 ile 100 arasındaki değerleri, üçüncü bölüm ise 101’den büyük değerleri içerecektir.

İkinci satır, MyPS adlı bir bölüm şeması oluşturuyor. AS PARTITION ifadesi ise bu şema tarafından kullanılacak olan bölüm fonksiyonunu belirtmekte kullanılıyor. Bu örnek MyPF adlı bölüm fonksiyonunu kullanıyor. TO ifadesi bölümlerin kaydedileceği dosya grubunu veya gruplarını belirtmekte kullanılıyor. Bu örnek FileGroup1 adlı tek bir dosya grubunu kullanıyor.

Daha sonra, bölüm şemasının bölümlendirilecek tablo ile ilişkilendirilmeis gerekiyor. Bu örnek tablonun bölümlendirilmesine olanak tanıyan extended CREATE TABLE sözdizimini göstermektedir. CREATE TABL ifadesinin ilk bölümü aynı. Tablo adını (bu örnekte MyTable) ve sütunları belirtiyor. Örnek tablomuz col1 ve col2 adlı iki sütun içeriyor. Yeni gelen ON keywordu kullanılacak bölüm şemasını belirtmekte kullanılıyor. Bu örnekte az önce oluşturduğumuz MyPS şeması kullanılıyor. Bölümlendirme’de kullanılacak verileri içeren sütun parantez içinde yazılıyor. Bu örnekte kullandığımız sütun: col1. col1 sütununun veri türü int türünde. Seçilen sütunun veri türü, bölümlendirme fonksiyonunda belirtilen veri türü ile aynı olmalıdır.

Bölümlendirmede kullanılacak sütunların sahip olabileceği veri türleri konusunda bazı kısıtlamalar söz konusudur. Bu kısıtlamalar, index tanımlarken söz konusu kısıtlamalara oldukça benzemektedir. Text, ntext ve image veri türleri kullanılamıyor. Aynı şekilde timestamp sütunlarda partitioning key olarak belirtilemiyor. Sadece native T-SQL veri türleri partitioning key tanımlamalarında kullanılabilmektedir. Her bir tablo için 1000 bölüm üst sınırı ve tüm bölümlerin tek bir node üzerinde bulunması zorunluluğu mevcuttur.

Index Alanındaki Yenilikler
SQL Server 2005, indexlerde de pek çok yenilik getiriyor. İlk olarak, artık bir clustered index’in rebuild edilmesi, tüm non-clustered index’lerin rebuild edilmesini gerektirmiyor. SQL Server 2000’de, bir clustered index’i rebuild ettiğimiz zaman, tüm ilgili non-clustered index’ler de rebuild ediliyordu. SQL Server 2005, non-clustered index’lerin hasar görmesini engellediği için bu indexlerin rebuild edilmesi gerekmiyor.

İkinci olarak, yeni gelen “included columns” özelliği, non-key sütunların da bir index’e eklenmesine olanak tanıyor. Bu yeni özellik daha çok sorgunun index tarafından kapsanmasına ve böylece SQL Server Engine’in sorguyu tamamlamak için tabloya gitmesi ihtiyacını ortadan kaldırarak sorgu performansının ve hızının artmasına neden oluyor. Bu özelliğin en iyi yanlarından biride, index’e dahil edilen ve anahtarın bir bölümü olmayan sütunlar, hala 900 byte olan index üst sınırına dahil edilmiyor olması.

SQL Server 2005 ile gelen bir diğer yenilikse index’lerin disable edilebiliyor olması. Bir index’in disable edilmesi, bu index’in kullanılmasını ve SQL Server Engine tarafından işlemlerde dikkate alınmasını engelliyor. Bir index disable edildiğinde, SQL Server index için rezerve edilen alanı serbest bırakır ancak index’in metadata’sını saklar. Disable edilen index’in yeniden aktif duruma getirilebilmesi için, ALTER INDEX komutu ile rebuild edilmesi gerekir.

Online Index İşlemleri

SQL Server’ın önceki sürümleri, index’e rebuild sürecindeyken erişmeye imkan vermiyordu. Tablo’nun yeniden update edilebilir olması için rebuild sürecinin tamamlanmasını beklememiz gerekiyordu. SQL Server 2005’in online index işlemleri özelliği, uygulamaların index rebuild sürecindeyken, tablo üzerinde insert, update ve delete gibi işlemler yaparak index’e erişebilmelerine olanak tanıyor. Bu konuyu da ilerleyen bölümlerde detaylı olarak ele alıyor olacağız.

System Catalog ve Metadata Konularındaki Yenilikler
SQL Server 2000 ve daha önceki sürümlerde, sistem kataloğu ve metadata, master veritabanında her veritabanının bir parçası olarak saklanıyordu. SQL Server 2005 ile birlikte metadata sistem tarafından sys adında bir nesne olarak kaydedilen resource veritabanında saklanmaya başladı. SQL Server 2005 ile artık birlikte sistem veritabanlarına doğrudan erişemiyoruz. Bu değişiklik daha yüksek güvenlik ve daha hızlı sistem güncellemeleri sağlamak amacıyla getirildi. Catalog metadata’sının güvenliği row-level filtreler ile sağlanmıştır. SQL Server 2005’te Güvenlik alanındaki yenilik ve geliştirmeleri ilerleyen bölümlerde detaylı olarak ele alıyor olacağız.

Yeni metadata, Microsoft tarafından dokumante edilmemiş olan ve kullanılmaması konusunda uyarıda bulunduğu sistem tablolarını kullanmadığınız sürece tamamen backward compatible’dır. SQL Server 2005’te sistem metadatası, çeşitli catalog view’ları tarafından sunulmaktadır. Catalog view’ları, ANSI INFORMATION_SCHEMA view’ları, property fonksiyonları ve built-in fonksiyonlar ile birlikte, sistem veritabanı ve tablolarına doğrudan erişim ihtiyacını tamamen ortadan kaldırmaktadır. Toplamda 250nin üzerinde catalog view’ı bulunmaktadır ve bu view’lar her kullanıcı veritabanının sys şemasından görüntülenebilir. Yeni sistem view’larını Microsoft SQL Server Manager Studio’da, Object Browser’ı açarak, ilgili veritabanına -> views -> system views node’una giderek bulabilirsiniz. Aynı zamanda yeni bir sorgu ekranı açarak aşağıdaki kod ile de görüntüleyebilirsiniz.

select * from sys.system_views

Multiple Active Results Sets (MARS)

SQL Server’ın önceki sürümleri her bir bağlantıda sadece bir sonuç kümesini destekliyordu. SQL server 2005 tek bir bağlantıda birden çok sonuç kümesini destekliyor. Bu özellik, veritabanına tek bir bağlantı açarak bir sorgu çalıştırma, sonuç kümesi üzerinde çalışma, sonrasında bir başka sorgu daha çalıştırarak sonuç kümesi üzerinde çalışmaya devam edebilme imkanı sağlıyor. Bunun uygulamalar açısından sunduğu avantaj ise, uygulamanın oluşan sonuç kümelerinin tümüne erişebiliyor ve işlem yapabiliyor olmasıdır.

Bulk Data Loading
SQL Server 2005 bulk data loading özelliğinde, önemli bir performans artışı ile birlikte pek çok yenilik sunuyor. Bulk Data Loading özelliği artık XML tabanlı bir dosya kullanarak Bulk Copy programlarının format dosyasının sağladığı tüm özellikleri sunuyor. Ek olarak BCP’nin XML formatında işlem yapması, dosyaların daha kolay okunabilmesini ve anlaşılabilmesini sağlıyor. Önceki uygulamalar ile uyumluluğu sağlamak için eski BCP formatı halen desteklenmektedir.

SQL Server 2005’in bulk data loading prosesi artık hatalı satırların kaydını tutma özelliğini sağlamaktadır. Bu, yükleme işleminin hata ile karşılaşılması durumunda da devam edebilmesini sağlamaktadır. Hatalı olarak formatlanmış kayıtlar bir hata kayıt dosyasına kaydedilmektedir. Sınırlara uymayan satırlar ise hata durumuna bağlı olarak spesifik bir hata tablosuna yönlendirilirler.

Full-Text Search
SQL Server 2005’te Full-Text Search özelliği de geliştirilmiştir. SQL Server’ın Full-Text Search özelliği ile birlikte çalışabilmemiz için SQL Server 2005’e pek çok yeni DDL ifadesi eklenmiştir. Yeni DDL ifadelerine, CREATE FULLTEXT CATALOG ve CREATE FULLTEXT INDEX ifadelerini örnek olarak verebiliriz.

SQL Server 2005’te Full-Text Search özelliğinde gerçekleştirilen yenilikler, Full-Text Search kataloglarının ve indexlerin yedeklenebilmesi ve geri yüklenebilmesini, Full-text katalogların ilgili veritabanlarına attach ve detach edilebilmesini ve thesaurus kullanarak eş anlamlı kelimelerle yapılan aramaları bulma desteğini kapsamaktadır.

T-SQL Yenilikleri
SQL Server 2005 ile birlikte T-SQL’de de pek çok yenilik karşımıza çıkıyor. Bu yenilikler Common Table Expressions’ı, geliştirilmiş TOP ve WAITFOR ifadelerini, DML ifadeleri için OUTPUT ifadesini içermektedir. Bu yenilikleri ileriki aşamalarda SQL Server 2005’te T-SQL Alanındaki Yenilikler başlıklı bölümde detaylı olarak ele alıyor olacağız.

SQL Server 2005’te Güvenlik Alanındaki Yenilikler
Güvenlik Microsoft açısından her zaman en öncelikli konular arasında yer almıştır. Microsoft’un Trustworthy Computing vizyonunun hedefi, tüm Microsoft uygulamalarının daha güvenli ve güvenilir olmasını sağlamaktır. Trustworthy Computing vizyonunun bir parçası olarak SQL Server 2005, güvenlik alanında çok önemli yenilik ve iyileştirmelerle birlikte gelmektedir. SQL Server 2005’in geliştirme grubu ürünün tasarımdan, dağıtıma, çok daha sağlam ve güvenli olmasına odaklanarak çalıştı. SQL Server 2005’in güvenlik tasarımında Microsoft bir kaç temel güvenlik kuralına bağlı kaldı. İlk olarak kurulum sırasında tüm standart ayarları sistemi en güvenli kılacak şekilde belirledi. Kullanıcılar daha az güvenli olan diğer seçenekleri ihtiyaçları doğrultusunda kullanabiliyor olsalar da, standart ayarlar, sistemin en yüksek güvenlik seviyesini yakalamasına odaklanmıştır. İkinci olarak sistem tasarımı en az yetki gerektirecek şekilde yapıldı. Son olarak Microsoft potansiyel risk alanını sadece gereksinim duyulan bileşenleri kurarak minimuma indirgemeyi hedeflemiştir.

SQL Server 2005’te yer alan tüm güvenlik özellikleri, Microsoft’un 2002 yılının başlarında geliştirdiği güvenlik tekniklerinden etkilenmiştir. Bu bölümde ele alacağımız güvenlik özelliklerinden başlıcaları; kullanıcıların şemalardan ayrılmasını, yeni stored procedure çalıştırma konseptini, daha detaylı yetki kontrolünü, yeni password policy sistemini, row-level Security’de yer alan yenilikleri ve kataloglar için geliştirilmiş güvenlik tekniklerini içermektedir.

Kullanıcı – Şema Ayrımı
SQL Server 2005’te gelen en önemli güvenlik değişikliklerin başında, kullanıcı-şema ayrımı gelmektedir. Bir kullanıcı veya daha doğru söylemek gerekirse bir principal, veritabanı nesnelerinin kendisine karşı korunduğu bir varlıktır. Principal bir Windows kullanıcısı, SQL Server kullanıcısı, bir rol veya bir application role olabilir. SQL Server 2000 ile veritabanı nesneleri doğrudan kullanıcılara aitti ve bu kullanıcılar sys_users sistem tablosunda kayıtlı tutulmaktaydı. SQL Server 2005’te bu yapı tümüyle değiştirildi ve veritabanı nesnelerinin sahipliği şemalara verildi. Kullanıcılar ise artık doğrudan veritabanı nesnelerinin sahibi durumda değil, şemaların sahibi durumunda oluyorlar. SQL Server 2005 ile birlikte kullanıcılar ve diğer güvenlik principal’ları yeni sys.database_principals adlı view ile görüntülenebilmektedir. SQL Server 2005’in şema listesine ise sys.schemas view’ı ile erişilebilir.

Şemayı çeşitli nesneler için bir container olarak düşünebiliriz. Şema, SQL Server tarafından kullanılan dört bölümlü isimlendirme yapısının üçüncü bölümü tarafından tanımlanmaktadır. Aşağıdaki örnek SQL Server 2005’in isimlendirme söz dizimini örneklemektedir.

sunucu_adi.veritabani_adi.schema_adi.nesne_adi

SQL Server’ın önceki tüm sürümlerinde schema ismi ve owner’ın ismi genellikle aynı olurdu. SQL Server 2005 ile birlikte owner, schema’dan ayrılmış durumdadır. SQL Server 2000 ve önceki sürümler nesne isimlerini çözümlerken SQL Server ilk olarak veritabani_adi.kullanici_adi.nesne_adi’na bakıyor ve çözümleme başarısız oluyordu, daha sonra ise veritabani_adi.nesne.adi’na bakıyordu.

SQL Server 2005’te kullanıcı ve şemanın ayrılmasının temel nedeni, bir kullanıcıya ait çok sayıda nesnenin ownership’liğini değiştirme ihtiyacıydı. Ek olarak, bir veritabanı nesnesinin isminin değişmesi aynı zamanda bir isim değişikliğine neden oluyordu. Örneğin MyDB veritabanında yer alan Tablo1’in ownerı KullanıcıA’dan KullanıcıB olarak değiştirildiğinde tablonun ismi MyDB.KullanıcıA.Tablo1’den MyDB.KullanıcıB.Tablo1’e dönüşmektedir. Bu problemi önlemek için çoğu kurum tüm veritabanı nesnelerinin dbo tarafından sahiplenilmesi şeklinde bir standart uygulama kullanmaya başladı.

SQL Server 2005’in veritabanı ownership zincirini şekil 1.2’de görebilirsiniz.

Şekil 1.2 :: SQL Server 2005, Veritabanı Ownership Zinciri

SQL Server 2005 ile birlikte veritabanı nesneleri şemalar içinde bulundurulmaya ve şemalar kullanıcılar tarafından own edilmeye başladı. Bu yeni soyutlama modeli veritabanı nesnelerinin sahibinin belirlenmesi ve değiştirilmesini kolaylaştırarak daha kolay yönetilebilir bir yapı oluşmasını sağladı. SQL Server 2005’te veritabanında herhangi bir nesnenin sahibi durumundaki bir kullanıcının silinmesi sadece DBA’in ilgili tüm nesnenin/nesnelerin ownerını değiştirmesi değil, sadece bu nesneleri içeren şemanın sahibinin değiştirilmesi anlamına geliyor. Bu DBA’in yapması gereken işlem ve müdahale edilmesi gereken nesne sayısını azaltarak, ilgili şemanın güncellenmesinden sonra ilgili kullanıcı accountunun drop edilerek işlerin çok daha hızlı tamamlanabilmesini sağlıyor. Ek olarak nesnenin / nesnelerin ismi değişmemiş oluyor.

Tabi bu değişikliklerle birlikte SQL Server’ın veritabanı nesnelerinin isimlerini çözümlemede kullandığı yöntem de değişiyor. Artık her kullanıcı için kullanıcı il ilişkilendirilmiş varsayılan bir şema mevcuttur ve SQL Server 2005 ilk olarak kullanıcının varsayılan şemasına bakar. Eğer başarısız olursa SQL Server nesneye dbo’nun şema ismine bakarak erişmeye çalışır. Örneğin KullanıcıA varsayılan şema olarak SchemaA ile ilişkilendirilmişse ve bu kullanıcı Tablo1 üzerinde bir sorgu çalıştırırsa, SQL Server ilk olarak SchemaA.Tablo1’i kullanarak isim çözümleme yapmaya çalışacak başarısız olursa dbo.Tablo1’e bakacaktır.

SQL Server 2000 veritabanlarının birden çok kullanıcı ve rol içerebildiği gibi SQL Server 2005 veritabanları da birden çok şema içerebilir. Her şema kendisine özgü bir kullanıcı veya rol olan principal’a sahiptir. İsim çözümleme işlemleri için her kullanıcı varsayılan bir şemaya sahiptir, veritabanı nesneleri ise şema içinde yer alır. Şema içinde yeni veritabanı nesneleri oluşturmak için ilgili nesne için CREATE, ilgili şema üzerinde ise ALTER veya CONTROL yetkileri olması gerekir. Ownership zinciri hala şemalara değil gerçek ownera dayanmaktadır.

SQL Server 2005 kullanıcı ve şema ayrımını desteklemek için USER, ROL ve SCHEMA nesneleri için CREATE, DROP, ALTER ifadelerinde pek çok DDL değişikliği ile gelmektedir.

Aşağıdaki kod, bir veritaanı şemasının nasıl oluşturulduğunu ve assign edildiğini örneklemektedir.

/* Yeni bir login oluştur */

CREATE LOGIN UserA WITH PASSWORD = ‘ABC123#$’

GO

/* Oluşturulan login için bir kullanıcı oluştur. Şema varolmak zorunda değildir */

CREATE USER UserA FOR LOGIN UserA

WITH DEFAULT_SCHEMA = MySchema

GO

/* Şemayı oluştur ve ownerı ile ilişkilendir */

CREATE SCHEMA MySchema AUTHORIZATION UserA

GO

/* Yeni şemanın içinde bir tablo oluştur */

CREATE TABLE MySchema.Table1 (col1 char (20))

GO

Örneğin ilk satırı UserA adlı yeni bir login oluşturuyor ve bir parola belirliyor. İkinci satır oluşturulan login için yeni bir kullanıcı oluşturuyor ve varsayılan şemayı belirtiyor. Bu aşamada belirtilen şemanın varolması gerekmemektedir. Yeni kullanıcı oluştururken varsayılan şemayı belirtmezseniz dbo ile aynı varsayılan şema kullanılacaktır. Sonraki adımda CREATE SCHEMA ifadesi ile MySchema adlı şema oluşturuluyor. AUTHORIZATION ifadesi şemanın ownerının UserA olduğunu belirtiyor ve şema içinde Table1 adlı bir tablo oluşturuluyor.

Stored Procedure Execution Context
Microsoft Stored Procedure Execution Context adlı bir özelliği deklare etmiş olsa da, bu özellik stored procedure’ler dışındaki modüller için de (fonksiyonlar veya assemblyler) geçerlidir. Bir modül için execution context belirtmek modülün içeridği tüm ifadelerin belirtilen execution context’e bağlı olarak yetki denetiminden geçirilmesine neden olacaktır. Diğer bir deyişle, bir modül için execution context’in belirtilmesi, modülün kapsadığı tüm ifadelerin, modülü çalıştıran kullanıcı yerine belirtilen kullanıcının ownershipliğinde çalıştırılması anlamına geliyor (İki kelime ile özetlemek gerekirse: identity impersonation diyebiliriz). Şekil 1.3 SQL Server 2005’in ownership mimarisini göstermektedir.

Şekil 1.4 :: SQL Server 2005 Ownership Mimarisi

UserA’nın dbo.Proc1’i çalıştırabilmesi için UserA’nın bu nesne üzerinde execute yetkisinin olması gerekiyor. Ancak dbo.Proc1, dbo.Table1’e eriştiğinde herhangi bir yetki denetimi yapılmıyor, çünkü dbo her iki nesneninde ownerı durumunda. Sonraki senaryoda, UsrA’nın UserB.Proc2’yi çalıştırabilmesi için, bu nesne üzerinde yetkiye gereksinimi var. Sonrasında UserB.Proc2, UserC.Table2 nesnesine erişmek istediğinde, UserA için SELECT yetkisi denetlenmek durumunda. Bu senaryoda, UserB.Proc2 ve UserC.Table2 farklı ownerlara sahip ve ownership zinciri kırılıyor.

SQL Server 2005 bu senaryoyu şekil 1.4’te görüldüğü üzere oldukça kolaylaştırıyor. Bu senaryoda UserA, UserB.Proc2’yi çalıştırmak istiyor ve SQL Serer UserA’nın UserB.Proc1 için Execute yetkisinin olup olmadığını denetliyor. Eğer UserB.Proc1 nesnesi, UserZ’nin contextinde çalıştırılacak şekilde oluşturulursa, UserB.Proc1 stored procedure’u UserC.Table1 nesnesine erişmeye çalıştığında SQL Server sadece işlemi gerçekleştiriyor olarak kabul edilecek kullanıcının, yani bu örnek için UserZ’nin yetkilerini denetleyecektir. İşlemi başlatan kullanıcı olan UserA için SELECT yetkisi aranmayacaktır.

Şekil 1.4 :: SQL Server 2005 execution context

Aşağıdaki kod MyProc1 adlı bir stored procedure’ın execution context’ini nasıl değiştirebileceğimizi örneklemektedir.

ALTER PROC MySchema.Proc1 WITH EXECUTE AS USER UserB

Bu ifade yeni WITH EXECUTE ifadesini kullanmaktadır. Burada MySchema içinde yer alan Proc1 adlı stored procedure UserB’nin context’inde çalıştırılmak üzere güncelleniyor. Bu işlemde bir kullanıcı adı belirtmemiz gerekiyor, bir rol ismi kullanamıyoruz. Execution Context’te yapılan değişiklikler sys.sql_modules view’ı aracılığıyla görüntülenebilmektedir.

Daha Detaylı Yetki Yönetimi
SQL Server 2005 önceki sürümlere göre çok daha detaylı yetkilendirme yapmamıza imkan veriyor. SQL Server 2005 ile birlikte pek çok farklı seviyede, farklı yetkilendirmeler yapılabiliyor. Yetkilendirmelerin uygulanabileceği seviyeler: sunucu, veritabanı, şema, nesne ve principal şeklindedir. SQL Server 2005’in gelişmiş yetkilendirme sisteminin arkasındaki fikir, DBA’in kime hangi yetkilerin verildiğini tam olarak kontrol edebilmesini ve mümkün olan en az yetki ile çalışmasını sağlamaktır. Yeni sistem, SQL Server’ın mevcut rollerini ortadan kaldırmıyor. SQL Server 2000’de yer alan tüm roller sorunsuz olarak yeni yetkilendirme sistemi ile bir arada çalışmayı sürdürüyor.

GRANT, DENY ve REVOKE gibi temel yetkilendirme ifadeleri geçerliliklerini halen korumakta. SQL Server 2005’te farklılık gösteren bir nokta, aynı yetkinin farklı seviyelerde uygulanabilmesi. Örneğin, eğer veritabanı seviyesinde bir yetkilendirme yapıyorsanız, yaptığınız yetkilendirme veritabanındaki tüm nesneleri etkileyecektir. Eğer yetkilendirmeyi şema seviyesinde yaparsanız, yetkilendirme şemanın içerdiği tüm nesneler için uygulanacaktır. Tablo 1.1 SQL Server 2005’te yer alan bazı önemli yetkilendirmeleri listelemektedir. Sunucu yetkilendirmeleri sys.server_permissions view’ı, veritabanı yetkilendirmeleri ise sys.database_permissions view’ı aracılığıyla görüntülenebilir.

Password Policy Sistemi
SQL Server 2005’te yer alan bir diğer önemli güvenlik özelliği ise password policy’ler. Yeni policy enforcement özelliği yerel Windows password policy’lerini izleyerek, kurumsal ölçekte sadece Windows Server sistemlerde değil, SQL Server sistemlerde de tutarlı bir Security policy oluşturmanızı mümkün kılar. SQL Serer 2005 artık parola kompleksliği, geçerlilik süresi ve account lockout policy’lerini destekliyor. Bu özelliklerden, Windows 2000 serverda desteklenen parola kompleksliği dışında tamamı Windows Server 2003 tarafından desteklenmektedir. Tüm bu güvenlik önlemleri, varsayılan kurulumda aktif haldedir ancak kurulum sonrasında değiştirilebilmektedir. SQL Server 2005 password policy’leri sys.sql_logins katalog view’ında saklar.

Katalog Güvenliği
Bu bölümde ele alacağımız son güvenlik yeniliği, catalog Security özelliği. Farklı veritabanlarında ve master veritabanında saklanan SQL Server 2000 tarafından kullanılan sistem tabloları, SQL Server 2005’te catalog view’larında toplanmıştır. Bu view’lar tarafından sunulan metadata varsayılan olarak korunma altına alınmıştır ve çok kısıtlı public yetki söz konusudur. SQL Server 2005’in catalog view’ları, içerdikleri verilere sadece nesnelerin ownerı olmanız veya gerekli yetkilere sahip olmanız durumunda erişebilmenizi sağlayan, row-level Security uygulamaktadır. Doğal olarak sa kullancısı bu durum için bir exception’dır. Sa accountu halen sunucu üzerindeki her nesneye tam erişim yetkisine sahip durumdadır.

Bir kullanıcı veya rolün metadata’ya erişmesini sağlamak için DBA’in VIEW DEFINITION yetkisini kullanması gerekir. VIEW DEFINITION yetkisi bir kullanıcıya, owner’ı olmadığı veya erişim hakkı olmayan bir nesne üzerinde, nesnenin metadata’sına erişme imkanı vermek amacıyla kullanılır. VIEW DEFINITION yetkisi sunucu, veritabanı, şema veya nesne seviyesinde uygulanabilir.

Bir sonraki bölümde SQL Server 2005’te veritabanı yönetimi ve programlaması alanlarındaki yenilikleri ele alıyor olacağız.

Kullanılan Kaynaklar;
SQL Server 2005 Books Online
SQL Server 2005 MSDN Site

Kadir Sümerkent
kadir@sumerkent.com

21 Kasım 2007
Yazar: | Kategori: Genel
Yorum: 0

SQL Server Güvenliği

 

Windows 2000/2003 Server da var olan kullanıcı yetkileri, kullanıcıların domain içinde veya lokaldeki üyelikleri sistem güvenliği için çok önemlidir. Aynı şekilde  SQL Server 2000’de de kullanıcılara tanımlanan oturumları, izinleri ve rolleri detaylı bir şekilde bilmek ve bu gereksinimlere göre tanımlamalar yapmak sistem güvenliğini sağlamak açısından belirleyici özelliklerdir.Atadığınız roller ve izinler veritabanına bağlanan kullanıcıların hangi tür veriye ulaşabileceklerini veya neleri yapıp yapamayacaklarını belirler.

 

SQL Server Güvenlikleri dört ana başlıktan oluşmaktadır. Bunlar;

  • SQL Server Kimlik Doğrulama Kipleri
  • Sunucu Oturumları
  • İzinler
  • Roller

 

1.Adım Olarak SQL Server Kimlik Doğrulama Kipleri

SQL Server’da iki tür kimlik doğrulama kipi vardır

Windows Authentication Only:Windows etki alanında bulunan kullanıcı ve grup hesaplarını kullanabilirsiniz.Domain’de (etki alanında) tanımlı kullanıcılara birde SQL Server oturum açma adı ve parolası vermenize gerek kalmadan veritabanlarına erişim yapabilirler.

Karma Güvenlik: Veritabanına şirket dışından erişim oluyorsa, etki alanı kullanılmıyorsa Karma Güvenlik kipiyle veritabanlarına erişim sağlanabilir.

SQL Server kimlik doğrulama kiplerini görmek için Enterprise Manager tıklayın çalışmak istediğiniz Sunucuyu içeren sunucu grubuna erişin, sonra da ve Enterprise Manager ağaç yapısındaki sunucu adını farenin sağ düğmesiyle tıklayın ve özelikleri seçin. Security tabında kimlik doğrulama modları yer almaktadır.

 

2.Adım Olarak Sunucu Oturumları

İki tür kimlik doğrulama kipi bulunduğu gibi iki türde sunucu oturumu mevcuttur. Etki alanın oturumlarını, etki alanında ya da yerel kullanıcı hesabını yerel grup hesaplarında ya da evrensel veya genel etki alanı grup hesapları olabilen etki alanı hesaplarını kullanarak yaratabilirsiniz. SQL Server oturumlarınız unique (benzersiz) bir oturum adı ve parola belirleyerek yaratırsınız. Varsayılan ayar olarak gelen oturumlar aşağıda yer almaktadır.

  • Yerel Administrators grup
  • Yerel Administrator hesabı
  • sa oturumu
  • guest oturumu
  • dbo oturumu

 

3.Adım Olarak İzinler

İzinler, kullanıcıların SQL Server üzerinde yada bir veritabanında yapabileceklerini belirler ve kullanıcılara oturum kimlik’ine ,grup üyeliğine ve rol üyeliğine göre verirler.Kullanıcıların veritabanında bir değişiklik yapma yada bir şeyi silme gibi eylemleri gerçekleştirmeden önce uygun izinlere sahip olmaları gerekmektedir.

SQL Server izinler üç ana başlıkta toplanır:

  • Nesne izinleri (object permissions)
  • Bildiri izinleri (statement permissions)
  • Kendiliğinden izinler (implicit permissions)

 

Nesne İzinleri:Tablo ,görünüm ve sütunları erişimi düzenleyen izinlerdir.Örneğin sadece raporlama üzerinde çalışan bir kullanıcıya bir tablodan sadece bilgi seçme (select) hakkı verilebilir,bu kullanıcı tabloya herhangi bir bilgi ekleme(insert),güncelleme(update) ve silme(delete) yetkisi vermeyebiliriz

 

Nesne Türü                                   Eylemler

Column                                          select ve update

Row                                               N/A(Tablo düzeyinde ayarlanır)

Stored Procedure                           Execute

Table                                              Select,insert,update,delete ve references

View                                              Select,insert,update,delete

 

Bildiri İzinleri:Bir veritabanı yaratmak veya bir veritabanına nesne eklemek için kullanılan yönetici izinleridir.Bu tür izinleri System Administrators rolüne sahip üyeler kullanabilir.Varsayılan ayarlarda normal oturumlara bildiri izinleri verilmez,daha sonra isteğe bağlı olarak verilebilir.Örneğin bir kullanıcıya veritabanını yedekleme izni vermek istiyorsanız backup database yürütme izni verilmelidir.Bu tür izinler verilebilir ve daha sonra o kullanıcıda geri alınabilir izinlerdir.Bu izinler aşağıda yer almaktadır:

Create Database: Kullanıcının Veritabanı yaratıp yaratmayacağı belirler.

Create Default: Kullanıcının tablo sütunu içinde varsayılan bir değer yaratıp yaratmayacağını belirler.

Create Function: Kullanıcının veritabanında kendi tanımladığı bir işlev değer yaratıp yaratmayacağını belirler.

Create Procedure: Kullanıcının saklı yordam değer yaratıp yaratmayacağını belirler.

Create Rule: Kullanıcının bir tablo sütunu değer yaratıp yaratmayacağını belirler.

Create Table: Kullanıcının bir tablo değer yaratıp yaratmayacağını belirler.

Create View: Kullanıcının bir görünüm değer yaratıp yaratmayacağını belirler.

Backup Database: Kullanıcının veritabanını yedekleyip yedekleyemeyeceğini belirler.

Backup Log: Kullanıcını işlem günlüğünü yedekleyip yedekleyemeyeceğini belirler.

 

Kendiliğinden İzinler: Önceden tanımlı rollerin üyeleri yada veritabanı nesnesi sahiplerin kendiliğinden olan izinleridir. Kendiliğinden olan izinler değiştirilemezler. Örneğin System Administrators’ın SQL Server’da tüm eylemleri gerçekleştirebilmesi gibi.

 

4.Adım Olarak Roller

Bir grup kullanıcıya kolayca izin atayabilmek için kullanılan ve değiştirilemeyen önceden tanımlı izinlerdir.

  • Sunucu Rolleri
  • Veritabanı Rolleri

 

Sunucu Rolleri: Sunucuyu yönetebilmek için kullanılır. Sunucu rolleri sunucu düzeyinde ayarlanır ve önceden tanımlıdırlar. Bu izinler tüm sunuyu etkiler ve değiştirilemezler.

Resimdeki sunucu rollerinin açıklamaları ise şu şekildedir.

Bulk Insert Administrators(bulkadmin): Veritabanına yığın eklemeleri yapmaları gereken etki alanı hesapları için tanımlanmış roldür. Bu rolün üyeleri bulkadmin’e üyeler ekleyebilir ve Aşağıda belirtilen izinlere sahiptirler.

Database Creators(dbcreator): Veritabanı yaratma, değiştirme ve iptal etme yetkisini içeren roldür. Aşağıda belirtilen izinlere sahiptirler.

 

Disk Administrators(diskadmin):Disk dosyalarını düzenleyebilme yetkisi verilmek istenen kullanıcılara atanan roldür. Aşağıda belirtilen izinlere sahiptirler.

Process Administrators(processadmin): SQL Server işlemleri denetleyebilme yetkisine sahip kullanıcılar bu role eklenirler. Process admin’e üye ekleyebilirler ve işlemleri kesebilirler.

Securtiy Administrators(securityadmin):Oturumları düzenler, veritabanı izinleri yaratır ve hata günlüklerini okuması gereken kullanıcılar bu role eklenirler. Aşağıdaki izinlere sahiptir.

Server Administrators(serveradmin): Sunucu ayarlamaları yapabilmesi ve sunucuyu kapatılabilmesi gereken kullanıcılar bu role eklenirler ve aşağıda yer alan izinlere sahiptirler.

Setup Administrator(setupadmin):Bu role üye kullanıcılara setup admine üye ekleyebilir ve bağlı sunucular ekleyip silebilirler.Aşağıda yer alan izinlere sahiptirler.

System Administrators(sysadmin): SQL Server üzerinde tam denetime sahip olması istenen kullanıcılarda sysadmin’de olmalıdırlar. SQL Server’da tüm uygulamaları yerine getirebilirler.

Veritabanı Rolleri: Veritabanı üzerinde izinler atamak istediğinizde veritabanı rollerini kullanabilirsiniz. Bu roller veritabanları için tek tek ayarlanır, yani bir kullanıcının her veritabanında farklı rolleri olabilir.

 SQL Server’da önceden tanımlı veritabanı rolleri mevcuttur. Önceden tanımlı roller yerleşiktir ve değiştirilemeyen izinleri vardır. Aşağıda önceden tanımlı roller ve açıklamaları yer almaktadır.

db_accesadmin: Bir veritabanına oturum ekleme ve çıkarma yetkisine sahip olması gereken kullanıcılar bir role üye edilmelidir.

db_backupoperator: Veritabanı yedeklemesi yapması gereken kullanıcılar bu role üye olmalıdırlar.

db_datareader: Veritabanından veriyi görüntüleyebilirler.

db_datawriter: Veritabanı üzerinde değişiklik yapabilme yetkisine sahip kullanıcılar bu role üye yapılmadırlar. Bu role üye kullanıcılar delete, insert ve update işlemlerini yapabilirler.

db_ddladmin: Bu role üye kullanıcılar SQL Server’ın veri tanımlama dili (data definition language-ddl)ile ilgili haklara sahip olurlar.

db_denydatareader: Veritabanı oturumunda olan kullanıcıların veriye erişimini kısıtlamak için oluşturulan roldür. Veritabanındaki tüm nesnelerde select izinlerini yasaklayabilir veya geri alabilirler.

db_denydatawriter: Bu rolün üyeleri Veritabanındaki tüm nesnelerden insert,update ve delete izinlerini yasaklayabilir yada geri alabilirler.

db_securityadmin: İzinleri ,nesne sahipliğini ve rolleri düzenleyebilmesi gereken kullanıcılar bu role üye edilmelidir.

 db_owner: Veritabanı üzerinde her türlü denetime gereksinimi olan kullanıcılar bu role üye edilmelidirler. Bu rolün üyeleri izinleri atayabilir, veritabanı ayarlarını değiştirebilir, veritabanına bakım uygulayabilir ve veritabanı üzerinde diğer tüm yönetim görevlerini gerçekleştirebilir.

public: Tüm veritabanı kullanıcılarına varsayılan olarak gelen bir roldür. En düşük izin ve ayrıcalıklarını taşımaktadır. Bir kullanıcıya public dışında atadığınız her rol, yeni ayrıcalık ve izin ekler.

 Yukarıda açıklamaları yapılan Veritabanı Rollerine istenirse kendinizde yeni Veritabanı Rolleri ekleyebilirsiniz. Yeni Rol eklemek istediğiniz veritabanına girin ve Roles’ın üzerinde farenin sağ tuşu ile New Database Role seçin.

Kendinizin eklemek istediğiniz yeni Veritabanı Rolünün adını yazın ve Standard Role altında yer alan Add butonuna basın ve bu role üye yapmak istediğiniz kullanıcıyı ekleyin.

Permissions butonuna basarak açılan pencereden eklediğiniz kullanıcının o veritabanındaki hangi işlemleri yapmasını ve yapmamasını istiyorsanız bu ayarlamaları yapın.

Columns butonuna basarak izni düzenlediğiniz veritabanında kullanıcının kolonlarda ne çeşit işlemler yapıp, yapamayacağını ayarlarsanız.

Bu işlemlerle oturum ile nesne izinleri sağlamış olursunuz.

Sunucu oturumlarının, İzinlerin ve Rollerin kullanıcılar üzerindeki etkilerini öğrendikten sonra çalışmak istediğiniz sunucuda bir kullanıcı yaratmayı ve tüm yukarıda anlatılanların nasıl yapıldığını bir örnekle tamamlayıp, SQL Server’da Güvenlik konusunu tamamlayalım.

 Varolan oturumları görmek için Enterprise Manager’ başlatın ve çalışmak istediğiniz sunucuya gelin, Sunucunun Security klasörünün altındaki Logins girişini seçin.

Resimde sağ tarafta yer alan Name,Type,Server Access,Default Language ve Default Database açıklamaları ise şu şekildedir.

Name :Oturum adı,

Type: Standard SQL Server’daki oturumları,Etki alanı kullanıcısı için Windows User ve Etki alanı grup hesaplarını Windows Group göstermektedir.

Server Access: Kullanıcın sunuya erişim iznini gösterir,Permit izinin var olduğunu,Deny olmadığını belirtir.

Default Database: Kullanıcı için varsayılan veritabanını.

Default Language: Kullanıcı için atan dili göstermektedir.

 Logins üzerinde farenin sağ tuşuna basın ve New Login seçin.

 

Yukarıdaki Resimde Windows Authentication’a göre açılan kullanıcı görülmektedir.

Yukarıdaki resimde ise SQL Server Authentication’a göre açılan kullanıcı görülmektedir.İstediğiniz  kimlik doğrulama tipine seçtikten sonra.Server Roles ve Database Access’leri tanımlamanız gerekmektedir.

Server Roles’da, kullanıcıya Sunucu üzerindeki rolleri tanımlanır bu rollerin ne tür izinler ve yetkiler verdiği daha önceki bölümlerde anlatılmıştı

Database Access’le  ise kullanıcının hangi veritabanına login olabileceğini ve bu veritabanı üzerinde nasıl izinleri sahip olacağı bu alanda tanımlanır.

Eğer daha sonraki günlerde SQL Server Authentication’a göre açılan kullanıcı şifresinin değiştirilmesi isteniyorsa Password alanına yeni şifre yazılır ve confirm kutusuna aynı şifre onaylanır.

Açılan kullanıcı şirketinizden ayrılmış veya herhangi bir sebepten dolayı kullanıcı için açılan hesabı kaldırmak istiyorsanız.Kaldırmak istediğiniz kullanıcın üzerinde farenin sağ tuşu ile tıklanır ve Delete (sil)seçilir.

 

 

Veritabanı Yöneticisi olarak, SQL Server Kimlik Doğrulama Kiplerini, Sunucu Oturumlarını, İzinleri ve Rolleri kâğıt üzerinde daha önceden belirler ve bu prosedüre göre işlemler yaparsanız sonradan çıkabilecek büyük güvenlik sorunlarını önlemiş ve daha az performansla daha kolay bir yönetim yapmış olursunuz.

 Kaynak:

microsoft.com

70-228: Microsoft SQL Server 2000 System Administration Training

Bir sonraki Makale’de Görüşmek Üzere…

 

Yazar: | Kategori: Genel
Yorum: 0

Microsoft’un yeni işletim sistemlerinde sürekli olarak güvenlik seviyesini arttırdığını biliyoruz, Vista ve Server 2008 işletim sistemlerinde de güvenliğin son derece ön planda olduğunu söylemek mümkün. Özellikle Group Policy lerde olağanüstü bir genişleme ve yenilik ilk bakışta göze çarpıyor. Ben de bu makalemde sizlere yeni versiyon işletim sistemlerindeki Group Policy dosyalarının farklarını ve olası hataların önlenmesi için neler yapılması gerektiğini anlatacağım.Daha önceleri .adm formatında olup sadece kendi platformunda çalışabilen Group Policy dosyaları ( En fazla notepad ile açabiliyorduk ki bu bizim düzenlememiz için düşünülmemiş.) artık .admx formatında ve xml programlarıyla görüntülenebiliyor.

Dosyaların arasında ki en büyük ve en önemli farklardan biri ise şu; önceki işletim sistemlerinin kullandığı Group Policy dosyalarında sadece işletim sisteminin kendi varsayılan dili kullanırken yeni Group Policy dosyaları belirtebileceğimiz farklı dillerde güncellenebiliyor. Bu da .admx uzantılı dosyaların çoklu dil desteği sağlaması anlamına geliyor.

Bununla beraber Group Policy dosyalarının yerinin de değiştiğini belirtmekte fayda var. Daha önce %systemroot%\inf konumunda bulunan dosyalar artık %systemroot%\policyDefinitions klasöründe bulunmaktadır ve aşağıda ki örnekte olduğu gibi varsayılan dil altında bütün Group Policy dosyalarının bir kopyası bulunmaktadır.

Dosyaların içerik farklılıkları hakkında bir ön bilgi sahibi olduktan sonra eski Group Policy dosyalarının yenilerine uyarlamasına geçebiliriz. Tabi ki yeni kuracağımız sistemde tam manasıyla bir alt yapı değişikliği yapacak olursak dosyaları da uyarlamaya ihtiyaç duymayız. Fakat eski işletim sistemleriyle beraber çalışacağımızı varsayıyorum. Açıkçası yeni sürüm işletim sistemine sahip server ve client ları eklemeden önce eski server ve client larımızın burada bahsettiğim yeni ayarlar ve dosya türlerinden etkilenmemesini düşünmek olanaksızdır.

Bu noktada .adm dosyalarının uzantılarını .admx olarak mı dönüştürmemiz gerekecek diye düşünülebilir. Elbette kesinlikle hayır, tahmin ettiğiniz gibi Server 2008 ve Vista da bulunan Group Policy Editor , Vista, Server 2003, 2000 ve Xp de kullanılan .adm dosyalarını düzenleyebilecek şekilde tasarlanmıştır. Adm şablonunun düzenlemenin açıklaması ise şu; Group Policy objelerini ara yüzden düzenlerken bu dosyaların üzerine yazıyorsunuz demek oluyor, örnek olarak domain ortamında ki kullanıcıların Windows Movie Maker ı kullanmalarını yasaklamak için Group Policy ayarlarını yapılandırdınızda sonuç olarak ilgili .adm dosyasını aşağıdaki gibi yapılandırmış olursunuz.

CATEGORY !!MovieMaker

POLICY !!MovieMaker_Disable

#if version >= 4

SUPPORTED !!SUPPORTED_WindowsXPSP2

#endif

EXPLAIN !!MovieMaker_Disable_Help

KEYNAME “Software\Policies\Microsoft\WindowsMovieMaker”

VALUENAME “MovieMaker”

VALUEON NUMERIC 1

VALUEOFF NUMERIC 0

END POLICY

END CATEGORY

Şimdi örnek bir yapı oluşturalım, yalnız ondan önce eğer “file replication” servisinin transfer zamanını beklemek istemiyorsanız bu yapıyı PDC üzerinde oluşturmanızı tavsiye ederim.

Aşağıdaki yapıyı oluşturmaktaki amaç Server 2008 ve Vista nın 2000–2003 ve Xp de ki gibi her bir Group Policy için ayrı klasörler açmaması ve dosyaları tek bir merkezi klasörde toplaması. Merkezi klasörler grubu oluşturarak aynı domain yapısındaki Domain Controller ların da kendi içinde dosya oluşturması yerine aynı merkezi kullanması ve dosyaları bu dizinden almasını sağlamış oluyoruz.

Yukarıda belirttiğimiz gibi İlk önce klasörleri oluşturalım.

%systemroot%\sysvol\domain\policies\PolicyDefinitions
%systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US

Daha sonra varsayılan klasördeki dosyaları almanız için önceden hazırlanmış Xcopy komutunu kullanabilirsiniz. ( Bat olarak kaydedebilir ya da direk komut satırına kopyalayabilirsiniz. )

CD C:\
Xcopy %systemroot%\PolicyDefinitions\* %systemroot%\sysvol\domain\policies\PolicyDefinitions\
Xcopy %systemroot%\PolicyDefinitions\en-us\* %systemroot%\sysvol\domain\policies\PolicyDefinitions\en-us

Daha sonra gpmc.msc komutu ile Group Policy Object Editor u açın ve yeni bir Group Policy oluşturun , objeyi modifiye edip kapatın ve dosyanın yeni formatta modifiye edildiğini kontrol edin.

Ve herhangi bir member server üzerinde dosyaların doğru dizinde konumlandırıldığını kontrol edin.

Böylece eski sistem Group Policy dosyalarınızı kaybetmeden veya yeni dosyalarla çakışmaya uğramadan kullanabilirsiniz.

Bir başka Server 2008 makalesinde daha görüşmek üzere…

Yazar: | Kategori: Genel
Yorum: 1

Windows Xp Pro ve 2000 Pro ile birlikte gelen IIS Server yazılımı ile bilgisayarımızda sadece tek bir web sitesi yayınlayabiliyoruz. Fakat bu kısıtlama Windows Server ürün ailesi için geçerli değil. IIS Server üzerinde dilediğimiz kadar web sitesi yayınlayabiliriz ve bunların içerikleri birbirinden tamamen farklı olabilir. Peki, gelen bir isteğin hangi web sitesine ait olduğunu IIS nasıl anlayacak? IIS Server gelen web isteklerini 3 farklı kıstasa göre değerlendirip birbirinden ayırabilir;

1-) IP Adresi

2-) Port Numarası

3-) Host Header Bilgisi

Şekilde bir web sitesinin özellikleri görünmektedir. Yukarıdaki bilgiler bu bölümden değiştirilebilir.

IIS üzerinde aynı ip üzerinden birden fazla web sitesini yayınlayabilmek için farklı port numaraları kullanabiliriz. Örneğin ilk web sitemiz standart http portu olan 80 nolu portu kullanırken ikinci site 81 nolu portu kullanabilir. Fakat bu kabul edilebilir bir durum değildir çünkü böyle bir durumda sitemizi ziyaret etmek isteyen kullanıcılar web tarayıcılarına http://www.sitemiz.com:81 gibi bir url yazarak siteye erişmek zorunda kalacaklar. bu durumun önüne geçmek için IIS Host Header bilgisini kullanır. Farklı siteleri farklı DNS domain isimleriyle yayınlarız. Bu DNS domain isimleri (örn; www.aslankara.com) aynı zamanda o sitenin Host Header bilgisini oluşturur. IIS aynı ip’nin 80 nolu portuna gelen istekleri bu bilgiden ayırt eder ve birçok siteyi sorunsuz biçimde yayınlama imkânı sağlar.

Fakat işin içine SSL girdiği zaman Host Header bilgisi artık kullanılamaz. IIS SSL ile gelen güvenli web isteklerini karşılarken Host Header bilgisine ulaşamayacağından yukarda anlattığımız durum söz konusu olur ve bir ip üzerinden aynı porttan (standart ssl portu 443) sadece bir güvenli web sitesi yayınlayabiliriz. Yeni bir web sitesi için yeni bir ip ye yada yeni bir porta ihtiyaç vardır. Yeni port kullanarak çözmek pek mantıklı olmayacak çünkü kullanıcıların sitemize erişmesi web adresinin haricinde birde port numarası girmeleri gerekecek ki bu reel hayatta pek doğru bir çözüm değildir. Burada yapılması gereken eğer gerçekten böyle bir ihtiyaç varsa ve birden fazla farklı web sitesi IIS üzerinde SSL kullanılarak yayınlanmak isteniyorsa her site için farklı ip adreslerinin kullanılması gerekmektedir.

Şirketimize ait web sitelerini tek IIS üzerinden güvenli bir şekilde yayınlamak için bir çözümde aynı SSL sertifikasını birden fazla site için kullanmak olabilir. Eğer tek sertifika birçok site için kullanılabilirse yukarıdaki Host Header sorunu ortadan kalkar. Fakat burada da bir problemimiz var. SSL sertifikaları talep edilirken “Common Name” başlığında sitemizin Host Header bilgisini girmemiz gerekmektedir. Eğer bu bilgide bir hata olursa İnternet Explorer web sitesini her açtığında güvenlik uyarısı verecektir. Şekilde bu uyarı görülmektedir.

Her site için ayrı bir sertifika kullanabilseydik bu bir sorun olmazdı fakat IIS yukarıda bahsettiğim sebeplerden sadece tek bir SSL sertifikasını kabul eder. Burada da imdadımıza “Wildcard Common Name” yetişmektedir. Sertifikayı isterken Host Header bilgisini yazdığımız Common Name bölümüne *.aslankara.com gibi bir ifade yazarak tüm sub domainleri kapsayan bir sertifika çekebilir ve tüm web sitelerimiz için kullanabiliriz. Şimdi adım adım bu işlemi gerçekleştirelim. Örneğimde banka.aslankara.com ve alisveris.aslankara.com isimli iki web sitesini aynı sertifikayı kullanarak yayınlayacağım.

Şekilde görüldüğü üzere standart halde her iki web sitesi 80 nolu porttan farklı Host Header bilgileri ile sorunsuz bir şekilde hizmet veriyor. İlk iş olarak alışveriş sitesi için bir sertifika talebinde bulunuyorum. Bunun için aşağıdaki adımları izlememiz gerek.

Alışveriş web sitesinin özelliklerinde Directory Security tabında Server Certificate butonuna tıklayalım. Daha sonra karşımızdan gelen sihirbazı aşağıdaki şekilde tamamlayalım. Common Name sorusuna ise verdiğimiz cevaba lütfen dikkat.

Bu işlemler tamamlandıktan sonra sertifikamızı görüntülemek için “View Certificate…” butonuna basıp durumu görelim.

Görüldüğü gibi sertifika *.aslankara.com domaini için geçerli.

Artık bu sitemizi SSL’li bir şekilde açabiliriz.

Şimdi sıra geldi ikinci web sitesini güvenli bir şekilde yayınlamaya. Bunun için farklı bir sertifika almak yerine varolan sertifikamızı örnekteki banka sitesi içinde kullanmak üzere atayacağız. Yapmamız gereken yine site özelliklerinde Directory Security tabına gelip Server Certificate butonuna tıklamak. Bu sefer karşımıza gelen sihirbazı aşağıdaki adımları uygulayarak bitiriyoruz.

İkinci sihirbazı da yukarıdaki şekilde tamamladıktan sonra her iki web sitemizde 443 nolu porttan çalışmaya başlayacak. Yada biz öyle olduğunu sanacağız çünkü IIS Server’ı yada sadece banka sitesini restart ettiğimizde göreceğiz ki banka sitesi start olamıyor. Restart etmeden tarayıcımız da https.//banka.aslankara.com yazsak dahi ilk siteyi açacaktır. Bu probleminde üstesinden gelmek için yapmamız gereken IIS metabase’deki bir değeri değiştirmektir. Metabase IIS in ayarlarının saklandığı bölümdür. IIS’in registry’si gibi düşünülebilir. Bu ayarı yapmak için aşağıdaki komutu çalıştırmamız gerekmektedir.

cscript.exe adsutil.vbs set /w3svc/<site identifier number>/SecureBindings “:443:<host header>”

Komutu c:\inetpub\adminscripts dizini altında çalıştırmalıyız zira adsutil.vbs dosyası bu dizindedir. Host Header bölümüne sitenin domain adı yani örnekte banka.aslankara.com yazılmalıdır. Site Identifier Number bilgisi ise IIS üzerinde görülebilir.

Komutu aşağıdaki şekilde koşturduktan sonra sitemiz kullanılmaya hazır olacak.

Artık sitemizi start edip güvenli bir şekilde kullanmaya başlayabiliriz. Öncesinde IIS Server Servisini restart etmeniz gerekebilir.

Yazımızın sonuna geldik. Bir başka makalede görüşmek üzere.

Yazar: | Kategori: Genel
Yorum: 1

WebFarm
Internet Information Server Clustering (Bölüm-1)

Kurumların büyüme ölçeklerini göz önünde bulundurarak söylemek gerekirse internet ya da intranet üzerinden verdikleri/verecekleri hizmetler bakımından sürekli artan bir ihtiyaç söz konusudur. Kurum içinde bu hizmetleri kullanacak personel sayısı arttıkça ya da kurumun dışarıya vermek istediği hizmetlerin boyutu -ister kullanıcı, isterse teknoloji bazlı olsun- arttıkça kurumlar server hizmetleri bakımından yeni yapılara ihtiyaç duyarlar. Günümüzün bu konudaki gözde teknolojilerinden biri “cluster” (küme) yapılardır. Bu makalede internet/intranet yani web üzerinden verilecek sistemlerdeki kullanılabilirlik, ölçülebilirlik ve performans açısından Web Server’ların Cluster yapısı anlatılacaktır.

Web Sunucularının cluster(kümeli) şeklinde çalışması için çeşitli tasarımlar geliştirilmiştir. Bu yapılar “WebFarm” şeklinde isimlendirilir. Birden çok sunucu ile ya da aynı anda birden çok süreç üzerinde eş zamanlı olarak çalışmak söz konusu olunca bu konuda çeşitli terimler ortaya konmuştur. Burada durumu biraz daha netleştirmek için Webfarm Cluster yapısının haricindeki “WebGarden” denilen başka bir yapıyı da açıklamakta fayda görüyorum. Bu yapı WebFarm’dan farklı olarak tek bir sunucu üzerinde aynı web hizmetinin devamlılığını sağlamak için birbirine eş birden fazla process oluşturarak belli bir application pool’da bulundurur ve bu yöntemle hataya karşı dayanıklılığı (Fault tolerancy) sağlar. WebFarm yapısı bundan tamamen farklı olarak birden fazla server ile “Fault tolerancy-Scalability- High Availability” ögelerini yerine getirir. Bu makelenin tümünde Windows Server 2003 R2 işletim sistemi kurulu olan sunucular kullanılmıştır. Ayrıca Internet Information Server 6.0 (IIS-6.0), Network Load Balancing Manager (NLB), Disturbed File System Management (DFS), SQL-2005, Windows Xp/Vista ayrıca çeşitli scriptler senorya gereği kullanılmıştır. Bu clustering senaryosu yukarıda sözü geçen uygulamaların başka sürümlerinin kombinasyonları ile de kullanılabilir, makale boyunca yeri geldiğince bu konuya ve bunu gerçekleştirirken karşılaşılabilecek sorunlara değinilecektir.

Konuya doğrudan girmek yerine bu bölümde cluster konusunda temel bilgiler vermeyi daha doğru buluyorum. Cluster(kümeleme) yöntemi, yukarıda WebFarm üzerine bahsettiğim gibi birden çok sunucunun belli bir amaç için beraber ya da duruma göre sırayla, belirlediğimiz sunusu kümesi içerisinde toplanarak çalıştırılmasıdır(kümelenmesidir). Bu sunucu kümesinin üyesi olan her sunucudan birine “Node”(düğüm) denir. Cluster uygulamasında yer alan node’lar tek bir birim gibi çalışarak Microsoft Internet Information Services (IIS), Exchange Server gibi uygulamalara yönelik hizmetleri yüksek kullanılabilirlik(high avaibility) ile kullanıcılara sunar. Böylelikle küme oluşturmak cluster içindeki node’ları tek tek yönetmek yerine, uygulamaya yönelik olarak tek bir sistem halinde yönetilmesini sağlar. Bunun yanı sıra bu durum kullanıcı tarafı temel alınarak incelenirse, kullanıcılar sistemin cluster şeklinde çalışıp çalışmadığını çoğu durumda sezemezler, bu da cluster içindeki sunucuların tek bir sistem şeklinde çalıştığının kanıtıdır ki cluster yapmanın en önemli amaçlarından biri budur.

Cluster uyumlu olan uygulamalara örnek vermek gerekirse:

· DFS (distributed File System)

· DHCP

· Exchange Server

· File Server görevleri (dosya paylaşımları)

· IIS (Internet Information Services)

· Microsoft Distributed Transaction Coordinator (MS-DTC)

· MSMQ (Microsoft Message Queuing)

· NNTP (Microsoft News Transfer Protocol)

· Printer Pooling

· SMTP

· SQL Server

· WINS

Bu uygulamalar farklı cluster tipleri ile uygulanabileceği gibi beraberce de belli bir sistem için kullanılabilirler. Bunların yanında farklı uygulamalar da kümeli çalışabilirler(Oracle Server vs.) Cluster ortamının oluşabilmesi için IP tabanlı protokollere ihtiyaç vardır. Uygulamalar iletişim kurmak için IPX NetBEUI tarzındaki protokolleri kullanamazlar.

Daha önceden WebFarm senaryosunda kullanılacak uygulamalardan bahsederken Windows Server 2003 (R2) demiştik, burada bu Server2003’ün desteklediği 3 çeşit cluster tipi vardır:

1- NLB (Netwok Load Balancing), sunuculara gelecek olan yükü network üzerinde, belirlediğimiz kurallara yönelik olarak (affinity) paylaştıran, ağ yükünün dengelenmesi şeklinde gerçekleşir. NLB ile TCP (Transmission Control Protocol) haricinde UDP (User Datagram Protocol) ve GRE (Generic Router Encapsulation) tarfikleri için de yük dengelemesi sağlanabilir. Webfarm uygulamasında kullanacağımız cluster tipi budur. Ayrıca Microsoft, Web Sunucuları için cluster yaparken en uygun yöntemi NLB olarak önerir.

2- CLB (Component Load Balancing), COM+ kullanan uygulama bileşenlerinin dinamik bir şekilde yük dengelemesini sağlar. Yine yüksek kullanılabilrlik-ölçeklenebilirlik(scalability) açısından birçok Node üzerinde yük dengelemesi sağlar.

3- MSCS (Server Clustering), Sunucu kümesi olarak adlandırılabilir. Cluster Administrator arayüzü kullanarak yapılandırılır. Yüksek kullanılabilirlik-Ölçeklenebilirlik-Güvenilirlik açısından uygulamalar üzerinde hataya karşı dayanıklılık (fault tolerancy) sağlar. Arka uç sunucularda (SQL Server vs.) kullanımı uygundur.

Her küme oluşturma teknolojisinin belirli bir amacı vardır ve farklı gereksinimleri karşılayacak şekilde tasarlanmıştır. NLB, web hizmetleri nedeniyle oluşabilecek kısıtlamaları engellemek amacıyla tasarlanmıştır. CLB, web tabanlı uygulamaların ölçeklenebilirlik ve yüksek kullanılabilirlik ihtiyaçlarını karşılayabilmek için tasarlanmıştır. MSCS, veri bütünlüğünü korumak(integrity) ve yerinde çalışma desteği sağlamak amacıyla tasarlanmıştır.

Konuya daha geniş bir açıyla bakarsak, bu cluster hizmetleri beraberce kullanılabilir ve çoğu durumda da bu sistemin planlanan verimde çalışması için bir gerekliliktir. Yukarıda bahsi geçen üç cluster tipinin beraberce kullanılabileceği en genel senaryo bir web sitesinin yayınlanması olacaktır. Webfarm’ın adından işte burada söz etmeye başlayarak örneklerle devam edelim. Ön uç sunucular olan Web sunucularda (IIS) NLB yani Webfarm, orta katman sunucularda CLB ve arka uçta olan veri tabanı hizmetlerinde MSCS kullanılarak (SQL Clustering) bir sistem tasarlanabilir. Bu sistem genel hatlarıyla aşağıdaki taslağa benzeyecektir, zaten ilerleyen bölümdeki uygulamaları bu taslak üzerinden yola çıkarak yapacağız.

webfarm genel.jpg

Cluster yapıları, Farm (çiftlik) ya da Paket adı verilen ikili gruplar olarak kullanılır. WebFarm bu gruplardan Farm yapısının Web uygulamalarına yönelik olarak kullanılış biçimi olduğu için bu şekilde isimlendirilir. Farm yapıları, benzer sistemler çalıştıran ama genelde veri paylaşmayan bir sunucu grubudur. Bunlara “Farm” adı verilmesinin sebebi, kendilerine iletilen tüm istekleri, verilerin sucular üzerinde yerel disklerde saklanan birebir kopyalarını kullanarak işlemeleridir. Verileri paylaşmak yerine birebir kopyalarının kullandıkları için node’lardan her biri özerk biçimde çalışır ve bunlara “Copy” (kopya) adı verilir. Paket ise bir arada çalışan ve bölümlenmiş verileri paylaşan bir grup sunucudur. Bunlara Paket denmesinin sebebi ise hizmetleri yönetmek ve korumak için birlikte çalışmalarıdır. Bir paketin üyeleri bölümlenmiş verilere erişimi paylaştığı için, işletim modları benzersizdir ve genelde paketin tüm üyelerinin bağlı olduğu disk sürücülerindeki paylaşılan verilere erişirler.

Çoğu durumda Web ve Uygulama(Application) hizmetleri Farm olarak, Arka uç veri tabanları ve kritik destek hizmetleri ise paket olarak düzenlenir. WebFarm yapısı birden fazla Farm’ın bileşimi olarak tasarlanabilir. Aynı veriler farm yapısındaki tüm Node’larda çoğaltılır ve her sunucu, kendisine gönderilen istekleri verilerin yerel kopyalarını kullanarak işleyebilir. Örneğin, NLB kullanan ve her birinde web sitesine ait olan verilerin yerel kopyası bulunan çok sayıda web sunucusu vardır. Elbetteki bir Farm içindeki sunucu sayısında da bir üst sınır vardır, bu konudan önümüzdeki paragraflarda bahsedeceğim. Biz oluşturduğumuz taslak üzerinden çalışma devam edeceğiz. Senaryomuzda WebFarm içerisinde iki adet web sunucuyu kümeli olarak çalıştıracağız. Aşağıdaki şema konu hakkında genel bir bilgi verecektir.

Paketi de kısaca açıklamak gerekirse, SQL Server çalıştıran ve bölümlenmiş veri tabanı görünümleriyle MSCS kullanan veri tabanı sunucuları bunlara örnektir. Bu durumda, paketin üyeleri verilere iletişimi paylaşır ve tüm istekleri işlemek yerine, verilerin ya da mantığın belirli bir bölümünü işlerler. Örneğin iki adet Node barındıran SQL Server cluster yapısında, bir sunucu A-M harfleri ile başlayan diğer sunucu ise N-Z harfleri ile başlayan hesapları işliyor olabilir.

Cluster mimarisi kullanan sunucular genelde üç katmanlı bir yapı kullanılarak tasarlanır bu yapı bahsettiğimiz şekilde,

Katman1- NLB’nin kullanıldığı ön uç Web sunucuları

Katman2- CLB’nin kullanıldığı çeşitli Uygulama sunucularını içeren orta katman sunucuları

Katman3- MSCS’nin kullanıldığı arka uçta yer alan veri tabanı sunucularını ya da dosya, kritik destek alanında görev yapan sunucuları içerir.

Cluster yapısı hazırlanırken bu şekildeki katmanlı bir yapı izlenmesinin asıl nedeni, cluster yapmanın asıl amaçlarından biri olan ölçeklenebilirliktir(scalability). Bu ölçeklenebilirlik istenilen katmana yeni sunucular ekleyerek ölçeğin artırılmasıyla gerçekleşebilir. Burada kritik nokta kullanılan sunucu işletim sistemidir.

· Windows Server 2003’ün tüm sürümleri, en fazla 32 Node’dan oluşan bir NLB Cluster destekler.

· Enterprise ve Datacenter Edition, en fazla 8 Node’lu bir CLB cluster destekler.

· Enterprise ve Datacenter Edition, en fazla 8 Node’lu bir MSCS cluster destekler.

İşlemci ya da RAM ekleyerek ölçek artırılmak isteniyor ise

· Standart Edition, en fazla 4 işlemci ile 32bit sistemlerde 4gb RAM ve 64bit sitemlerde 32gb RAM destekler

· Enterprise Edition, en fazla 8 işlemci ile 32bit sistemlerde 32gb RAM ve 64bit sitemlerde 64gb RAM destekler

· Datacenter Edition, en fazla 128 işlemci ile 32bit sistemlerde 64gb RAM ve 64bit sitemlerde 512gb RAM destekler

Ölçeklenebilirlik gereksinimleri belirlenirken kuruluşun “live” sitemdeki ve piyasadaki ileriye dönük gereksinimleri göz önünde bulundurulmalıdır. Doğru Windows sürümü ile uygun ölçeklenebilirlik sağlanabilir. Buna ek olarak, işlemciler ve bellek (RAM), sunucuların çalıştıracağı uygulama ve hizmetlerin yanı sıra, eş zamanlı olarak gerçekleştirilecek kullanıcı bağlantı sayısına uygun olarak boyutlandırılmalıdır. Eş zamanlı kullanıcı sayısı özellikle WebFarm senaryosunda dikkat edilmesi gereken önemli bir noktadır.

Bir sonraki bölümde NLB hakkında genel açıklamalar ile WebFarm senaryosu için yapılandırılmasını ve uygulanmasını anlatacağım.


KAYNAK:

-Microsoft/Technet

-Server2003 Inside/Out –William R. Stanek


Ahmet TOPRAKÇI
BilgeAdam IT Academy
System & Network | Beşiktaş

Yazar: | Kategori: Güvenlik
Yorum: 1

Güvenlik Duvarı(Firewall)
Firewall’lar, yerel ağınızla dış ağ arasındaki güvenlik kontrol yazılımları/cihazlarıdır. Firewall ilk kurulduğunda bu nokta üzerindeki bütün geçişleri durdurur. Daha önceden belirlenen politikalar dahilinde hangi data paketinin geçip geçmeyeceği, hangi geçişlerde parola doğrulaması yapılacağı gibi bilgiler Firewall kural tablolarına eklenir. Bu sayede sisteme ulaşan kişi ve bilgi trafiği kontrol altına alınmış olur. İçerideki/dışarıdaki sistemlere kimlerin girip giremeyeceğine, giren kişilerin hangi bilgisayarları ve hangi servisleri kullanabileceğini Firewall üzerindeki kurallar belirler.
Firewall yazılımı, adresler arası dönüştürme-maskeleme(NAT) sayesinde LAN(Local Area Network) deki cihazların IP adreslerini gizleyerek tek bir IP ile dış ağlara erişimini sağlar. Adres saklama ve adres yönlendirme işlemleri Firewall üzerinden yapılabilir. Böylece dış dünyadaki kullanıcılar yerel ağdaki kritik topoloji yapısını ve IP bilgisini edinemezler. Firewall yazılımı kendi üzerinde belirtilmiş şüpheli durumlarda sorumluları uyarabilir(e-mail, SNMP, vb.).
Gelişmiş Firewall yazılımları üzerinden geçen bütün etkinlikleri daha sonradan incelenebilmesi için kaydederler. Ek bir lisans yada modül ile birlikte VPN(Virtual Private Network) denilen yerel ağa gidip gelen bilgilerin şifrelenmesi ile uzak ofislerden yada evden internet üzerinden güvenli bir şekilde şirket bilgilerine ulaşmak mail vb. servisleri kullanmak mümkün olmaktadır. Bu şekilde daha pahalı çözümler yerine(lised line yada frame relay) Internet kullanılabilir. Yalnız uzaktaki kullanıcıların güvenliği burada ön plana çıkmaktadır. Dışarıdan bağlanan kişinin gerçekten sizin belirlediğiniz yetkili kişi olup olmadığı önemlidir. Bu kişilerin şifresini ele geçirenler sisteminize o kişilerin haklarıyla ulaşabilirler. Bu noktada kişisel Firewall ve dinamik şifre üreten tokenlar devrede olmalıdır.
Günümüzdeki gelişmiş Firewall sistemleri içerik denetleme işlemi yapmamakta bu tip hizmetleri Firewall sistemleriyle entegre çalışan diğer güvenlik sistemlerine yönlendirmektedir. Bu sayede güvenlik firmaları sadece odaklandıkları ve profesyonel oldukları konularda hizmet vermekte, kullanıcı da bu ayrık sistemlerden kendisi için uygun olan çözümleri tercih etmektedir. Örneğin gelen bilgilerin içerisinde virüs olup olmadığı yada atak yapılıp yapılmadığı Firewall tarafından kontrol edilmez. Kurallarda belirtilmişse kendisi ile entegre çalışan sisteme data paketini yönlendirir. Tarama işlemi diğer makinada yapıldıktan sonra paket tekrar Firewall a geri döner.
Firewall yazılımının yönetim konsolu merkezi yönetim amaçlı olarak ayrı makinelere yüklenebilir. Yönetim ile ilgili kurallar, trafikle ilgili kayıtlar(log) ayrı sistemlerde tutulabilir. Kullanıcı grafik ara yüzü ile uzak makinelerden kolayca yönetim yapılabilir ve mevcut kullanıcı bilgileri (LDAP) uygulamalarından alınabilir. Aktif bağlantılar görüntülenip gerektiğinde ana güvenlik politikalarına engel olmadan bağlantılara müdahale edilebilir. Bant genişliği yönetimi sağlayan sistemlerle entegre olabilir.
Firewall yazılımları/cihazları güvenliğin yapı taşları olup sistem içerisindeki diğer güvenlik yazılım/cihazları ile uyumlu çalışmakta ve gelecekteki güvenlik teknolojilerine taban teşkil etmektedirler. Firewall yazılımı kesinlikle şart olmasına rağmen güvenlik için tek başına yeterli değildir.

VPN (Virtual Private Networks)
VPN sayesinde hem maliyetlerimizi azaltmamız hem de daha önceden güvenli olmadığı, ayrıca pahalı olduğu için yapamadığımız farklı mekanlardaki PC ve LAN’ları internet üzerinden aynı platformlara taşımamız mümkün. Bu sayede evimizdeyken şirketimize bağlanıp sanki oradaymış gibi güvenli bir şekilde şirket kaynaklarına ulaşmamız, maillerimizi kontrol etmemiz, Intranet’i kullanmamız mümkün olmaktadır.
Bu sayede mobil çalışanlarımızı, uzak bürolarımızı, bayilerimizi, iş ortaklarımızı bizim belirlediğimiz kriterlere göre şirket içi kaynaklarından faydalanmalarını sağlayabiliriz. Lised lines ve frame-relay hatların pahalı çözümlerine alternatif olarak Internet’i kullanabiliyoruz. Tabi akla gelen ilk soru Internet üzerinde bilgi alışverişi yapılırken bilgilerimiz ne derece güvende. VPN teknolojilerinde taraflar arasında karşılıklı şifreleme söz konusu ve bu şifreleme teknolojileri oldukça gelişmiş durumda. Güvenlik için bilgiler karşılıklı dijital olarak imzalanır, sonra bu paketler uluslar arası standartlara uygun çeşitli protokollerden biri tarafından şifrelenir ve karşı tarafta da benzer şekilde açılır. Yalnız VPN sadece bilgi gidip gelmesi sırasındaki güvenliği kapsadığından karşılıklı yapıların firewallar tarafından korunması gerekmektedir. Sizin bölgeniz çok güvenli olabilir ama size bağlanan evdeki bilgisayarın güvenliği de önemlidir. Çünkü dışarıdan içeri normal şartlarda sızamayan kişiler zincirin en zayıf halkasından içeri sızabilirler.
VPN uygulamalarında dikkat edilmesi gereken karşılıklı bağlantılar sırasında statik şifre kullanılmamasına dikkat edilmesi token/smart card benzeri çözümlerle desteklenmesi gerekir.

Antivirüs
Ev kullanıcılarından büyük şirketlere herkes Antivirüs çözümü kullanması gerektiğinin farkındadır. Kurumların ihtiyaçlarını ev kullanıcıları gibi düşünemeyiz. Artık eski sistem desktop bazlı korumalar tek başına yeterli olmamaktadır. Örneğin bu tip bir sistem bilgisayarın açılması sırasında daha virüs koruma yazılımı devreye girmeden ağdaki virüslenmiş bir sistem tarafından dosya paylaşımından faydalanarak sisteme girip Antivirüs korumasını devre dışı bırakabilmektedir. Yada son günlerde tanık olduğumuz sistem açıklarını kullanarak yayılan “worm”larda olduğu gibi. Bu yüzden yeni teknolojilerde virüslerin merkezi bir yapı tarafından daha yerel ağa girmeden önce taranması fikri esas alınmaktadır.
Virüslerin en çok yayıldığı servisler olan e-mail, http ve ftp trafikleri Firewall mantığı esas alınarak Antivirüs ağ geçidine yönlendirilir. Buradaki tarama işleminden sonra gerekli yerlere yönlendirilme yapılır. Bu sistemle dışarıdan gelecek olan virüsler engellenmiş olur. Mail sunucuları üzerine kurulan Antivirüs sistemiyle yerel ağ içerisinde e-mail aracılığıyla dolaşan virüslerde etkisiz hale getirilmiş olur.
Sunucu bilgisayarları üzerine kurulacak virüs koruma yazılımları ve şirket çalışanlarının sistemlerini kontrol edecek yazılımlarla kurumsal Antivirüs çözümü sağlanmış olur.
Bütün bu virüs sistemlerinin tek bir merkezi noktadan kontrolü ve tek bir noktadan Antivirüs güncelleme dosyalarının alınıp dağıtılması yapılabilmektedir. İstenirse Firewall la entegre çalıştırılabilmektedirler. Otomatik olarak gerektiğinde her saat başı yeni güncelleme dosyaları alınabilmektedir. Bu sistemlerle ayrıca rahatsız edici mailleri engellemek, içerdiği kelimelere yada eklerine göre silme/arşivleme vb. işlemler yapılabilmekte kısaca mail yönetimi sağlanabilmektedir.
Kurumsal Antivirüs Koruması seçerken dikkat edilmesi gerekenler
Virus taraması yaparken performans kaybı yaşanmamalıdır. Mümkünse uluslararası sertifikaları sorulmalıdır.Her türlü zararlı kodlara karşı tarama yapabilmelidir (Trojans, droppers, ActiveX ve Java) Müşteri tarafına her türlü yoldan zararlı kodların ulaşabileceği düşünülmeli sunulan çözüm bütün zararlı kodları tesirsiz hale getirebilmelidir. Sizi virüslerin çoğundan değil hepsinden koruyan sistemlere ihtiyacınız olacaktır. Sorunla karşılaşıldığında servisini ve desteğini alabileceğiniz ürünlere yönelin. Sisteminize entegre olup olmayacağını sorun çünkü yeni teknoloji virüs tarayıcılar Firewall sistemleriyle Proxy lerle mail sunucularıyla entegre çalışabilmektedir Bütün virüs sistemini mümkünse tek yerden yönetebileceğiniz sistemleri seçmeniz avantajınıza olacaktır. Merkezi raporlama ve otomatik güncelleme (yeni virüslere karşı) yapması da işlerinizi kolaylaştıracaktır.

IDS (Saldırı Tespit Sistemleri)
Saldırı Tespit Sistemleri, Internet dünyasının gelişim sürecinde özellikle tüm dünyada kullanılan web trafiğinin artması ve de web sayfalarının popüler hale gelmesi ile birlikte kişisel ya da tüzel sayfalara yapılan saldırılar sonucu ihtiyaç duyulan en önemli konulardan biri haline gelmiştir. Bununla birlikte kurum ya da kuruluşların sahip oldukları ve tüm dünyaya açık tuttukları mail, dns, database gibi sunucularının benzeri saldırılara maruz kalabilecekleri ihtimali yine Saldırı Tespit Sistemlerini Internet Güvenliği alanının vazgeçilmez bir parçası haline getirmiştir. Kurumların sahip oldukları çalışan sayısı ve bu çalışanların kendi kurumlarındaki kritik değer taşıyan yapılara saldırabilme ihtimalleri de iç ağın ya da tek tek kritik sunucuların kontrol altında tutulma gerekliliğini beraberinde getirir.
IDS(Intrusion Detection System) genel olarak iki tip olarak karşımıza çıkar; Sunucu tabanlı IDS ve Ağ tabanlı IDS.
Ağ tabanlı IDS in görevi, bir kurum yada kuruluşun sahip olduğu ağ yada ağlara yönlenmiş olan tüm trafiği algılayarak, bu ağa doğru geçen her bir data paketinin içeriğini sorgulamak, bir atak olup olmadığına karar vererek kaydını alabilmek, kendisi ya da konfigüre edebildiği başka bir aktif cihaz tarafından atakları kesmek, sistem yöneticisini bilgilendirmek ve ilgili raporlar oluşturabilmektir. IDS bir data paketinin atak olup olmadığını, kendi atak veritabanında bulunan atak tipleriyle karşılaştırarak anlar ve karar verir. Sonuç olarak bir IDS in en önemli bileşeni bu atak veritabanıdır. Söz konusu Atak veritabanı nın içeriği, ne kadar sıklıkla ve doğrulukla güncellendiği ve kimin tarafından oluşturulduğu/güncellendiği en önemli noktadır. Bu sebeple doğru üretici firma ve ekip seçimi çok önemlidir.
Sunucu Tabanlı IDS in görevi ise kurulu bulunduğu sunucuya doğru yönlenmiş bulunan trafiği yine üzerinde bulunan atak veritabanı(İşletim Sistemine göre özelleştirilmiş) baz alınarak dinlemesi ve atakları sezerek cevap vermesidir.

Genel olarak IDS iki veya daha fazla makineden oluşan bir yapıdır. Performans artırımı sebebiyle Merkezi Kontrol ve Kayıt mekanizmasının bir makinede, Trafiği dinleyen ağ tabanlı modül veya Sunucu tabanlı modül ayrı makinelerde tutulur.
IDS’ ler, dinlediği trafiğin kaydını tutarak, gerektiğinde bu kayıtları baz alarak istenilen şekilde raporlar çıkartabilmektedir. Atak sezdiklerinde atakları önleyebilir, yöneticilerine mail yada benzeri yollarla haber verebilirler, önceden oluşturulmuş bir program çalıştırabilir ve telnet benzeri bağlantıları kayıt ederek sonrasında izlenmesini sağlayabilirler. Tüm bu özellikleriyle IDS ler sistemin güvenli bir şekilde işlemesine yardımcı olur ve Sistem Yöneticilerinin Sistemi güçlü bir şekilde izlemesine yardımcı olmaktadırlar.

Web filtreleme çözümleri (URL Filtering)
Bugün çalışanların çoğunun Internet’e erişim hakları var. Fakat bunların hangi sayfalara gittikleri, oralarda ne kadar zaman geçirdikleri bunların ne kadarının işle ilgili olduğu gibi soruların yanıtlanması gerekiyor. Son zamanlarda yapılan bir çok araştırma iş günü içerisinde yapılan web sayfası ziyaretlerinin çoğunun işle alakalı olmadığı, sakıncalı sayfa ziyaretlerinin sistemlere virus/trojan bulaşmasına, gereksiz bant genişliği harcanmasına ve yasal olmayan sitelerden indirilen programların sistemlere sahte lisanslarla kurulmasına (ki bu programların lisanssız yada sahte lisanslarla kurulmasından sistem yöneticileri ve şirket sahipleri BSA ya karşı sorumlular) sebep olmakta.
Bütün bunları engelleyebilmek için URL filtering denilen yazılımlar kullanılmakta. Bu yazılımların her gün güncellenen veri tabanları sayesinde dünyadaki çoğu web sayfaları sınıflandırılmış durumda. Bu yazılımlar kişi, grup, IP adres aralıklarına kural tanımlamamızı sağlamaktadır. Bu sayede daha önceden tanımladığımız kişilere hangi zaman aralıklarında nerelere girebileceklerini belirlenebilir. Yada gün içerisinde bizim belirlediğimiz kategoriler için zaman kotası uygulana bilinir. Örneğin sabah 9:00-12:00 arası gazetelere yarım saat bakılma izni (bu sayfalarda kalış zamanı kotadan düşürülür) 12:00-13:00 her yere izin vb.. URL filtreleme yazılımlarıyla ayrıca anahtar kelime bazlı sınırlandırma(örnegin Mp3) yada manuel olarak sayfa eklenebilir.
Engellenen sayfalarla ilgili olarak kullanıcı karşısına bilgilendirici bir ekran çıkar ve neden engellendiği yada hangi zaman aralıklarında geçerli olduğu belirtilir. Burada daha önceden belirlenmiş bir sayfaya yönlendirmekte mümkündür. Bu tür yazılımlarının raporlama modülleri sayesinde kimlerin nerelere gittikleri oralarda ne kadar süre boyunca kaldıkları gibi ayrıntılı bilgilere ulaşmak mümkündür.
Internetin pozitif kullanımı
* eMail
* eTicaret
* Araştırmalar
* Önemli gelişmeler
* Doküman alışverişi
* Web tabanlı uygulamalar
Negatif amaçlarla kullanım
. Desktop TV, BBG tarzı yapımlar
. Porno
. Hisse senedi
. Eğlence
. Alışveriş
. Kumar
. Müzik
. Spor
. Download
. Internette en çok aratılan üç kelime Mp3, sex, hotmail (kaynak wordtracker.com)
. Çalışanların 54% ü gün içerisinde an az yarım saatlerini işle alakasız konularda internette sörf yapmaktadırlar
. Bu zamanın çoğu yetişkin sitelerinde geçmekte
. Yeni iş başvuruları yapılmakta
. Gezi siteleri ziyaret edilmekte
. Spor aktiviteleri takip edilmekte
. Konuşma odalarında bulunulmakta
. Hacker sayfaları ve hack araçlarının bulunduğu sayfalar ziyaret edilmekte

Güçlü Tanılama (Strong Authentication)
Gerçekten sistemlerinize kimlerin ulaştığını biliyor musunuz? Eğer VPN, mail, Web sayfa erişimleri, uzak erişim (remote access) v.b. bağlantılarınızda statik kullanıcı isimleri ve şifreler kullanıyorsanız bundan tam olarak emin olamazsınız. Dışarıdan yapılan bağlantılarda sizin verdiğiniz şifrelerin başkaları tarafından ele geçirilmesi yada “brute force” denilen yöntemle şifrelerin bulunması söz konusudur. Güçlü tanılama yöntemleri sisteminize erişenlerin kimliğinden emin olmanızı sağlar.

Güçlü tanılama (Strong Authentication) nedir?:
Güçlü tanılama, bir kullanıcıyı tanırken en az iki metot kullanır. 3 metotla mevcut tanılama güçlendirilebilir:
. Sahip olduğunuz şey (Something you have)
Kapı anahtarı, ATM kartı veya token
. Bildiğiniz şey (Something you know )
Şifre, PIN numarası
. Biyometrik tanılama (Something you are)
Parmak izi, ses tanıma sistemleri, retina taramaları
Bu yöntemlerin her biri tek başına yeterli değildir mesela ATM kartınızı kaybedebilirsiniz, şifreniz tahmin edilebilir. Biyometrik tanılama güçlü bir yöntem olmasına rağmen halen pahalı ve açık noktaları bulunabilmektedir. Bu yöntemlerden teki (single authentication) yerine iki metodun birlikte kullanıldığı yöntemler “two-factor authentication” yada “strong authentication” olarak bilinmektedir. Örneğin ATM makineleri iki kombinasyonu birlikte kullanırlar plastik bir kard (Something you have) ve bir PIN numarası (Something you know). Token ve smart kartlar güçlü tanılama sistemleri kullanırlar. Token ve smart kartların bir çok çeşidi bulunmakta
Smart Kartlar: Dünya üzerinde yaklaşık bir milyar kişi smart kart teknolojisini banka hesapları, ödeme, telefon sistemleri, kişisel bilgilerin saklanması(tıbbi kayıtlar gibi) için kullanıyor. Smart kartlar ATM(banka) kartlarından çip yapısıyla ayrılır. ATM kartlarında statik bilgi içeren manyetik bantlar bulunmaktadır. Smart kartlarda ise küçük bir çip bulunmaktadır. Bu sayede çip içerisinde bilgilerin saklanmasının yanında hesaplamalarda yapılabilmektedir. Manyetik kartların dış yüzeylerinde bulunan bilgilerin kopyalanabilmeside güvenlik açısından smart kart kullanımının gerekliliğini ortaya koymaktadır. Bütün bilgilerin ve işlemlerin çip içerisinde yapılması ve çipin kopyalanamaması smart kartın en büyük artıları arasında yer almakta. Ayrıca smart kartınızdaki bilgilerinize ulaşmanız için kartınızın PIN koduna ihtiyacınız var. Oldukça güvenli bu sistemlerin tek dezavantajı smart kart okuyucuya ve yazılımına ihtiyaç duyulması.
Token-Tabanlı Uygulamalar: Token çözümleri gelecekte güvenlik işlemlerinde zorunluluk olarak kaşımıza çıkacak. Şifrelerin bu kadar kolay ele geçirilebilmesi yada şifre denemeleri sayesinde şifrelerin bulunabilmesi her seferinde size başka şifre üreten sistemlerin doğmasına yol açtı. Bu sayede şifrenizi ele geçiren bir kişi dahi onu kullanamaz. Bunun için çeşitli yazılım yada fiziksel çözümler mevcut. Dakikada bir değişen şifreler yada her düğmeye bastığınızda size yeni bir şifre üreten tokenlar sayesinde şifrelerin çalınması yada başkaları tarafından bilinmesi problemi ortadan kalkıyor. Ve tokenların çoğundaki sistem bir PIN numarası ile korunuyor bu sayede tokenin kendisini kaybetmeniz durumunda dahi sistem kendini koruyabiliyor. Bir çoğu anahtarlık ve kredi kartı boyutlarında üretildiklerinden kolayca yanınızda taşıyıp istenilen yerden başka bir sisteme gerek kalmadan bağlantılarınızı güvenli bir şekilde yapabilirsiniz.

__________________

Yazar: | Kategori: Güvenlik
Yorum: 0

hijackthis, bir virüs ya da spy bulma programı değildir; sisteminizin o anki bir nevi röntgenini çeken bir programdır… sisteminizde o anda aktif olan herşeyi gösterir…
dolayısıyla yanlış bir silme sisteminizin tamamen çökmesine neden olabilir…

öncelikle
http://download.hijackthis.eu/hijackthis_199.zip
bu linkten hijackthis isimli programı indirip, bir klasöre çıkartın… daha sonra programı çalıştırıp DO A SYSTEM SCAN AND SAVE A LOG FILE yazan yere tıklayın… program kendisi bir tarama yapacak ve notepadde bir log dosyası açacaktır… daha sonra “hiçbirşeyi silmeden” log dosyasında yazan herşeyi copy/paste ile bu bölümde açacağınız topice yazın…

Hijackthis bir virüs ya da spy bulma programı değildir, eğer program hakkında bilgi sahibi değilseniz tek yapacağınız log dosyasında yazanları buraya yollamak arkadaşlar…

Neden Hijackthis…
hijackthis ile sisteminizde o anda aktif haldeki tüm girişler görülebilir… bu sayede eğer Antivirüs ya da antispy programlarınızla yaptığınız temizlik işlemleri sorununuzu çözmemişse sorunun kaynağı tespit edilip manuel bir şekilde olaya müdahale edilebilir… O yüzden ilk yapacağınız işlem, Antivirüs ve antispy programınızla temizlik yapmak olmalıdır arkadaşlar…

İstatistikler…
daha önce tek topicden ilerleme yapılıyordu; 4 ay içerisinde yaklaşık 150 kadar logla ilgili yorum yapıldı ve çok yüksek oranda, rakam vermek gerekirse sadece 1 log dışında tüm sistemler temizlendi…

-Nasıl Fixlerim?

Fixlenmesi gereken bölümdeki kutucuğu
işeretleyip resimde görülen fix checkede basmak yeterli

Yazar: | Kategori: Genel
Yorum: 0

CID SHIVERS

Port Numarası : 10520
Dosya Adı: “msgsvr16.exe”
Boyutu : 186 kb
Dizini: C:\Windows

Temizlemek için ;

Başlat-Çalıştır-regedit yazıp

*) HKEY_LOKAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\RunServices “Explorer | msgsvr16.exe”

*) HKEY_LOKAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\RunServices
“Explorervmsgsvr16.exe”

kayıtlarını silin ve

*) PC’nizi MS-DOS kipinde başlatın.

*) C:\Windows\msgsvr16.exe” dosyasını silin.

*) PC’ nizi yeniden başlatın.

BACK ORIFICE

Port Numarası: 31337
Dosya Adı: “.exe”
Boyutu: 126 kb
Dizini: C:\Windows\system

Temizlemek için ;

Başlat-Çalıştır-regedit yazıp

*) HKEY_LOKAL_MACHINE > Software > Microsoft > Windows > CurrentVersion > RunServices den
“.exe” kaydını silin.

*) PC’nizi yeniden başlatın.

*) Windows klasörünü açın .Görünüm >Klasör Seçenekleri menüsündeki Görünüm sekmesini açın ve Gizli Dosyalar bölümündeki “Tüm Dosyaları Göster” seçeneğinin işaretli olduğunu kontrol edin.

*) “C:\Windows\System\.exe” dosyasını silin.

*) PC’nizi yeniden başlatın.

BACKDOOR

Port Numarası: 1999
Dosya Adı: “icqnuke.exe”
Boyutu: 102 Kb
Dizini: C:\Windows, C:\Windows\system

Temizlemek için ;

Başlat > Çalıştır > regedit yazıp ;

*) HKEY_LOKAL_MACHINE > Software > Microsoft > Windows > CurrentVersion\Run
“icqnuke.exe.” kaydını silin.

*) PC’nizi Ms-Dos kipinde başlatın.

*) “C:\Windows\icqnuke.exe” ve “C:\Windows\System\icqnuke.exe” dosyalarını silin.

*) PC’nizi yeniden başlatın.

BIG GLUCK

Port Numarası: 34324
Dosya Adı: “bg10.exe”
Boyutu: 100 Kb
Dizini: C:\Windows, C:\Windows\system

Temizlemek için
;

Başlat > Çalıştır > regedit yazıp

*) HKEY_LOKAL_MACHINE > Software > Microsoft > Windows > CurrentVersion > RunServices
“bg10.exe.” kaydını silin.

*) PC’nizi Ms-Dos kipinde başlatın.

*) “C:\Windows\bg10.exe” ve “C:\Windows\System\bg10.exe” dosyalarını silin.

*) PC’nizi yeniden başlatın.

BRADE RUNNER

Port Numarası: 21,5400,5401,5402
Dosya Adı: “server.exe”
Boyutu: 323 Kb
Dizini: C:\Windows, C:\Windows\system

Temizlemek için ;

Başlat >Çalıştır > regedit yazıp ;

*) HKEY_LOKAL_MACHINE > Software > Microsoft > Windows > CurrentVersion > Run
“server.exe.” kaydını silin.

*) PC’nizi Ms-Dos kipinde başlatın.

*) “C:\Windows\server.exe” ve “C:\Windows\System\server.exe” dosyalarını silin.

*) PC’nizi yeniden başlatın.

BUGS

Port Numarası: 2115
Dosya Adı: “bugs.exe”
Boyutu: 78 Kb
Dizini: C:\Windows, C:\Windows\system

Temizlemek için ;

Başlat-Çalıştır-Regedit yazıp

*) HKEY_LOKAL_MACHINE > Software > Microsoft > Windows > CurrentVersion > Run
“bugs.exe.”
kaydını silin.

*) PC’nizi Ms-Dos kipinde başlatın.

*) “C:\Windows\bugs.exe” ve “C:\Windows\System\bugs.exe” dosyalarını silin.

*) PC’nizi yeniden başlatın.

DEEP BACK ORIFICE

Port Numarası: 31338
Dosya Adı: “.exe”
Boyutu: 122 Kb
Dizini: C:\Windows\system

Temizlemek için ;

Başlat-Çalıştır-Regedit yazıp

*)
HKEY_LOKAL_MACHINE > Software > Microsoft > Windows > CurrentVersion > RunServices
“.exe” kaydını silin

*) PC’nizi yeniden başlatın.

*)
Windows klasörünü açın.Görünüm Klasör Seçenekleri menüsündeki Görünüm sekmesini açın ve Gizli Dosyalar bölümündeki “Tüm Dosyaları Göster” seçeneğinin işaretli olduğununu kontrol edin.

*) “C:\Windows\System\.exe” dosyasını silin.

*) PC’nizi yeniden başlatın.

port 21 – Back Construction, Blade Runner, Doly Trojan, Fore, FTP trojan, Invisible FTP, Larva, WebEx, WinCrash
port 23 – Tiny Telnet Server (= TTS)
port 25 – Ajan, Antigen, Email Password Sender, Haebu Coceda (= Naebi), Happy 99, Kuang2, ProMail trojan, Shtrilitz, Stealth, Tapiras, Terminator, WinPC, WinSpy
port 31 – Agent 31, Hackers Paradise, Masters Paradise
port 41 – DeepThroat
port 59 – DMSetup
port 79 – Firehotcker
port 80 – Executor, RingZero
port 99 – Hidden Port
port 110 – ProMail trojan
port 113 – Kazimas
port 119 – Happy 99
port 121 – JammerKillah
port 421 – TCP Wrappers
port 456 – Hackers Paradise
port 531 – Rasmin
port 555 – Ini-Killer, NeTAdmin, Phase Zero, Stealth Spy
port 666 – Attack FTP, Back Construction, Cain & Abel, Satanz Backdoor, ServeU, Shadow Phyre
port 911 – Dark Shadow
port 999 – DeepThroat, WinSatan
port 1001 – Silencer, WebEx
port 1010 – Doly Trojan
port 1011 – Doly Trojan
port 1012 – Doly Trojan
port 1015 – Doly Trojan
port 1024 – NetSpy
port 1042 – Bla
port 1045 – Rasmin
port 1090 – Xtreme
port 1170 – Psyber Stream Server, Streaming Audio trojan, Voice
port 1234 – Ultors Trojan
port 1243 – BackDoor-G, SubSeven, SubSeven Apocalypse
port 1245 – VooDoo Doll
port 1269 – Mavericks Matrix
port 1349 – BO DLL
port 1492 – FTP99CMP
port 1509 – Psyber Streaming Server
port 1600 – Shivka-Burka
port 1807 – SpySender
port 1981 – Shockrave
port 1999 – BackDoor, TtansScout
port 2000 – TransScout
port 2001 – TransScout
port 2001 – Trojan Cow
port 2002 – TransScout
port 2003 – TransScout
port 2004 – TransScout
port 2005 – TransScout
port 2023 – Ripper
port 2115 – Bugs
port 2140 – Deep Throat, The Invasor
port 2155 – Illusion Mailer
port 2283 – HVL Rat5
port 2565 – Striker
port 2583 – WinCrash
port 2600 – Digital RootBeer
port 2801 – Phineas Phucker
port 2989 – RAT
port 3024 – WinCrash
port 3128 – RingZero
port 3129 – Masters Paradise
port 3150 – Deep Throat, The Invasor
port 3459 – Eclipse 2000
port 3700 – Portal of Doom
port 3791 – Eclypse
port 3801 – Eclypse
port 4092 – WinCrash
port 4321 – BoBo
port 4567 – File Nail
port 4590 – ICQTrojan
port 5000 – Bubbel, Back Door Setup, Sockets de Troie
port 5001 – Back Door Setup, Sockets de Troie
port 5011 – One of the Last Trojans (OOTLT)
port 5031 – NetMetro
port 5110 – Prorat
port 5321 – Firehotcker
port 5400 – Blade Runner, Back Construction
port 5401 – Blade Runner, Back Construction
port 5402 – Blade Runner, Back Construction
port 5550 – Xtcp
port 5512 – Illusion Mailer
port 5555 – ServeMe
port 5556 – BO Facil
port 5557 – BO Facil
port 5569 – Robo-Hack
port 5742 – WinCrash
port 6400 – The Thing
port 6669 – Vampyre
port 6670 – DeepThroat
port 6771 – DeepThroat
port 6776 – BackDoor-G, SubSeven
port 6912 – Shit Heep (not port 69123!)
port 6939 – Indoctrination
port 6969 – GateCrasher, Priority, IRC 3
port 6970 – GateCrasher
port 7000 – Remote Grab, Kazimas
port 7300 – NetMonitor
port 7301 – NetMonitor
port 7306 – NetMonitor
port 7307 – NetMonitor
port 7308 – NetMonitor
port 7789 – Back Door Setup, ICKiller
port 8080 – RingZero
port 9400 – InCommand
port 9872 – Portal of Doom
port 9873 – Portal of Doom
port 9874 – Portal of Doom
port 9875 – Portal of Doom
port 9876 – Cyber Attacker
port 9878 – TransScout
port 9989 – iNi-Killer
port 10067 – Portal of Doom
port 10101 – BrainSpy
port 10167 – Portal of Doom
port 10520 – Acid Shivers
port 10607 – Coma
port 11000 – Senna Spy
port 11223 – Progenic trojan
port 12076 – Gjamer
port 12223 – Hack«99 KeyLogger
port 12345 – GabanBus, NetBus, Pie Bill Gates, X-bill
port 12346 – GabanBus, NetBus, X-bill
port 12361 – Whack-a-mole
port 12362 – Whack-a-mole
port 12631 – WhackJob
port 13000 – Senna Spy
port 16969 – Priority
port 17300 – Kuang2 The Virus
port 20000 – Millennium
port 20001 – Millennium
port 20034 – NetBus 2 Pro
port 20203 – Logged
port 21544 – GirlFriend
port 22222 – Prosiak
port 23456 – Evil FTP, Ugly FTP, Whack Job
port 23476 – Donald Dick
port 23477 – Donald Dick
port 26274 – Delta Source
port 29891 – The Unexplained
port 30029AOL Trojan
port 30100 – NetSphere
port 30101 – NetSphere
port 30102 – NetSphere
port 30303 – Sockets de Troi
port 30999 – Kuang2
port 31336 – Bo Whack
port 31337 – Baron Night, BO client, BO2, Bo Facil, BackFire, Back Orifice, DeepBO
port 31338 – NetSpy DK ,Back Orifice, DeepBO
port 31339 – NetSpy DK
port 31666 – BOWhack
port 31785 – Hack«a«Tack
port 31787 – Hack«a«Tack
port 31788 – Hack«a«Tack
port 31789 – Hack«a«Tack
port 31791 – Hack«a«Tack
port 31792 – Hack«a«Tack
port 33333 – Prosiak
port 33911 – Spirit 2001a
port 34324 – BigGluck, TN
port 40412 – The Spy
port 40421 – Agent 40421, Masters Paradise
port 40422 – Masters Paradise
port 40423 – Masters Paradise
port 40426 – Masters Paradise
port 47262 – Delta Source
port 50505 – Sockets de Troie
port 50766 – Fore, Schwindler
port 53001 – Remote Windows Shutdown
port 54320 – Back Orifice 2000
port 54321 – School Bus, Back Orifice 2000
port 60000 – Deep Throat
port 61466 – Telecommando

Yukarı
Yazilar iin RSS aboneligi