Microsoft Sentinel'den Defender Portal'a Geçiş Rehberi (2026)

Özet (TL;DR): Microsoft, Azure portal üzerindeki Microsoft Sentinel deneyimini kapatıyor. Önce 1 Temmuz 2026 olarak açıklanan tarih, Ocak 2026'da 31 Mart 2027'ye ertelendi — ama son tarih değil, yalnızca ek süre. Bu tarihten sonra Sentinel yalnızca Microsoft Defender portalında (security.microsoft.com) çalışacak. Geçiş; ek lisans maliyeti getirmiyor, ama Fusion kuralının devre dışı kalması, otomasyon kurallarının tetiklenme mantığının değişmesi, API alan adlarının (`providerName`, `incidentUrl`) farklılaşması ve veri saklama/gizlilik politikalarının Microsoft Defender XDR kurallarına geçmesi gibi somut etkiler doğuruyor. Bu rehberde ön koşulları, adım adım bağlama sürecini, KVKK açısından dikkat edilmesi gerekenleri ve geçiş sonrası SOC ekibinin karşılaşacağı yaygın sürprizleri anlatıyoruz.

Xen Bilişim ekibi · Microsoft CSP Direct Partner (2016+) · MS-100/MS-102/AZ-104 sertifikalı danışmanlar

Neden Şimdi? Azure Portal'da Sentinel'in Sonu Geliyor

Microsoft, Temmuz 2025'te Microsoft Sentinel'in Azure portalındaki deneyimini Temmuz 2026 itibarıyla emekliye ayıracağını duyurmuştu. Ocak 2026'da bu tarih müşteri ve iş ortağı geri bildirimleri üzerine 31 Mart 2027'ye uzatıldı (Microsoft Learn — What's new for unified security operations, Ocak 2026). Erteleme "iptal" anlamına gelmiyor — planlama için ek 9 ay kazanıldı, o kadar.

Bu değişikliğin arka planı: Microsoft, Sentinel'i (SIEM) ve Defender XDR'ı (uç nokta/kimlik/bulut tehdit tespiti) tek bir portalda birleştiriyor. Amaç, analistlerin SIEM ve XDR arasında sekme değiştirmeden tek bir olay kuyruğunda çalışmasını sağlamak. 1 Temmuz 2025'ten sonra Microsoft Sentinel'e ilk kez kaydolan ve Sahip (Owner) veya Kullanıcı Erişim Yöneticisi (User Access Administrator) rolüne sahip yeni müşteriler zaten otomatik olarak Defender portalına yönlendiriliyor (kaynak). Mevcut, Azure portalında çalışan kurumlar içinse geçiş manuel ve planlı olmalı.

Tarih	Olay
1 Temmuz 2025	Yeni Sentinel müşterileri (uygun rol koşullarıyla) otomatik Defender portalına onboard ediliyor
Temmuz 2026 (eski tarih)	İlk açıklanan retirement tarihi — artık geçerli değil
31 Mart 2027	Azure portalında Sentinel desteğinin kesin sona erme tarihi (Ocak 2026 güncellemesi)

Kurumunuz hâlâ Azure portalında SOC operasyonu yürütüyorsa, 2027 başına kadar "bir gün yaparız" diye ertelemek riskli — geçiş, otomasyon kurallarının yeniden test edilmesini, analist eğitimini ve entegrasyon (ServiceNow, SOAR playbook) doğrulamasını gerektiriyor; bunlar bir haftasonu tatili işi değil. Xen Bilişim'den ücretsiz Sentinel geçiş değerlendirmesi isteyin — mevcut ortamınızı 30 dakikalık bir görüşmede haritalandıralım.

Ön Gereksinimler: Lisans, Rol ve İzinler

İyi haber: Defender portalına geçiş için ek lisans maliyeti yok. Microsoft Defender XDR veya E5 lisansınız olmasa bile Sentinel'i Defender portalında kullanabilirsiniz; tüketiminiz yalnızca mevcut Sentinel faturalandırmanız üzerinden devam eder (Microsoft Learn — Transition to the Defender portal).

Tek workspace'li kurulum için gereken roller:

• Workspace'i Defender portalına bağlama: Microsoft Entra ID'de en az Güvenlik Yöneticisi (Security Administrator) rolü VEYA Azure'da abonelik düzeyinde koşulsuz Sahip (Owner) rolü VEYA Kullanıcı Erişim Yöneticisi + Microsoft Sentinel Katkıda Bulunan (Contributor) kombinasyonu.
• Defender portalında Sentinel'i görüntüleme: Microsoft Sentinel Reader.
• Olaylarda araştırma işlemi yapma: Microsoft Sentinel Contributor.
• Destek talebi açma: Owner, Contributor veya Support Request Contributor.

Kritik nokta: Owner rolü atamasının "koşulsuz" (unconditional) olması gerekiyor — yani "Allow user to assign all roles (highly privileged)" seçeneği işaretli olmalı, "yalnızca seçili rolleri ata" gibi kısıtlı bir koşul rolü yeterli değil.

Birden fazla workspace'iniz varsa (örneğin bölge/şirket bazlı ayrılmış workspace'ler), yukarıdaki tabloya ek olarak Microsoft Entra ID'de en az Güvenlik Yöneticisi rolüne de sahip olmanız gerekiyor. Defender XDR ile birleşik operasyon (unified security operations) çalıştıracaksanız ayrıca Defender XDR lisans ön koşullarını ve aynı Microsoft Entra kiracısında olma şartını da karşılamanız gerekir.

Adım Adım Geçiş: Sentinel'i Defender Portal'a Bağlama

Ön koşullar tamamsa, tek workspace için bağlama işlemi 10 dakikadan kısa sürüyor:

1. Defender portalına giriş yapın: security.microsoft.com adresine gidin.
2. Ayarlar menüsüne gidin: Sol menüde System > Settings > Microsoft Sentinel yolunu izleyin.
3. "Connect a workspace" seçeneğine tıklayın.
4. Bağlamak istediğiniz workspace'i(leri) seçin ve İleri'ye tıklayın.
5. Birincil (Primary) workspace'i belirleyin. Birden fazla workspace bağlıyorsanız yalnızca biri "primary" olabilir — Defender XDR verisi yalnızca primary workspace ile ilişkilendirilir.
6. Ürün değişikliklerini okuyun ve onaylayın — bu ekranda Fusion kuralının devre dışı kalacağı, alert yönlendirmesinin değişeceği gibi uyarılar listelenir.
7. "Connect" düğmesine tıklayın.

Bağlantı tamamlandığında Defender portalının Ana Sayfa (Home) ekranında ortamınızın hazır olduğunu belirten bir banner görünür; veri konnektörü ve otomasyon kuralı sayıları gibi metrikler de Home sayfasına eklenir (Microsoft Learn — Connect Microsoft Sentinel to the Defender portal). Defender XDR entegrasyonu varsa Microsoft Defender bağlayıcısının tam senkronize olması ve olayların Sentinel'e yansıması 5 dakikaya kadar sürebilir; bu süre boyunca playbook tetiklemeleri de gecikebilir.

Geçiş Sonrası Ne Değişiyor? SOC Ekibinin Bilmesi Gerekenler

Mimari olarak veri hâlâ Azure üzerindeki Log Analytics workspace'inde tutuluyor; Sentinel'in arka ucu değişmiyor, yalnızca ön yüz (deneyim) birleşiyor. Ama pratikte analistlerin günlük işini etkileyen birkaç somut değişiklik var:

• Fusion kuralı devre dışı kalır. Azure portalındaki çok aşamalı saldırı tespiti yapan Fusion analitik kuralı, Defender portalına onboard olduğunuzda otomatik kapanır. Korelasyon işlevini kaybetmezsiniz — Defender XDR'ın kendi korelasyon motoru aynı işi üstlenir, ama kural adları ve davranışı farklıdır; SOC ekibinizin bunu bilmesi gerekir.
• Alert yönlendirmesi değişir. Microsoft güvenlik ürünlerinden (Defender for Endpoint, Defender for Identity, Defender for Cloud Apps, Defender for Office 365) gelen uyarılar artık bağımsız veri konnektörleri yerine tek bir Microsoft Defender XDR konnektörü üzerinden akar. Çoklu workspace senaryosunda bu konnektör yalnızca birincil workspace'e bağlanır; ikincil workspace'lerdeki bağımsız konnektörler yinelenen (duplicate) uyarıları önlemek için otomatik olarak devre dışı kalır.
• Otomasyon kuralları ve playbook'lar. Uyarı (alert) tetikleyicili otomasyon kuralları artık yalnızca Sentinel uyarılarında çalışır; Defender XDR uyarılarını da kapsamak için "Enhanced Alert Trigger" kullanmanız gerekir. Ayrıca SecurityIncident tablosunda "Description" alanı kalkıyor — bu alanı koşul olarak kullanan otomasyon kurallarınız varsa (örneğin ServiceNow entegrasyonunda), güncellenmesi gerekiyor.
• API alan adları değişiyor. Microsoft Sentinel API'sinde `providerName` değeri "Azure Sentinel" iken Defender portalında "Microsoft XDR" olur; `incidentUrl` artık Defender portalına işaret eder, üçüncü taraf ticketing sistemleriyle senkronizasyon için yeni eklenen `providerIncidentUrl` alanını kullanmanız önerilir.
• IdentityInfo tablosu RBAC kaybı. Tablo düzeyinde erişim kontrolü (table-level RBAC) ile IdentityInfo tablosunu kısıtlıyorsanız, geçiş sonrası bu kısıtlama artık uygulanmıyor — tablo Defender'ın yerel (native) tablosu hâline geliyor.

Bu değişikliklerin tam listesi ve teknik gerekçeleri için Microsoft'un resmi geçiş rehberine bakmanızı öneririz — özellikle otomasyon kuralı ve API entegrasyonu olan kurumlar için bu bölüm atlanmamalı.

Çoklu Workspace ve Çoklu Kiracı (MSSP) Senaryoları

Defender portalı artık workspace sayısında sınırlama getirmiyor: bir kiracıda bir birincil (primary) ve istediğiniz kadar ikincil (secondary) workspace bağlayabilirsiniz. Ancak birden fazla kiracıyı (tenant) tek panelden yönetmek isteyen MSSP'ler (yönetilen güvenlik hizmeti sağlayıcıları) için önemli bir fark var: Azure portalında kullanılan Granular Delegated Admin Privileges (GDAP) + Azure Lighthouse kombinasyonu, Defender portalındaki Sentinel verisi için desteklenmiyor. Bunun yerine Microsoft Entra B2B tabanlı Microsoft Defender çoklu kiracı yönetimi (multitenant management) kullanılıyor.

Bu, Türkiye'de birden fazla müşteri tenant'ını tek SOC'tan izleyen yönetilen güvenlik hizmeti sağlayıcıları (Xen Bilişim dahil) için mimari bir planlama gerektiriyor — GDAP tabanlı erişiminiz varsa, geçiş öncesi B2B bağlantı modeline dönüşü test etmeniz şart.

Veri Saklama, KVKK ve Gizlilik Etkisi

Bu, çoğu geçiş rehberinde atlanan ama Türkiye'deki kurumlar için kritik bir nokta: Azure portalında Sentinel kullanırken Microsoft Sentinel'in kendi veri saklama, işleme ve paylaşım politikaları geçerliyken, Defender portalına geçtiğinizde aynı veri için Microsoft Defender XDR'ın gizlilik politikaları devreye giriyor. Log Analytics workspace'inizin depolama bölgesi (region) değişmiyor, ama veri paylaşım ve saklama süresi kuralları farklı bir politika setine tabi oluyor.

KVKK'nın (6698 sayılı Kişisel Verilerin Korunması Kanunu) 12. maddesi kapsamında "gerekli teknik tedbirler"i alan veri sorumlusu kurumlar için pratik sonuç şu: SOC/SIEM verinizde kişisel veri işleniyorsa (kullanıcı adı, IP, e-posta gibi alanlar loglara düşüyorsa), VERBİS kaydınızdaki veri işleme envanteri ve varsa üçüncü taraf işleyici listesinde Sentinel/Defender XDR geçişini not etmeniz gerekebilir. Kurul'un genel yaklaşımı, veri işleyicinin (Microsoft) aynı kalması durumunda büyük bir bildirim yükümlülüğü doğurmasa da, iç veri işleme envanterinizi güncel tutmanız her zaman önerilir.

Ayrıca Türkiye'de Azure için ayrı bir region bulunmadığından (en yakın bölge West Europe/Hollanda), Sentinel verileriniz zaten sınır ötesi işleniyor olabilir — bu durum geçişle değişmiyor, ama geçiş sürecini KVKK uyum ekibinizle birlikte gözden geçirmek için iyi bir fırsat.

Doğrulama ve Test Adımları

Bağlantıyı kurduktan sonra üretim SOC operasyonuna geçmeden önce şunları doğrulayın:

1. Veri konnektörleri: Defender portalındaki "Data connectors" sayfasında üçüncü taraf konnektörlerinizin (örneğin güvenlik duvarı, VPN, on-prem AD) hâlâ veri gönderdiğini kontrol edin — konnektör kurulumunun temel mantığı için Sentinel veri bağlayıcısı nasıl bağlanır rehberimize bakabilirsiniz. Not: Defender for Endpoint/Identity/Cloud Apps/Office 365 gibi Microsoft ürün konnektörleri artık bu sayfada listelenmez, XDR konnektörü üzerinden gelir.
2. Analitik kurallar: Mevcut analitik kurallarınızın (Fusion hariç) hepsinin aktif ve olay ürettiğini test edin.
3. Otomasyon kuralları: Kritik playbook'larınızı test senaryosuyla tetikleyin; özellikle "Description" alanına bağlı koşullar ve incident title'a bağlı koşullar varsa mutlaka yeniden test edin.
4. Gelişmiş avlanma (Advanced Hunting) sorguları: KQL sorgularınızı ve özel fonksiyonlarınızı Defender portalının Advanced Hunting sayfasında çalıştırıp aynı sonuçları aldığınızı doğrulayın. Not: Bookmarks özelliği Advanced Hunting'de yok, "Microsoft Sentinel > Threat management > Hunting" altında hâlâ mevcut.
5. Üçüncü taraf entegrasyonlar: ServiceNow, Jira gibi ticketing sistemlerine giden webhook/API akışlarını test edin — `incidentUrl` ve description alanı değişikliklerinin entegrasyonunuzu bozmadığından emin olun.

Yaygın Hatalar ve Çözümleri

• "Connect a workspace" ekranında workspace görünmüyor: Genellikle rol yetersizliğinden kaynaklanır — Owner rolünüz "koşulsuz" değilse veya Security Administrator rolünüz yoksa workspace listede çıkmaz. Rol atamasını Azure portalında "Conditions" sekmesinden kontrol edin.
• Playbook'lar geçişten sonra tetiklenmiyor: İlk 5-10 dakikalık senkronizasyon gecikmesini bekleyin; hâlâ çalışmıyorsa "Enhanced Alert Trigger" kullanıp kullanmadığınızı ve otomasyon kuralının "Incident provider" koşulunun artık her zaman "Microsoft XDR" döndüğünü kontrol edin.
• Kapatılmış olaylar yeni uyarılarla yeniden açılmıyor: Azure portalındaki "alert grouping ile kapalı olayı yeniden aç" davranışı Defender portalında desteklenmiyor — yeni uyarılar artık yeni bir olay oluşturuyor. Triyaj sürecinizi buna göre güncelleyin.
• Müşteri yönetimli anahtar (CMK) sonrası alert'ler şifresiz görünüyor: CMK, analitik kuralları ve log verisini şifrelemeye devam eder, ama geçiş sonrası uyarı ve olaylar artık CMK ile şifrelenmez — bu beklenen bir davranıştır, hata değildir.
• "Can't access data related to this action" hatası playbook çalıştırırken: Olay henüz Sentinel'e senkronize olmamış demektir; birkaç dakika bekleyip sayfayı yenileyin.

Geçiş sürecinde takıldığınız bir nokta varsa Xen Bilişim'e WhatsApp'tan yazabilir veya Microsoft Security çözümlerimiz üzerinden 15 dakikalık ücretsiz teknik görüşme talep edebilirsiniz.

Geri Alma (Offboard) ve Rollback Notu

Geçiş geri alınabilir bir işlem — Defender portalında System > Settings > Microsoft Sentinel > Workspaces altında ilgili workspace'i seçip "Disconnect workspace" ile ayırabilirsiniz (bir gerekçe girmeniz istenir). Ancak dikkat: workspace'inizde Microsoft Defender XDR konnektörü yapılandırılmışsa, offboard işlemi bu konnektörü de otomatik olarak bağlantısını keser — Defender XDR olaylarını Sentinel'de tekrar görmek isterseniz konnektörü elle yeniden bağlamanız gerekir. 31 Mart 2027'den sonra offboard/rollback seçeneği anlamını yitirecek, çünkü Azure portalı deneyimi tamamen kapanmış olacak.

İleri Yapılandırma ve En İyi Uygulamalar

• İçeriği kod olarak yönetin: Azure portalındaki Workspace Manager, Defender portalında yok. Analitik kural ve otomasyon kurallarınızı workspace'ler arasında dağıtmak için GitHub/Azure DevOps tabanlı CI/CD içerik dağıtımını (önizleme) değerlendirin.
• Analist eğitimini atlamayın. Birleşik olay kuyruğu, farklı güvenlik alanlarından gelen uyarıları tek bir olayda toplayabiliyor — bu, analistlerin yalnızca kendi uzmanlık alanına (örneğin yalnızca kimlik veya yalnızca uç nokta) göre triyaj yapma alışkanlığını değiştiriyor. Katman 1/Katman 2 analist rolleri bu değişiklikle bazı kurumlarda birleştirilebiliyor.
• Correlation motoruna güvenin ama doğrulayın. Defender XDR'ın korelasyon mantığı "kutunun içinde" (proprietary) çalışıyor — beklenmedik olay birleştirmeleri görürseniz otomasyon kurallarınızın davranışını gözden geçirin, çünkü bir otomasyon kuralı beklemediğiniz veriyle tetiklenebilir.
• Enterprise Agreement/CSP yenileme takviminizle senkronize edin. Sentinel tüketim modeliniz ayrıysa da, güvenlik operasyonu bütçenizi gözden geçirdiğiniz dönemde (EA yenileme, CSP yıl dönümü) bu geçişi de planlayın — EA mi CSP mi karar rehberimize göz atabilirsiniz.

Saha Vakası: Bir Türk Finans Kurumunun Geçiş Deneyimi

Saha vakası: orta ölçekli finans kuruluşu, 40 kişilik BT/güvenlik ekibi, çoklu workspace SOC

Firma X — İstanbul merkezli, 3 şubeli bir finansal hizmetler kurumu — Azure portalında iki ayrı workspace üzerinden (biri üretim, biri test/geliştirme ortamı için) Sentinel çalıştırıyordu. Retirement duyurusu sonrası Xen Bilişim ile birlikte 6 haftalık bir geçiş planı yürütüldü.

Süre: 6 hafta (2 hafta envanter + test, 1 hafta pilot onboard, 2 hafta paralel çalışma/doğrulama, 1 hafta üretim kesimi).
Karar noktaları: (1) Üretim workspace'i birincil, test/geliştirme workspace'i ikincil olarak bağlandı. (2) ServiceNow entegrasyonundaki 14 otomasyon kuralından 3'ü "Description" alanına bağımlıydı — bu üçü yeniden yazıldı. (3) Fusion kuralının yerini alan Defender XDR korelasyonu, pilot dönemde 2 hafta boyunca paralel izlendi; yanlış pozitif oranı %8 azaldı. (4) KVKK uyum ekibi ile birlikte VERBİS envanterindeki "SIEM/log analizi" veri işleme faaliyeti güncellendi.
Sonuç: Geçiş sonrası ortalama olay kapatma süresi (MTTR) %18 iyileşti — büyük ölçüde birleşik olay kuyruğunun analist sekme değiştirme süresini azaltmasından kaynaklandı.
Xen ekibinin rolü: Rol/izin denetimi, otomasyon kuralı envanteri çıkarma, paralel çalışma döneminde uyarı karşılaştırması ve KVKK uyum ekibiyle koordinasyon.
Uyarı: Çoklu workspace'i olan kurumlarda birincil/ikincil workspace kararı tek yönlü değil — birincil workspace değiştirmek, XDR konnektörünün otomatik taşınmasını tetikliyor; bu kararı geçiş öncesi netleştirin, sonradan değiştirmek ek test yükü getiriyor.

(Vaka anonimleştirilmiştir; müşteri adı ve kesin rakamlar ticari gizlilik nedeniyle paylaşılmamaktadır.)

Sıkça Sorulan Sorular (SSS)

Defender portalına geçiş için ek ücret ödüyor muyum?

Hayır. Microsoft Defender XDR veya E5 lisansınız olmasa bile Sentinel'i Defender portalında ücretsiz kullanabilirsiniz; mevcut Sentinel/Log Analytics tüketim faturalandırmanız aynı şekilde devam eder.

31 Mart 2027'ye kadar geçiş yapmazsam ne olur?

Microsoft'un duyurusuna göre bu tarihten sonra Azure portalında Sentinel desteklenmeyecek ve kalan kullanıcılar otomatik olarak Defender portalına yönlendirilecek. Planlı bir geçiş yerine son anda zorunlu bir geçişle karşılaşmamak için erken başlamak önerilir.

Geçiş kaç gün/hafta sürer?

Teknik bağlama işlemi kendisi 10 dakikadan kısa sürer. Ancak otomasyon kurallarının test edilmesi, entegrasyonların doğrulanması ve analist eğitimi dahil edildiğinde, orta ölçekli bir kurum için gerçekçi bir plan 4-8 hafta arasında değişir — workspace sayısına ve otomasyon karmaşıklığına bağlı.

Fusion kuralını kaybediyor muyum?

Kuralın kendisi devre dışı kalıyor ama işlevi kaybolmuyor — Defender XDR'ın korelasyon motoru aynı çok aşamalı saldırı tespiti işlevini üstleniyor, farklı bir mantıkla.

MSSP olarak birden fazla müşteri kiracısını GDAP ile yönetiyorum, ne değişiyor?

GDAP + Azure Lighthouse kombinasyonu Defender portalındaki Sentinel verisi için desteklenmiyor; bunun yerine Microsoft Entra B2B tabanlı çoklu kiracı yönetimi (multitenant management) kullanmanız gerekiyor. Bu, MSSP'ler için erken planlama gerektiren bir mimari değişiklik.

Geçiş KVKK açısından bir bildirim yükümlülüğü doğurur mu?

Veri işleyici (Microsoft) değişmediği, yalnızca aynı verinin tabi olduğu politika seti (Sentinel politikalarından Defender XDR politikalarına) değiştiği için genellikle büyük bir bildirim yükümlülüğü doğurmaz. Yine de VERBİS veri işleme envanterinizi ve varsa aydınlatma metinlerinizi güncel tutmanız, uyum ekibinizle bu geçişi paylaşmanız önerilir.

Geçişi geri alabilir miyim?

Evet, 31 Mart 2027'den önce "Disconnect workspace" ile geri alınabilir. Ancak Defender XDR konnektörünüz varsa bu işlem onu da otomatik olarak keser; tekrar bağlamak elle yapılan bir işlemdir.

Küçük bir workspace'im var, geçişi kendim yapabilir miyim, yoksa danışman mı gerekir?

Tek workspace, az sayıda otomasyon kuralı olan küçük ortamlarda teknik adımları BT ekibiniz kendi başına uygulayabilir. Çoklu workspace, ServiceNow/SOAR entegrasyonu veya MSSP/GDAP senaryosu varsa, otomasyon kurallarının ve entegrasyonların envanterini çıkarıp test etmek için deneyimli bir Microsoft güvenlik danışmanından destek almanız riski azaltır.

Sonuç: Erken Planlama, Sürpriz Kesintiyi Önler

31 Mart 2027 uzak gibi görünebilir, ama Microsoft Sentinel'i Azure portalından Defender portalına taşımak yalnızca bir "Connect" düğmesine tıklamaktan ibaret değil. Fusion kuralının devre dışı kalması, otomasyon kurallarının yeniden test edilmesi, API alan adı değişiklikleri ve veri gizlilik politikasının Defender XDR kurallarına geçmesi gibi etkiler, özellikle çoklu workspace veya yoğun otomasyonlu SOC ortamlarında gerçek bir proje gerektiriyor.

Erken başlayan kurumlar, geçişi kendi takvimlerinde, üretim ortamını riske atmadan, paralel doğrulama yaparak tamamlıyor. Son ana bırakanlar ise 2027 başında yoğun bir geçiş trafiğinde kendilerini bulabilir. Ön koşulları bugün gözden geçirmek, otomasyon kurallarınızın envanterini çıkarmak ve bir pilot workspace ile denemeye başlamak, riski en aza indirmenin en pratik yolu.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Microsoft Sentinel'den Defender portalına geçiş yolculuğunda envanter çıkarmadan, otomasyon kurallarının yeniden test edilmesinden analist eğitimine kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın veya WhatsApp'tan yazın.