Office 365 URL ve IP Adresleri

Kurumsal Microsoft 365 projelerinde özellikle güvenlik duvarı, proxy veya internet çıkış politikaları sıkı olan şirketlerde en çok karşılaştığım sorulardan biri hangi URL ve IP adreslerine izin verilmesi gerektiği. Exchange Online, Microsoft Teams, SharePoint Online veya OneDrive bağlantılarında yaşanan sorunların arkasında bazen eksik bir ağ kuralı bulunabiliyor.

Soru: Microsoft 365 erişim sorunlarını çözmek için gerekli URL ve IP adreslerinin güncel listesine nereden ulaşabilirim?

Cevap: Microsoft bu bilgileri hem çevrimiçi doküman olarak hem de otomasyona uygun bir web servisi aracılığıyla yayımlıyor. Eskiden burada Office 365 için tek bir destek makalesine bağlantı veriyordum. Ancak Microsoft 365 hizmetleri sürekli geliştiği için artık sabit bir IP listesini kopyalamak yerine güncel endpoint verisini takip etmek daha doğru.

Microsoft 365 URL ve IP adreslerinin güncel listesi

Microsoft 365 servisleri için gerekli adresler, Microsoft 365 URLs and IP address ranges sayfasında servis alanlarına göre listeleniyor. Exchange Online, SharePoint Online ve OneDrive, Microsoft Teams ve ortak Microsoft 365 bileşenlerinin ihtiyaç duyduğu FQDN, IP aralığı ve port bilgilerini buradan görebilirsiniz.

Bu listede gördüğünüz adreslerin tamamını tek bir statik firewall kuralına dönüştürmek iyi bir yaklaşım değil. Öncelikle hangi Microsoft 365 bulut ortamını kullandığınızı, trafiğin hangi cihazdan çıktığını ve hangi servislerin gerekli olduğunu belirlemek gerekiyor. Ayrıca bazı servisler ortak endpoint’leri kullandığından yalnızca tek bir ürünün adreslerini açmak her senaryoda yeterli olmayabilir.

Optimize, Allow ve Default ne anlama geliyor?

Microsoft, endpoint’leri bağlantı gereksinimleri açısından üç kategoriye ayırıyor:

• Optimize: Gecikmeye ve ağ üzerindeki ek işlem yüküne hassas, performans açısından öncelikli bağlantılar. Uygun mimarilerde doğrudan ve en kısa yoldan internet çıkışı önem taşıyor.
• Allow: Microsoft 365 servislerinin çalışması için gerekli olan ve belirli ağ optimizasyonlarından yararlanabilen diğer bağlantılar.
• Default: Genel internet erişim modeline daha yakın şekilde değerlendirilen Microsoft 365 bağımlılıkları. Bu kategoride de gerekli endpoint’ler bulunabiliyor.

Özellikle Teams toplantı trafiğini tümüyle merkezi bir proxy üzerinden dolaştırmak ile uygun şekilde doğrudan internet çıkışına yönlendirmek arasında kullanıcı deneyimi açısından ciddi fark oluşabiliyor. Burada güvenlik politikasından vazgeçmek yerine Microsoft’un kategori ve ağ optimizasyonu önerilerine göre tasarım yapmak gerekiyor.

PowerShell ile güncel Microsoft 365 endpoint listesini almak

Çok sayıda şube, firewall veya proxy yöneten kurumlarda web sayfasından IP adreslerini tek tek kopyalamak sürdürülebilir değil. Microsoft’un endpoints.office.com servisi üzerinden güncel veri JSON formatında alınabiliyor. Aşağıdaki örnek yalnızca veriyi sorgular, mevcut güvenlik duvarı kurallarını değiştirmez:

$requestId = [guid]::NewGuid().ToString()
$uri = "https://endpoints.office.com/endpoints/worldwide?clientrequestid=$requestId"
$endpoints = Invoke-RestMethod -Uri $uri -Method Get

$endpoints |
    Select-Object id, serviceArea, category, required, tcpPorts, udpPorts |
    Format-Table -AutoSize

Belirli bir servis alanının kayıtlarını incelemek için elde ettiğimiz sonuçları filtreleyebiliriz. Örneğin Exchange Online:

$endpoints |
    Where-Object { $_.serviceArea -eq 'Exchange' } |
    Select-Object id, category, required, urls, ips, tcpPorts

Bu çıktıdaki ips ve urls alanları dizi olabilir. Ağ cihazına otomatik kural yazacak bir çözüm geliştiriyorsanız CIDR, FQDN, joker karakter, port ve gerekli/isteğe bağlı endpoint ayrımını doğru işlemeniz gerekir. Yalnızca IP adresleriyle kural yazmak, FQDN tabanlı gereksinimleri tek başına karşılamaz.

IP adresleri değişirse nasıl takip edeceğiz?

Microsoft 365 endpoint verisi zaman içinde değişiyor. Bu nedenle üretim ortamında bir kez oluşturulmuş adres listesinin yıllarca güncel kalacağını varsayamayız. Web servisinin sürüm sorgusu ile yeni endpoint sürümleri takip edilebilir. Değişiklikleri önce test ortamında değerlendirip ardından güvenlik duvarı veya proxy kurallarına kontrollü biçimde aktarmak daha doğru olur.

$requestId = [guid]::NewGuid().ToString()
$versionUri = "https://endpoints.office.com/version/worldwide?clientrequestid=$requestId"
Invoke-RestMethod -Uri $versionUri -Method Get

Önemli: Buradaki worldwide ticari Microsoft 365 bulut ortamını ifade ediyor. GCC High, DoD veya 21Vianet gibi farklı bulut örneklerinde uygun instance seçilmelidir. Ayrıca kullanıcı cihazından Microsoft 365’e yapılan çıkış trafiğinin listesi, hibrit sistemlerde Microsoft tarafından kurum ağınıza gelen bütün bağlantıların eksiksiz listesi anlamına gelmez.

Bağlantı sorunu yaşandığında nelere bakıyorum?

Bir kullanıcının Outlook bağlantısı çalışmadığında veya Teams görüşmesinde sorun yaşadığında kontrolü yalnızca açık portlarla sınırlamıyorum. DNS çözümlemesi, proxy kimlik doğrulaması, TLS incelemesi, istemcinin internete çıktığı nokta, ağ cihazındaki FQDN politikaları ve Microsoft 365 endpoint kategorileri birlikte incelenmeli. Örneğin PowerShell ile TCP 443 bağlantısının başarılı olması, kullanıcı oturumunun ve ilgili servisin uçtan uca sağlıklı çalıştığını tek başına kanıtlamaz.

Özetle kurumsal Microsoft 365 erişimi için tek seferlik bir IP listesi değil, değişiklikleri takip edilen bir ağ politikası gerekiyor. Özellikle birden çok lokasyon veya farklı güvenlik duvarı üreticisi bulunan ortamlarda endpoint verisini otomatik almak ve değişiklikleri kontrollü uygulamak yönetimi ciddi ölçüde kolaylaştırıyor.