Microsoft Cloud Danışmanlığı

Azure Danışmanlığı mı, Microsoft 365 Danışmanlığı mı — Yoksa İkisi mi?

Kurumlar hizmet ararken çoğu zaman iki ayrı kapıdan girer: kimi 'Azure danışmanlığı', kimi 'Microsoft 365 danışmanlığı' arar. Bu iki başlık farklı ihtiyaçları işaret eder. Azure danışmanlığı ağırlıklı olarak altyapı tarafını kapsar — sanal makineler, ağ, veritabanı, PaaS servisleri ve bulut göçü. Microsoft 365 danışmanlığı ise üretkenlik ve işbirliği katmanıyla ilgilenir: Exchange, Teams, SharePoint ve OneDrive. Hangisine ihtiyaç duyduğunuz, öncelikli sorununuzun nerede olduğuna bağlıdır; bir BT yöneticisi 'önce hangisini çözmeliyim' diye sorduğunda yanıt teknoloji tercihinden çok iş önceliğiyle şekillenir.

Ayrım net görünse de pratikte iki ekosistem ortak bir omurgayı paylaşır. Yalnızca bir veri merkezini buluta taşıyorsanız Azure ekseninde, yalnızca e-posta ve işbirliği ortamınızı modernleştiriyorsanız Microsoft 365 ekseninde ilerlemek yeterli olabilir. Ancak kimlik (Entra ID), güvenlik (Defender ve Purview) ve lisans (Enterprise Agreement) her iki tarafı da aynı anda ilgilendirir. Bu üç katmanı iki ayrı danışmanlık silosunda ele almak, aralarında politika boşlukları ve maliyet körlükleri doğuran dikişler bırakır.

Karar verirken üç soruyu netleştirmek yol gösterir: birincil dönüşüm ekseniniz altyapı mı yoksa üretkenlik mi; kimlik ve güvenlik duruşunuz her iki tarafta da olgun mu; ve yaklaşan bir EA yenilemesi bütünsel bir bakışı gerekli kılıyor mu? Bu sorular çoğu zaman tek bir ekosistemin sınırlarını aştığınızı gösterir.

Aşağıdaki tablo, aynı ihtiyaçların ayrı ayrı ve birleşik yönetildiğinde nasıl farklılaştığını somut boyutlarda karşılaştırır. Görüldüğü gibi tek eksenli ihtiyaçlarda tekil bir danışmanlık kapsamı mantıklıdır; kimlik, güvenlik ve maliyetin iç içe geçtiği kurumlarda ise 'ikisi birden' sorusunun cevabı çoğunlukla birleşik Microsoft Cloud yaklaşımıdır.

Birleşik Kimlik ve Güvenlik Neden Tek Elden Yönetilir

Microsoft Entra ID, Azure ile Microsoft 365'i birbirine bağlayan ortak omurgadır. Bir kullanıcı Azure portalına da, Exchange posta kutusuna da, bir SharePoint sitesine de aynı kimlik düzlemi üzerinden erişir. Kimlik iki ayrı ekip tarafından yönetildiğinde politika kayması (policy drift) kaçınılmaz hale gelir: Microsoft 365 e-postası için sıkılaştırılan bir koşullu erişim kuralı, Azure yönetim düzlemini kapsamayabilir ve geride sessiz bir açık bırakır. Kimliğin tek elden yönetilmesi, hem altyapı hem üretkenlik tarafını aynı tutarlı politika yüzeyiyle koruma altına alır.

Güvenlik tarafında tehditler Azure ile Microsoft 365 sınırını tanımaz. Oltalama (phishing) yoluyla ele geçirilen bir Microsoft 365 kimliği, aynı kullanıcının Azure kaynaklarına doğru yanal harekete zemin hazırlayabilir. Microsoft Defender XDR kimlik, uç nokta, e-posta ve bulut sinyallerini ilişkilendirir; Sentinel bunları tek bir SIEM çatısında toplar. Bu bileşenleri tek bir yol haritasında ele almak, iki kopuk müdahale kitabı yerine tek bir tespit ve yanıt sürecini mümkün kılar. Ayrıcalıklı erişim de (PIM) tek noktadan yönetildiğinde etki alanı (blast radius) öngörülebilir biçimde daralır.

Bu bütünlüğün pratikteki karşılığını Kurumsal Bankacılık Hibrit Bulut Göçü vaka çalışmasında görmek mümkündür: hibrit kimlik Entra ID ve Connect ile kurulmuş, koşullu erişim politikaları kademeli olarak uygulanmıştır. Tek bir kimlik düzlemi hem altyapı göçünü hem erişim yönetişimini aynı zemine oturttuğu için, güvenlik kararları parça parça değil bütünsel alınabilmiştir.

Aynı mantık uyumluluk için de geçerlidir. KVKK ve GDPR kontrolleri iki ekosistem için ayrı çerçevelerde yürütüldüğünde denetim tekrar eder ve dikişlerde boşluk kalır. Kimlik, güvenlik ve veri yönetişimi tek bir kontrol çerçevesinde toplandığında, hem denetim yükü azalır hem de her iki ortam için tutarlı bir uyumluluk duruşu sağlanır.

Örnek Bir Microsoft Cloud Yol Haritası

Somut bir örnek üzerinden ilerleyelim. Diyelim ki bir kurum hem yaşlanan bir veri merkezine hem de dağınık, kısmen şirket içinde barındırılan bir e-posta ve işbirliği ortamına sahip. Birleşik bir yol haritası, işe her iki tarafı da tek bir olgunluk fotoğrafında toplayarak başlar: Azure kullanımı, Microsoft 365 lisans portföyü, kimlik mimarisi ve güvenlik duruşu tek bir raporda yan yana konur ve girişimler iş önceliğine göre sıralanır.

İlk adım genellikle ortak zemini kurmaktır: Entra Connect ile hibrit kimlik, çok faktörlü kimlik doğrulama ve koşullu erişim, her iki dönüşüm hattının da ön koşulu olarak devreye alınır. Ardından iki hat paralel ilerler — bir yanda Exchange ve Teams iş yükleri dalgalar hâlinde Microsoft 365'e taşınırken, diğer yanda Azure landing zone Cloud Adoption Framework prensipleriyle ayağa kalkar. Birleşik güvenlik (Defender ve Sentinel) erken açılır, böylece her iki hat da ilk günden itibaren aynı gözetim panosundan izlenir. FinOps baz çizgisi ise EA yenilemesinden önce alınır, çünkü lisans ve tüketim kararları o pencerede en yüksek kaldıracı taşır.

Bu akış yalnızca örnektir; gerçek yol haritası kurumun ölçeğine, uyumluluk kapsamına ve mevcut olgunluğuna göre ölçeklenir. Süre ve tasarruf değerleri birer hedeftir ve gerçekleşen sonuç kullanım verileriyle doğrulanır. Tipik olarak 12-24 aya yayılan bu aşamalı ilerleme, her dalga sonunda ölçülebilir iş değeri üretecek ve aylık FinOps ile güvenlik inceleme döngüsüyle kalıcı hale gelecek biçimde tasarlanır.