KOBİ'lerde Zero Trust: Ağ segmentasyonu, cihaz uyumluluğu ve pazarlama klişeleri yerine pragmatik yol haritaları

„Zero Trust“ ilk bakışta büyük bir şirket programı gibi görünebilir. Ancak birçok orta ölçekli işletme ortamında bu daha çok gelişmiş gerçekliğe pragmatik bir yanıt: dış şubeler, hibrit ekipler, iş ortağı erişimleri, bulut hizmetleri, mobil cihazlar ve bunların yanında klasik sunucu hizmetleri, ERP istemcileri, dosya paylaşımları ve özel donanım. Eski model „içerisi güvenilir, dışarısı tehlikeli“ burada artık işlemiyor – çünkü ele geçirilmiş bir istemci dahili ağda genellikle çok fazla yol buluyor.

Orta ölçekli işletmelerde Zero Trust bu yüzden öncelikle şunu ifade eder: Erişimler ağ konumuna göre genelleyerek izin verilmez; bunun yerine kimlik, cihaz durumu (Device Compliance), bağlam ve asgari gerekli haklar temelinde karar verilir. Ve: Mimari öyle inşa edilir ki bir ihlal otomatik olarak yaygın bir felakete dönüşmesin.

Bu yazı buzzwordleri bir kenara bırakır ve pratikte en büyük etkiyi sağlayan üç kola odaklanır: Ağ segmentasyonu (kimin nereye iletişim kurmasına izin var?), Device Compliance (hangi cihaz durumu ön koşuldur?) ve Roadmaps, mükemmel bir hedef görüntüsünü beklemek yerine aşamalar halinde sonuç veren. Odak, operasyon, administrasyon, kurumsal yazılım, arayüzler ve rollout üzerindeki etkiler üzerindedir.

Zero Trust pratikte ne demektir – ne değildir

Eğer „Zero Trust“ bir projeksiyon alanı haline gelmemesi isteniyorsa, açık bir çalışma tanımı yardımcı olur. Pratikte Zero Trust üç ilkeyi kapsar:

• Açık doğrulama: Her erişim kararı sinyallere dayanır (kimlik, MFA durumu, cihaz durumu, risk, hedef sistemin hassasiyeti).
• Least Privilege (asgari gerekli yetkiler): Kullanıcılar, servisler ve adminler bir süreç için gerçekten ihtiyaç duyduklarıyla sınırlanır – mümkünse zamanla sınırlı ve izlenebilir.
• Assume Breach: Mimari ve operasyon, bir uç noktanın ele geçirilmiş olabileceğini varsayar. Amaç zarar sınırlama (Containment), „her şeyi engelleyeceğiz“ vaadi değil.

Kastedilenler arasında şu yoktur: „her şeyi baştan yapmak“, „sadece bulut“, „LAN’ı tamamen mikrosegmentasyonla değiştireceğiz“ veya „departmanlar pes edene kadar her şeyi engelleyeceğiz“. Zero Trust gündelik işlerde çalışmak zorundadır: tarayıcılar taramaya devam eder, ERP istemcileri çalışır, arayüzler işler, toplu işler geceleri başlar ve administrasyon için bir acil durum erişim yolu vardır.

Orta ölçekli işletmelerin Zero Trust ile beklenenden daha hızlı ilerlemesinin nedenleri

Orta ölçekli işletmelerde karar süreçleri genellikle daha kısadır ve paralel, rekabet eden güvenlik insiyatifleri daha azdır. Aynı zamanda kaynaklar daha sınırlıdır ve iş yazılımlarının yaşam döngüleri uzundur. Bu koşullar yine de uyumlu hale getirilebilir; önlemler tipik risk tetikleyicilerine odaklandığında:

• Ransomware zincirleri: Phishing → ele geçirilmiş istemci → lateral hareket (örn. SMB/RDP) → kimlik/backup/depolama → şifreleme.
• „Gölge“ erişimler: unutulmuş VPN hesapları, paylaşılan servis hesapları, sahipliği olmayan partner erişimleri, kalıcı yönetici hakları.
• Legacy entegrasyonları: dosya paylaşımları „entegrasyon otobüsü“ olarak kullanılması, sabit IP beyaz listeleri, cihaz durumu ve son kullanma tarihi olmayan açık portlar.

Büyük fayda daha çok „içgüdüsel daha fazla güvenlik“ değil, kontrol edilebilir bir etki sağlayabilmektir: istemci bölgesinden daha az ulaşılabilir hedef, günlük kullanımda daha az ayrıcalıklı hesap ve veriler ile arayüzler için daha belirgin yollar.

Ağ segmentasyonu bir Zero Trust bileşeni olarak

Ağ segmentasyonu, yatay hareketi doğrudan kısıtladığı için en somut başlangıçtır. Kastedilen, sistem alanlarının bilinçli bir şekilde ayrılmasıdır; tipik olarak VLANs/VRFs (anahtar veya yönlendirme düzeyinde mantıksal ağ ayrımı) ve segmentler arasındaki Firewall-Regeln ile. Amaç her sistemi tek tek izole etmek değil, sadece tanımlı protokollerin ve hedeflerin ulaşılabildiği kommunikationsarme Zonen oluşturmaktır.

Pragmatisches Zielbild: Zonen, die Betrieb und Sicherheit zusammenbringen

Gelişmiş ortamlarda gerçekçi bir hedef genellikle üç aşamalıdır ve gerektiğinde genişletilir:

• Client-Zone: Ofis istemcileri, dizüstü bilgisayarlar, mobil cihazlar. Buradan mümkün olduğunca yönetici protokollerine ve yönetim sistemlerine erişim olmamalıdır.
• Server-/Workload-Zone: İş uygulamaları (ERP/CRM/Portale), veritabanları, entegrasyon hizmetleri, dosya servisleri. Erişim yalnızca tanımlı portlar üzerinden ve tercihen uygulama yolları aracılığıyla olmalıdır.
• Admin-/Management-Zone: Kimlik (ör. Domain Controller/IdP), yedekleme, sanallaştırma, monitoring, ağ yönetimi. Erişim yalnızca yönetici iş istasyonlarından veya bastion-hostlar üzerinden, kısıtlı ve kayıtlı olarak gerçekleşmelidir.

Bu ayrım sadece „Netzwerk“ değildir. İleride yapılacak kontrollerin (Device Compliance, ayrıcalıklı erişimler, Service-to-Service-Absicherung) Any-to-Any erişilebilirlik ile etkisiz hale gelmemesi için ön koşuldur.

Stolperfallen: SMB, Drucker/IoT und „temporär“ offene Ports

Segmentasyon nadiren switch’lere veya firewall’lara takılır; başarısızlığa yol açan çoğunlukla tanımlanmamış trafik akışlarıdır. Üç tipik desen vardır:

• SMB/Fileshares als Integrationsbus: Uygulamalar dosyaları klasörlere yazar, iş ortakları bunları alır, Excel iş akışları ağ sürücülerine erişir. Segmentasyon bu durumda kararlar alınmasını zorunlu kılar: Hangi yollar gerçekten gerekli? Hangi durumlarda SFTP/HTTPS, portaller veya bir Message Broker’a geçiş mantıklıdır?
• Druck/Scan/IoT: Çok fonksiyonlu cihazlar, etiket yazıcıları, tarayıcılar, üretim ekipmanları genellikle birden fazla sunucu ile konuşur. Bu cihazlar, asgari düzeyde belgelenmiş istisnalar ve düzgün envanterleme ile ayrı bir segmente yerleştirilmelidir.
• „Einmal offen, immer offen“: RDP, SQL-Ports veya WinRM bir proje için açıldı ve olduğu gibi kalıyor. Segmentasyon yalnızca kural sahipleri ve istisnalar için bir son kullanma tarihi ile işe yarar.

Segmentasyon bir değişim programı olarak kendini kanıtlamıştır: önce görünürlük (Netflow/Firewall-Logs), sonra pilot segmentler, ardından dalgalar halinde rollout. Tüm VLAN’lar arasında doğrudan „Default Deny“ uygulayanlar kesintiler üretir ve kabul görmeyi kaybeder.

Segmentierung für Unternehmenssoftware, Datenbanken und Integrationen

Bireysel kurumsal yazılımlar ve süreç odaklı yazılım çözümleri için segmentasyon çift etkili olur: daha az risk ve daha net işletme görünümleri. Tipik rehber ilkeler:

• App-Server → Datenbank: yalnızca gerekli DB-Port, yalnızca tanımlı uygulama alt ağlarından; istemci bağlantıları doğrudan veritabanına olmaz.
• Clients → Anwendung: doğrudan iç servisler veya sunucu paylaşımlarına erişim yerine öncelikle Web-Frontend veya API üzerinden HTTPS tercih edilmelidir.
• Integrationszone: REST/SOAP/SFTP/Message Broker için özel sistemler, ERP/CRM’de ve iş ortaklarına yönelik kontrollü yollarla.

Böylece ağda aksi halde „versteckt“ kalan mimari konular görünür hale gelir: veritabanlarına doğrudan bağlanan fat clients; yönetici yetkileri gerektiren batch süreçleri; veya açık bir sorumluluk olmadan „einfach laufen“ durumda olan arayüzler.

Cihaz Uyumluluğu: Erişim için Cihaz Durumu Önkoşulu

İkinci kaldıraç, son cihazlar sıklıkla giriş noktası olduğu için Cihaz Uyumluluğudur. Burada “Compliance” hukuki uyumluluk değil, teknik asgari gereksinimler anlamına gelir: yama düzeyi, şifreleme (ör. BitLocker/FileVault), etkin kötü amaçlı yazılım koruması, güvenlik duvarı durumu, Secure Boot ve cihazın yönetiliyor olduğunun kanıtı (MDM/Endpoint Management).

Microsoft ortamlarında bu sıklıkla Intune/Endpoint Manager ile birlikte Koşullu Erişim ile uygulanır. Koşullu Erişim, oturum açarken erişime izin verilip verilmeyeceğine karar veren politikalar bütünüdür (ör. yalnızca MFA ile ve yalnızca uyumlu cihazlardan). Diğer teknoloji yığınlarında benzer işleyiş MDM, Kimlik Sağlayıcı (IdP) ve ZTNA/SSE çözümleri aracılığıyla gerçekleşir. Önemli olan araç değil, operasyonel olarak sürdürülebilir politika‚dır.

Destek ve işletmeyi sürdürebilecek politikalar

Sık rastlanan bir hayal kırıklığı nedeni, kademelendirilmiş erişim senaryoları olmadan aşırı sert kurallardır. Uygulanabilir olan, aşamalı bir modeldir:

• Temel: Herkes için MFA; kritik uygulamalarda (yönetici panelleri, Finans, İK, uzaktan erişimler) bilinmeyen cihazlar için engelleme.
• Standart: Merkezi portallara ve işbirliği araçlarına erişim yalnızca kayıtlı cihazlardan; kayıtlı olmayan cihazlar ancak platform destekliyorsa sınırlı (ör. sadece web) erişim alır.
• Yüksek: Yönetici erişimleri yalnızca özel yönetici iş istasyonlarından (PAW, Ayrıcalıklı Erişim İş İstasyonu) sağlanır; daha sıkı uyumluluk kuralları ve günlük kullanımda yerel yönetici hakları yoktur.

Önemli: “uyumlu” kalıcı bir durum değildir. Cihazlar uyumluluğu kaybedebilir (güncelleme gecikmesi, şifreleme hatası, eski işletim sistemi). Zero Trust gereği: tartışma değil, kontrollü geri düşürme. Örnek: Portal erişimi devam edebilir; VPN veya yönetim bölgelerine erişim, iyileştirme yapılana kadar engellenir.

BYOD, özel cihazlar ve yönetilemeyen uç birimler

KOBİ’lerde genellikle standart dizüstü bilgisayarlar gibi yönetilemeyen cihaz sınıfları vardır: ölçüm cihazları, makine PC’leri, terminal sistemleri, tarayıcılar, özel yazılımlar için eski Windows sürümleri. BT, cihaz kategorilerini tanımlayıp erişim haklarını bunlara bağladığında bu yönetilebilir hale gelir:

• Yönetilen Standart Cihazlar: MDM/GPO ile tam uyumluluk; bilgi çalışması ve yönetim için standart.
• Kısıtlı Cihazlar: Sınırlı şekilde yönetilebilir; sadece izole segmentlere ve yalnızca tanımlı hedef sistemlere (ör. üretim ağı → entegrasyon geçidi) erişmelerine izin verilir.
• Yönetilmeyen/BYOD: Sadece sınırlı hizmetlere erişim (ör. Webmail/Portal) MFA ile ve veri çıkışına ilişkin net kısıtlamalarla.

Böylece “yapılamaz” olan bir durum istikrarlı bir uzlaşıya dönüşür: özel cihazlara izin verilir, ancak kapsam sınırlandırılır ve böylece risk kontrol edilebilir hale gelir.

NAC ve 802.1X: Ağ artık yalnızca tanınan cihazlara izin verdiğinde

Cihaz uyumluluğu oturum açmayla bitmez. Bir sonraki adım Ağ Erişim Kontrolü (NAC)dir: cihazlara, anahtarda veya kablosuz ağda kimliklerini doğruladıklarında ağ erişimi verilir. 802.1X, cihazın sertifika veya kullanıcı kimliğiyle ağa kimlik doğrulaması yaptığı bir standarttır. 802.1X olmayan cihazlar için sıklıkla MAB (MAC Kimlik Doğrulama Atlaması) kullanılır – istisna olarak, daha az güvenli ama bazen kaçınılmaz.

NAC çok etkili, ancak operasyonel olarak zorludur. Gerçek şu ki: birçok istisna (yazıcılar, IoT, misafirler, eski cihazlar) normaldir. Bir NAC projesi aşamalı olarak yürütüldüğünde yönetilebilir kalır:

• Bir lokasyonda pilot uygulama veya öncelikle sadece Corporate WLAN içinde.
• Gerçek cihaz ortamını öğrenmek için Monitor-/Alert-modunda başlatma.
• Bilinmeyen cihazlar için açık yardım masası süreçleri ve mümkünse Self-Service kaydı ile birlikte bir karantina ağı.

Ek fayda: daha iyi envanterleme. NAC, bir „cihaz gerçeğine“ zorlar ve bu da segmentasyon, olay müdahalesi ve yaşam döngüsü kararları için temel sağlar.

Identitäten, Rollen und Service Accounts: Ohne IAM-Hygiene bleibt es Stückwerk

Zero Trust sıklıkla bir ağ veya uç nokta konusu olarak anlaşılır. Ancak uygulamada doğruluk ve sürdürülebilirlik kimlik tarafı tarafından belirlenir. IAM (Kimlik ve Erişim Yönetimi) giriş, roller/gruplar, Joiner-Mover-Leaver süreçleri ve teknik hesapları (Service Accounts) kapsar.

Least Privilege in Business-Software: Rollen konsolidieren, Admin trennen

ERP/CRM ve portallerde izinler genellikle tarihsel olarak oluşur: yeni bir işlev, yeni bir rol, sonra tekrar bir istisna. Sonuç, örtüşen yetkiler ve „kim ne yapabilir?“ sorusuna belirsiz cevaplardır. Zero Trust uyumlu hale gelmek için rollerin iş yetenekleri olarak modellenmesi gerekir (ör. „faturayı onaylama“, „ana verileri değiştirme“, „dışa aktarımları başlatma“) ve teknik yönetici ayrıcalıkları bunun dışına tutarlı şekilde ayrılmalıdır.

Operasyon için önemli olan, rollerin yeniden sertifikalandırılabilir olmasıdır: Belirli döngülerde sorumlular erişimlerin hâlâ gerekli olduğunu onaylar. Bunun bürokratik olması gerekmez, ancak her veri alanı için açık sahipler olmalıdır.

Service Accounts und Schnittstellenzugriffe absichern

Birçok kritik erişim kullanıcılar tarafından değil, hizmetler tarafından gerçekleşir: entegrasyon işleri, ETL, partner arayüzleri, batch süreçleri, Windows-servisleri veya Linux-servisleri. Tipik riskler statik parolalar, aşırı geniş yetkiler, döngüsel değiştirme eksikliği ve belirsiz sahipliktir. Zero Trust bağlamında geçerli olanlar:

• Her hizmet için ayrı kimlik: birden fazla iş için paylaşılan hesaplar kullanılmasın.
• Minimum yetki: örn. bir SFTP-inbox için sadece yazma hakkı, bir paylaşım üzerinde tam erişim yerine.
• Sırların profesyonelce yönetimi: Anahtarlar/parolalar yapılandırma dosyalarında tutulmasın; rotasyon planlanabilir olsun, sorumlular atansın.
• Segmentasyona uygun ağ yolları: bir entegrasyon servisi tanımlı hedeflere konuşsun, „tüm sunucu ağına“ değil.

Özellikle arayüzlerde Zero Trust bununla aynı zamanda bir mimari çalışma haline gelir: Bir API-Gateway veya Integration-Proxy kimlik doğrulamayı, oran sınırlamalarını ve logging’i merkezileştirip kontrolsüz büyümeyi azaltabilir. Bu uygulama güvenliğinin yerini almaz, ancak daha iyi operasyon kontrolü sağlar.

Zero Trust im Mittelstand als Roadmap: in Etappen liefern

İşleyen bir yol haritasının iki özelliği vardır: birkaç hafta içinde gözle görülür iyileştirmeler üretir ve sonraki genişleme adımlarına bağlanabilir kalır. Pratikte eksiksizlikten ziyade risk kaldıraçlarına odaklanan bir aşama modeli işe yarıyor.

Phase 0: Kritische Systeme, Datenflüsse und Außenkanten erfassen

Engellemeden ve segmentlemeden önce asgari bir şeffaflığa ihtiyaç vardır:

• Hangi sistemler kritik (ERP/DMS, veritabanları, yedekleme, kimlik, sanallaştırma, entegrasyon sunucuları)?
• Hangi erişim yolları mevcut (VPN, RDP/SSH, yönetici araçları, API, SMB, SFTP)?
• Hangi dış uç noktalar var (iş ortakları, lokasyonlar, Bulut kiracıları, harici yönetici erişimleri)?

Bu mükemmel bir CMDB çağrısı değil. Bu, daha sonra istisnaları, güvenlik duvarı kurallarını ve sorumlulukları sürdürülebilir kılan bir çalışma listesidir.

Faz 1: Kimliği sertleştirmek – MFA, acil erişimler, yönetici oturumlarını ayırmak

Birçok ortamda MFA var, ancak düzgün uygulanmamış. Dayanıklı asgari standartlar şunlardır:

• Tüm kullanıcılar için MFA, özellikle uzaktan erişimler ve yönetim arayüzleri için.
• Tanımlanmış bir acil erişim (‚Break Glass‘): ayrı korunmuş, izlenen ve yalnızca olaylar için ayrılmış.
• Kullanıcı ve yönetici hesaplarının ayrılması, böylece kimlik avı otomatik olarak ayrıcalıklı hakları ele geçiremesin.

Fayda doğrudan: Birçok saldırı ikinci faktörde başarısız oluyor ve ele geçirilen standart hesaplar daha nadiren doğrudan yönetim katmanına yol açar.

Faz 2: Cihaz uygunluğunu önce kritik hedeflerde zorla

‚Tüm cihazları hemen uyumlu yapmak‘ yerine genellikle kuralları kritik varlıklara bağlamak daha etkili olur:

• Yönetici portalları (sanallaştırma, yedekleme, ağ yönetimi) sadece uyumlu cihazlardan erişilebilir.
• VPN sadece uyumlu cihazlardan veya sıkı şekilde kısıtlanmış hedef ağlarla kullanılabilir.
• Finans/İK portalları ve hassas veri dışa aktarımları yalnızca cihaz denetimi ve net oturum kuralları ile.

Bu, anlamlı bir geçiş baskısı oluşturur: Tam erişime ihtiyaç duyanlar cihazı yönetim kapsamına sokmak zorunda. Aynı zamanda tüm iş istasyonlarını hemen engellemezsiniz.

Faz 3: Ağ segmentasyonu dalgalar halinde – Önce yedekleme ve yönetimi koruyun

Eğer kısa sürede yalnızca bir segmentasyon kuralı uygulanabilecekse, genellikle bu olmalıdır: Yedekleme ve yönetim sistemleri istemci bölgesinden doğrudan erişilebilir olmamalıdır. Bu, fidye yazılımı tırmanışına karşı güçlü bir fren işlevi görür. Ardından sunucu bölgeleri ve tanımlanmış bir entegrasyon bölgesi gelir.

Her dalga için bir geri dönüş planına ihtiyaç vardır: Acil durumda geçici olarak neler açılabilir, bunun nasıl belgeleneceği, kimlerin yeniden kapatacağı? Bu mekanizma olmadan segmentasyon günlük kullanımda yavaşça aşınır.

Faz 4: Privileged Access Management (PAM) ve yönetici iş istasyonları

PAM (Privileged Access Management), ayrıcalıklı erişimleri sınırlamak için teknik ve süreçleri kapsar: Just-in-Time hakları (zaman sınırlı), onay yolları, parola/anahtar rotasyonu ve kayıt tutma. KOBİ’lerde pratik bir başlangıç genellikle şudur:

• Ayrılmış yönetici iş istasyonları (PAW) veya RDP/SSH için bir bastion ortamı.
• Günlük dizüstülerden yönetici işlemleri yapılmaması.
• Olay anında gerçekten kullanılabilir runbook’lar ve kayıtlar.

Bu, ele geçirilmiş bir kullanıcı cihazının yönetim bölgesine sıçrama tahtası olma ihtimalini azaltır.

İşletme gerçeği: Zero Trust nerede işe yarar (ve nasıl yönetilir)

Zero Trust ücretsiz değildir. Bunu açıkça planlayanların sonra daha az politik sürtüşmesi olur. Tipik işletme sonuçları:

Daha fazla politika ve istisna yönetimi

Başlangıçta ayarlamalar artar: Uyumluluk politikası çok sert davranır, bir lokasyon özel donanıma sahiptir, bir servis yine de bağlantıya ihtiyaç duyar. Kaos ile ilerleme arasındaki fark, açık bir istisna sürecidir: süreli, bir sahibi olan, belgelenmiş ve düzenli olarak denetlenen. Aksi halde Zero Trust hızla tekrar ‚Any-to-Any, çünkü acele vardı‘ haline gelir.

Günlükleme (logging) sorun giderme için ön koşul haline gelir

Erişimler bağlama bağlı olarak kararlaştırıldığında, logların güvenilir olması gerekir: IdP ve kimlik doğrulama logları, uç nokta durumu, Firewall-/VPN-Logları ve tercihen merkezi değerlendirme (SIEM veya konsolide edilmiş bir log yönetimi). Loglar olmadan “Kullanıcı neden giremiyor?” sorusu yeniden üretilemez ve politikalar hayal kırıklığıyla gevşetilir.

Kurumsal yazılıma etkileri: Kimlik doğrulama, veri yolları, sertifikalar

Birçok sistem yeniden inşa edilmek zorunda değil, ancak yeni güvenlik varsayımlarına uymalıdır. Tipik uyarlamalar:

• OIDC/SAML üzerinden SSO, anlamlı olduğu durumlarda yerel parolalar yerine. OIDC (OpenID Connect), bir IdP üzerinden oturum açma için modern bir protokoldür; SAML kurumsal SSO’da hâlâ yaygındır.
• Fileshare yerine API, segmentasyon aksi halde sürekli istisnalar gerektirecekse.
• Servisler arası güvenlik (ör. mTLS): mTLS, her iki tarafın sertifikalarını doğrulayan TLS’dir; bu sayede çağıran servis de kesin olarak tanımlanır.

Bu maddeler sadece „Security“ ile ilgili değil. Operasyonu etkiler: sertifika süreleri, gizli anahtar rotasyonu, dağıtımlar, izleme ve arayüzler için net sorumluluklar.

Başarıyı, metriklere boğulmadan ölçmek

İlerlemeyi kontrol edilebilir kılmak için birkaç ölçüm noktası yeterlidir:

• Yönetilen cihazların payı (yönetilen vs. yönetilmeyen) ve eğilim.
• Uygunluk oranı (compliant vs. non-compliant) cihaz grubu başına ve en sık nedenler (güncellemeler, şifreleme, AV).
• Düz ağ izinlerinin azaltılması: segmentler arasındaki Any-to-Any kurallarının sayısı, süreli istisnaların sayısı ve bunların yaşı.
• Privileged Access: hâlâ PAW olmayan cihazlardan gelen yönetici oturumlarının oranı; kalıcı yönetici yetkilerinin azaltılması.
• Olay sinyalleri: yönetim bölgelerine engellenmiş erişimler, olağandışı kimlik doğrulamalar, tekrarlayan kötü amaçlı yazılım tespitleri.

Soru her zaman şudur: Hangi önlem riski ölçülebilir şekilde azaltır, operasyonu engellemeden?

Sonuç: Zero Trust bir işletme kararıdır, araç tartışması değil

Orta ölçekli işletmelerde Zero Trust, mimari, işletim ve temiz erişim kontrolünün birleşimi olarak anlaşıldığında işler. Segmentasyon ağ içindeki hareket alanını sınırlar, cihaz uyumluluğu giriş eşiğini yükseltir ve aşamalı bir yol haritası önce kimliği, yedeklemeyi ve yönetimi korur. Önemli olan, istisnaların gayri resmi olarak büyümesine izin vermemek; bunları süreli, belgelenmiş bir süreç olarak yürütmek ve kurumsal yazılım, arayüzler ile sertifika/secret yaşam döngüsü üzerindeki etkileri erken planlamaktır.

Proje veya modernizasyon girişimini Net-Base ile görüşün.