Active Directory Sunucusu Kiralama ve Güvenli Mimari

Active Directory sunucusu kiralama, bir kurumun kullanıcı hesapları, bilgisayarların etki alanına katılımı, grup ilkeleri ve kimlik doğrulama hizmetlerini kiralık altyapıda çalıştırmayı planlamasıdır. Doğru mimari yalnızca Windows Server kurmak değildir: etki alanı denetleyicileri (Domain Controller/DC), DNS, replikasyon, güvenli şube erişimi, yedekleme ve yönetim sorumlulukları bir bütün olarak tasarlanmalıdır. Kimlik sistemi kesintisi, dosya paylaşımından ERP oturumlarına kadar birçok uygulamayı etkileyebilir.

Kısa cevap: Kurumun mevcut AD DS topolojisini ve bağımlılıklarını analiz edin; mümkünse farklı hata alanlarında çalışan en az iki uygun etki alanı denetleyicisi, doğru DNS istemci ayarları, erişimi sınırlandırılmış yönetim ağı ve AD DS uyumlu geri yükleme planı oluşturun. Tek DC, iki DC veya hibrit kurulum seçimi; kullanıcı ve lokasyon sayısına, ağ gecikmesine, işletme riskine, lisans koşullarına ve yazılı hizmet kapsamına göre belirlenmelidir. Active Directory ve dosya hizmetleri çözüm yaklaşımı bu teknik keşfin ilk adımıdır.

1. Active Directory kiralamada gerçekte hangi hizmet alınır?

Active Directory Domain Services (AD DS) kurumsal kullanıcı ve bilgisayar nesnelerini, güvenlik gruplarını, etki alanı ilkelerini ve bazı uygulamaların ihtiyaç duyduğu kimlik altyapısını yönetir. Etki alanı denetleyicisi ise AD DS veritabanını ve ilgili hizmetleri çalıştıran Windows Server rolüdür. Bir sunucunun uzaktan erişilebilir olması onun otomatik olarak güvenli, yedekli ve doğru yapılandırılmış bir etki alanı hizmeti sunduğu anlamına gelmez.

Kiralanan hizmetin sınırı açık yazılmalıdır: fiziksel veya sanal makine kaynağı mı veriliyor, Windows Server lisansı mı sağlanıyor, AD DS/DNS kurulumu mu yapılıyor, yoksa replikasyon, güvenlik, yedekleme ve olay yönetimi de üstleniliyor mu? Operasyon sorumlusu netleşmediğinde parola sorunları, DNS kesintileri veya başarısız yedeklerin kimin tarafından giderileceği belirsiz kalır.

Microsoft'un AD DS tasarım gereksinimleri mantıksal yapı, site topolojisi ve etki alanı denetleyicisi kapasitesinin birlikte planlanması gerektiğini açıklar. Bu nedenle hazır sunucu paketi satın almadan önce mevcut orman/etki alanı, kullanıcı, şube ve uygulama envanterini hazırlamak gerekir.

2. Tek Domain Controller yeterli mi, neden ikinci DC düşünülür?

Küçük bir test ortamında tek DC çalışabilir; ancak üretimde kimlik hizmetinin tek sunucuya bağımlı olması önemli bir kesinti riskidir. İşletim sistemi güncellemesi, host arızası, disk sorunu veya ağ erişimi kaybı sırasında kullanıcılar daha önce doğrulanmış oturumlarıyla bazı işlemlere devam edebilse bile yeni oturum açma, DNS keşfi ve başka etki alanı işlemleri etkilenebilir.

İki DC kullanıldığında veritabanı replikasyonu, DNS ve kimlik sorguları için başka bir seçenek bulunabilir. Bununla birlikte iki VM'yi aynı fiziksel hosta, aynı depolama alanına ve aynı güç yoluna koymak bütün hata alanlarını ortadan kaldırmaz. İş gereksinimlerine göre farklı host, ağ yolu ve gerekiyorsa farklı lokasyon seçilmelidir. İkinci DC de test edilmiş yedeğin yerine geçmez.

Birden fazla domain controller bulunan yapıda istemci DNS ayarlarının ve AD Sites and Services topolojisinin doğru olması gerekir. Yedekli tasarım; kapasite rezervi, yazılım bakımı, replikasyon sağlığı ve tutarlı yönetim prosedürleriyle tamamlanır.

3. VPS, dedicated veya özel bulut seçimi nasıl yapılmalı?

VPS veya bulut sunucu, uygun sanallaştırma altyapısında AD DS çalıştırmak isteyen ve kaynakları kademeli büyütmeyi planlayan kurumlar için bir seçenek olabilir. VPS ve bulut sunucu kiralama hizmetinde CPU/RAM tahsisi kadar depolama sürekliliği, yedek politikası, yönetim sınırı ve hypervisor özellikleri de sorgulanmalıdır.

Dedicated fiziksel sunucu, kaynak izolasyonu, özel donanım veya aynı host üzerinde birden fazla kontrollü iş yükü gerektiren kuruluşlarda değerlendirilebilir. Ancak dedicated sunucu kiralama seçmek, AD DS replikasyonunun veya yedeklemesinin kendiliğinden kurulduğu anlamına gelmez. Fiziksel sahiplik, bakım ve Windows Server lisanslama koşulları ayrı ele alınmalıdır.

Birden fazla şube, mevcut veri merkezi veya karma kimlik altyapısı bulunan şirketlerde özel bulut ve hibrit altyapı seçenekleri değerlendirilir. Kararı sunucu tipinin adından değil, kullanıcı erişim yolu ve kimlik hizmetinin kurumsal iş sürekliliği gereksiniminden başlatın.

4. DNS, domain adı ve AD Sites tasarımı neden kritik?

Active Directory istemcileri uygun etki alanı denetleyicisini bulmak için DNS kayıtlarından yararlanır. DNS yapılandırması hatalıysa kullanıcı tarafında zaman aşımı, etki alanına katılamama veya uygulama oturumunda gecikme görülebilir. Rastgele harici DNS adresi vermek, AD DS'nin ihtiyaç duyduğu kayıtların bulunmasını engelleyebilir.

Microsoft'un DNS ve AD DS teknik açıklaması DNS'in DC keşfi ve denetleyiciler arası iletişimdeki rolünü açıklar. Tasarımda AD ile bütünleşik DNS bölgeleri, uygun yönlendirme (forwarder), istemci DNS sırası ve kayıtların güncelliği kontrol edilmelidir. Mevcut kurumsal DNS yapısıyla çakışan ikinci bir adlandırma düzeni kurulmadan önce etki analizi yapılmalıdır.

Şubeler farklı lokasyonlardaysa AD Sites and Services üzerinde subnet, site bağlantısı ve replikasyon maliyetleri planlanır. Microsoft'un site topolojisi rehberi, istemci sorgularının ve replikasyon trafiğinin doğru yönlendirilmesinde bu tasarımın önemini belirtir.

5. Şubelerden ve uzaktan çalışanlardan erişim nasıl korunmalı?

Domain controller yönetim portlarını doğrudan genel internete açmak, kiralık sunucuyu uzaktan kullanılabilir kılmanın doğru yöntemi değildir. Şubelerle veri merkezi arasında yetkilendirilmiş site-to-site VPN veya kurumsal ağ bağlantısı, yönetim ekipleri için ayrı erişim yolu, çok faktörlü kimlik doğrulama ve firewall politikaları planlanmalıdır.

Uygulama kullanıcılarının erişim yetkisi ile domain admin yetkisi aynı olmamalıdır. Güvenlik grupları ve yönetim rolleri en az ayrıcalık ilkesiyle düzenlenmeli; ayrıcalıklı hesaplar normal günlük işlemlerde kullanılmamalıdır. Yönetim erişimi günlükleri, parola sıfırlama süreçleri, bakım pencereleri ve acil durum iletişim bilgileri belgelenmelidir.

Ağ güvenliği, firewall ve VPN hizmetleri bu mimarinin ayrı bir hizmet katmanı olarak değerlendirilmesini sağlar. Farklı şubelerin bağlantı kalitesi kötü olduğunda bütün sorunların Windows Server kaynak artırımıyla düzelmeyeceğini unutmayın.

6. Windows Server CPU, RAM, disk ve lisans ihtiyacı

AD DS boyutlandırmasında kullanıcı, bilgisayar, grup, oturum açma sıklığı, GPO büyüklüğü, global catalog rolü, DNS yükü ve diğer servisler hesaba katılır. Tek bir sabit vCPU/RAM paketi her kurum için doğru değildir. Yoğun dosya paylaşımı veya uygulama barındırma yükünü aynı DC üzerine eklemek hem kapasiteyi hem güvenlik sınırlarını karmaşıklaştırabilir.

Disk kapasitesi yanında sistem ve AD veritabanı işlemleri için gerçek depolama gecikmesi, güvenli güncelleme alanı, boş kapasite ve yedekleme süresi incelenmelidir. İşletim sistemi ile AD DS sunucusunun güvenlik bakımının aynı sahibi olması da açıkça belirlenmelidir.

Windows Server lisansı, sanallaştırma hakları ve gerektiğinde erişim lisansları (CAL), kiralanan hizmetin ticari kapsamına göre değerlendirilir. “Proxmox/VMware üzerinde VM oluşturmak” Windows lisans yükümlülüğünü otomatik olarak ortadan kaldırmaz. Nihai lisans koşullarını güncel Microsoft sözleşmesi ve yetkili lisans kanalıyla doğrulayın.

7. Sanal DC yedekleme, snapshot ve VM-Generation ID

Sanal bir domain controller için snapshot almak kolaydır; ancak snapshot tek başına Active Directory yedekleme stratejisi değildir. Yanlış disk veya VM geri dönüşü, replikasyon tutarlılığına zarar verebilir. Microsoft'un sanal domain controller güvenlik açıklaması VM-Generation ID desteğini, güvenli geri dönüş koşullarını ve sınırlarını detaylandırır.

AD DS uyumlu sistem durumu (system state) yedeklemesi, uygun yedekleme yazılımı ve ayrı koruma alanı düşünülmelidir. Yedekler sadece alınmamalı; seçilen kurtarma senaryosu için geri yüklenebilirliği ve uygulama bağımlılıkları test edilmelidir. Özellikle bütün DC'lerin aynı anda eski snapshot'a döndürülmesi tehlikeli olabilir.

Kurumun veri kaybı hedefi (RPO), geri dönüş süresi (RTO), saklama ve erişim yetkileri ölçülebilir biçimde belirlenmelidir. Yedekleme ve felaket kurtarma hizmetleri teklif edilirken system state, AD veritabanı, DNS ve SYSVOL geri kazanım adımlarının gerçekten dahil olup olmadığı sorulmalıdır.

8. Mevcut Active Directory yeni sunucuya nasıl taşınır?

Var olan bir etki alanını yeni kiralık sunucuya taşırken genellikle güvenli yaklaşım; yeni sunucuyu mevcut etki alanına eklemek, uygun koşullarda ek DC olarak yükseltmek, DNS ve replikasyon sağlığını sınamak, ardından gerekli roller ve istemci bağımlılıklarını planlı biçimde değiştirmektir. Bu akış her ortama uygulanacak otomatik bir komut listesi değildir.

Önce mevcut forest/domain functional level, Windows Server sürümleri, DNS bölgeleri, FSMO rol sahipleri, global catalog, NTP/zaman kaynağı, GPO ve SYSVOL durumu envantere alınmalıdır. Replikasyon hataları varsa yenisini eklemek sorunu çözmeyebilir; önce nedenleri giderilmelidir. Ayrıca DHCP seçenekleri, uygulamaların sabit DC IP'sine bağımlılığı ve eski DC'nin sertifika hizmeti gibi ek roller taşıyıp taşımadığı araştırılmalıdır.

Test ortamında devreye alınan yeni DC üzerinden oturum açma, grup ilkesi, dosya erişimi ve iş uygulaması girişleri doğrulanmalı; dcdiag ve repadmin gibi araçların sonuçları operasyon kaydına alınmalıdır. Eski DC kaldırılmadan önce replikasyon, DNS, rol aktarımı, yedekleme ve geri dönüş koşulları tamamlanmalıdır.

9. Microsoft 365 ve hibrit kimlik entegrasyonu

Kuruluşun Microsoft 365 kullanması, her senaryoda şirket içi Active Directory'den vazgeçilmesi gerektiği anlamına gelmez. Bazı uygulamalar Kerberos/LDAP, GPO veya geleneksel dosya ve etki alanı ilişkilerini kullanmaya devam eder. Buna karşılık yalnız bulut tabanlı kimliğe uygun yeni uygulamalarda farklı mimariler değerlendirilebilir.

Microsoft Entra ID ile AD DS'nin aynı servis olmadığı bilinmelidir. Hibrit kimlik senkronizasyonu planında kullanıcı kimliği eşleşmesi, UPN, parola/kimlik doğrulama yöntemi, güvenli bağlantı ve geri dönüş senaryosu birlikte ele alınmalıdır. Ayrı tenant ya da birden fazla forest bulunan kurumlarda ek uyumluluk ve yetki planlaması gerekebilir.

Daha kapsamlı mimari için özel bulut ve hibrit çözüm seçenekleri üzerinde uygulama bağımlılıklarını ve güvenli erişim ihtiyacını karşılaştırabilirsiniz. Entra ID senkronizasyonunu yalnız bir bağlantı ayarı gibi görmek, kullanıcı yaşam döngüsü ve güvenlik risklerini gözden kaçırabilir.

10. Yönetilen Active Directory hizmetinde sorumluluk matrisi

“Kiralık Active Directory” teklifinde DC'lerin kim tarafından kurulduğu, sistem yamalarının ne zaman uygulandığı, replikasyon alarmlarını kimin izlediği, DNS değişikliklerinin kimden onay aldığı ve yedek geri yükleme testlerini kimin gerçekleştirdiği ayrı ayrı yazılmalıdır. Bir altyapı sunucusunun açık kalması, AD DS'nin bütün fonksiyonlarının sağlıklı olduğu anlamına gelmez.

Yönetim sözleşmesinde olay önceliği, izleme ölçütleri, bakım pencereleri, log saklama, yetkili erişim, lisans, müşteri sorumlulukları ve destek iletişim kanalları olmalıdır. Doğrudan uygulama kaynaklı hataların da bu kapsamda olup olmadığı belirtilmelidir.

Yönetilen sunucu hizmetleri incelenirken yalnız genel “7/24 destek” ifadesine dayanmayın; hangi denetimin otomatik çalıştığını, hangi işlemin talep üzerine yapıldığını ve SLA koşullarının neyi kapsadığını netleştirin. Kesinti, yedekleme veya müdahale garantisi ancak doğrulanmış teklifle ifade edilmelidir.

11. Active Directory sunucu kiralama teklifinde bulunması gerekenler

Aşağıdaki tablo, satın alma ve BT ekiplerinin teklifleri karşılaştırmak için kullanabileceği bir başlangıç kontrol listesidir. Gereksinimleri ilk keşifte değerlendirin; gerçek donanım ve hizmet kapasitesi ölçülmeden kesin sonuç yazmayın.

Bir şirket için iki DC ve düşük gecikmeli erişim kritik olabilirken, farklı bir kuruluş için aynı öncelik ağır ERP sorguları veya uzak şube bağlantısında olabilir. Sunucu fiyatını karşılaştırırken sözleşmede yer almayan yedekleme, lisans veya yönetim özelliğini var saymayın.

Sık sorulan sorular

1. Active Directory sunucusu bulutta veya kiralık VPS üzerinde çalışabilir mi?

Evet, uygun Windows Server ve desteklenen sanallaştırma altyapısında AD DS çalıştırılabilir. Ancak hypervisor özellikleri, DNS, güvenli ağ bağlantısı, replikasyon, sistem durumu yedeği ve lisans koşulları doğrulanmalıdır. Her VPS paketi yönetilen Active Directory hizmeti sunmaz.

2. Domain Controller için ikinci sunucu zorunlu mudur?

Her ortam için tek bir kesin sayı yoktur. Yine de kimlik hizmetinin iş açısından kritik olduğu üretim ortamlarında birden çok uygun DC, tek sunucu kesintisinin etkisini azaltabilir. Bu DC'lerin aynı hata alanına bağımlı olmaması da önemlidir.

3. Şube kullanıcıları etki alanına VPN olmadan bağlanabilir mi?

Kimlik hizmetini genel internete doğrudan açmak güvenli bir standart yaklaşım değildir. Şube bağlantısı için kurumsal WAN veya uygun VPN, uzaktan çalışanlar içinse uygulamaya ve güvenlik modeline uygun kontrollü erişim yöntemi tasarlanmalıdır.

4. AD DS yedeği için sadece sanal makine snapshot'ı yeterli mi?

Hayır. Snapshot geri dönüşü, AD DS veritabanı ve replikasyon sağlığı açısından özel riskler taşır. VM-Generation ID korumaları belirli durumlarda yardımcı olsa da AD DS uyumlu sistem durumu yedeği ve test edilmiş kurtarma planının yerini tutmaz.

5. Active Directory ile Microsoft Entra ID aynı şey midir?

Hayır. AD DS geleneksel domain controller, LDAP/Kerberos ve GPO gibi yetenekler sunarken Microsoft Entra ID farklı bir bulut kimlik hizmetidir. Kurumlar ihtiyaçlarına göre yalnız bulut veya hibrit mimari kullanabilir; uygulama bağımlılıkları önceden incelenmelidir.

6. Active Directory taşınırken kullanıcı hesapları ve GPO'lar korunabilir mi?

Mevcut etki alanına uygun bir ek DC kurulup sağlıklı replikasyon sağlanıyorsa kullanıcı, grup, GPO ve diğer dizin bileşenleri planlı geçişle korunabilir. Ancak bütün ortamlar aynı değildir; DNS, SYSVOL, FSMO rolleri ve uygulama bağımlılıkları test edilmelidir.

7. Active Directory sunucusu kiralama fiyatı neye göre değişir?

DC sayısı, fiziksel veya sanal kaynaklar, Windows Server lisansı, ağ/VPN, yedekleme, bakım, izleme, ayrı lokasyon ve geçiş hizmetlerinin kapsamı maliyeti etkiler. Güncel teklifi şirketin gerçek ihtiyaçlarına göre karşılaştırmak gerekir.

Active Directory altyapınızı ölçerek teklif oluşturun

Kiralık etki alanı denetleyicisi seçimini yalnız vCPU/RAM tablosuyla yapmayın. Mevcut DC sayısını, kullanıcı ve şubeleri, DNS bağımlılıklarını, güvenli bağlantı koşullarını, yedek durumunu ve hedef bakım modelini paylaşın. Böylece iş sürekliliği risklerini ve operasyon sorumluluklarını baştan netleştiren bir mimari oluşturulabilir.

Netsun Bilişim'in sunabileceği altyapı ve yönetim kapsamı, keşif ve yazılı teklif sonrasında kesinleşir; bu rehber herhangi bir sayısal SLA veya hazır kapasite garantisi vermez. Active Directory sunucusu kiralama için teknik ihtiyaçlarınızı iletip teklif alın.