render farm ağ segmentasyonu ve WireGuard güvenliği: Tier-1 + Tier-2 mimari

Giriş

Bir render farm, render sorunu olmadan önce bir ağ sorunudur. Frame'ler bir submission makinesi, bir manager, bir worker filosu, bir asset cache ve bir output store arasında akar; lisans hakları artistler ile lisans sunucuları arasında akar; remote oturumlar artistler ile sürdükleri workstation yüzeyi arasında akar. Ağ tek bir odada tek bir switch olduğunda güvenlik modeli ağırlıklı olarak perimeter'dir. Farm datacenter veya kıtaları kapsadığında perimeter artık kullanışlı bir analiz birimi değildir: bir bina sınırını aşan her bağlantı, aksi kanıtlanana kadar bir genel internet bağlantısıdır, bir uzak sistemi tutan her credential ele geçirilebilir ve her diğer worker'a ulaşabilen her worker, bir kez compromise edilirse pivot yapabilen bir worker'dır.

Bu makale cross-site ve cross-country render farm deployment'ları için işlettiğimiz güvenlik mimarisini açıklıyor — default-deny edge ile iki tier firewall modeli, arkasında düğüm başına host firewall'lar, bir bina sınırını aşan her bağlantı için WireGuard uçtan uca şifreleme, her operatör rolü için en az ayrıcalık erişim örüntüleri ve paylaşımlı multi-tenant altyapıdan tek müşterili dedicated cluster'lara ölçeklenen müşteri izolasyon ilkeleri. Hedef kitle: cloud-rendering tedarikçilerini değerlendiren IT güvenlik ekipleri, compliance officer'lar ve pipeline mimarları. Ağ mimarisi hakkında ayrı bir yazı — WireGuard hub-and-spoke, BBR, MSS clamping ve paylaşılan SMB cache — taşımayı kapsar; bu makale telin üzerinde ne olduğunu kapsar.

render farm için ağ segmentasyonu ilkeleri

Segmentasyon burada üç ayrı şey demektir. Birincisi, hiçbir düğüm işi için ulaşması gerekmeyen başka bir düğüme ulaşamaz. Bir render worker, cache'den asset okur, manager'dan job çeker, output'ları bilinen bir konuma geri yazar ve heartbeat telemetrisi gönderir — başka bir şey yapmaz. Diğer worker'lara pivot yapamayan, operatör SSH'sine veya management plane'e ulaşamayan bir compromise edilmiş worker, cluster-wide bir arıza yerine kontrol altında tutulmuş bir arızadır. Yanal hareket, bir segmentasyon politikasının önlediği en sonuçlu şeydir.

İkincisi, hiçbir müşteri başka bir müşteriye ulaşamaz. Multi-tenant altyapıda bu, işlemlerin, kullanıcı hesaplarının, dosya sistemi yollarının ve lisans check-out'larının işletim sistemi düzeyinde müşteri başına izole edildiği anlamına gelir. Dedicated cluster altyapısında bu, fiziksel donanım sınırları, ayrı WireGuard hub'lar, ayrı credential store'lar ve ayrı operasyonel yönetim yüzeyleri demektir. İzolasyonun gücü workload'un hassasiyetiyle eşleşmelidir — bir ürün görselleştirmesi render eden bir freelancer ve pre-release entertainment işi render eden bir stüdyo aynı seviyeye ihtiyaç duymaz, ancak tehdit modellerine uyan seviyeyi seçebilmelidirler.

Üçüncüsü, hiçbir müşteri operatörün iç sistemlerine bir işin gerçekten ihtiyaç duyduğu yüzeyin ötesinde ulaşamaz. Bir render submission'ı manager'ın job kuyruğuna yazar ve kendi output'larını okur; diğer müşterileri numaralandırmasına, operatörün billing veritabanını okumasına veya source control'üne ulaşmasına gerek yoktur. Bu, operatörün kendi sistemleri aracılığıyla her müşteriyi her diğer müşteriden koruyan ayrıcalık sınırıdır.

İşlettiğimiz tier modeli bu üç ilkeyi yansıtır. Tier 1 perimeter'dir — kamuya açık internete bakan ve hangi trafiğin gireceğine karar veren edge gateway. Tier 2 düğüm başına host firewall'dur — perimeter içindeki her makine, hangi peer'lardan bağlantı kabul edeceğine bağımsız karar verir. Her iki tier'ın üzerinde, uygulama katmanı erişim kontrolleri rol ayrımını, müşteri izolasyonunu ve compliance review'ların dikkate aldığı audit sınırını uygular. Her tier bağımsız olarak audit edilebilir; birindeki bir arıza diğerlerini çökertmez.

ufw ve default-deny ile Tier-1 edge

Cluster'ın edge'i ufw çalıştıran tek bir Linux gateway'dir; Ubuntu LTS'de nftables için kanonik frontend. Yapılandırılmış duruş default deny incoming ve default allow outgoing'dir. Genel arayüzdeki tek gelen kural WireGuard için allow 51820/udp'dir. Başka hiçbir şey genel taraftan trafik kabul etmez — SSH, HTTPS, SMB, render manager API'si, monitoring agent'ları yok. Bu servisler yalnızca iç arayüzlere bind eder; bunlara cluster dışından ulaşmak önce bir WireGuard tüneli terminate etmeyi gerektirir.

Mantık mekaniktir. Genel internetteki her açık port dakikalar içinde taranır ve ardından sürekli olarak yoklanır. Genel port sayısını tam olarak bire indirgemek ve o portun kimliği doğrulanmamış prob'lara yanıt vermeyen bir protokol konuşmasını sağlamak (WireGuard tanımadığı bir peer'a hiçbir şey yanıtlamaz), saldırı yüzeyini en küçük anlamlı birime indirir. WireGuard tüneli arkasındaki SSH, saldırganın önce WireGuard'ı yenmeden ulaşamayacağı bir hedeftir.

Forward zincirinin açık dikkat gerektirir. Gateway, WireGuard arayüzü ile iç cluster alt ağı arasında router olarak hareket eder ve ufw'nin default forward duruşu deny'dir. /etc/default/ufw içinde DEFAULT_FORWARD_POLICY="ACCEPT" ayarlarız, sonra aslında yönlendirilen akışları bilinen cluster alt ağları arasında trafiğe izin veren ve diğer her şeyi reddeden açık FORWARD zincir kurallarıyla daraltırız. Sonuç, audit edilebilir ve kimsenin amaçlamadığı bir hedefe yanlışlıkla paket yönlendirmeyen bir perimeter'dir.

Giden kurallar aynı disiplini hak eder. Worker'lar küçük bir upstream asset store kümesinden çeker, manager küçük bir lisans sunucusu kümesiyle konuşur, telemetri küçük bir monitoring endpoint kümesine gider ve OS paket güncellemeleri bilinen bir mirror'dan çeker. Giden hedefleri o küçük kümeye kilitlemek bütün bir post-compromise davranış sınıfını engeller: saldırgan kontrolündeki bir host'a veri exfiltrate etmek isteyen bir compromise edilmiş worker host'a ulaşamaz çünkü host egress allowlist'inde değildir. Egress filtreleme görünmez exfiltration'ı monitoring'in işaretleyebileceği gürültülü bir girişime dönüştürür.

Tier-1 edge'deki logging her düşürülen gelen paketi ve router zincirindeki her yönlendirilen akışı kaydeder ve yalnızca kimliği doğrulanmış operatör workstation'larından erişilebilen aynı WireGuard tüneli arkasındaki merkezi bir log host'a gönderir. Log'lar compliance review'lar için birincil audit kanıt kaynağıdır.

Her düğümde Tier-2 host firewall

Tier-1 edge gerekli ve yeterli değildir. İç alt ağdaki her diğer worker'dan erişilebilen bir worker, edge'in ne kadar güçlü olduğuna bakılmaksızın cluster-wide bir pivot'tan bir compromise uzaktadır. Tier 2 cevaptır: perimeter içindeki her makine, kendi ruleset'iyle kendi host firewall'unu işletir ve hangi peer'ları kabul ettiğine bağımsız karar verir.

Linux düğümlerinde host firewall ufw'dir; edge ile aynı default-deny inbound duruşuyla yapılandırılmış ama düğümün rolünün gerektirdiği bağlantılara izin veren iç kurallarla. Bir render worker cache'den SMB'yi, manager'dan render-manager job protokolünü, monitoring host'undan monitoring telemetrisini ve operatör bastion alt ağından SSH'yi kabul eder. Diğer worker'lardan gelen bağlantılar dahil her şey reddedilir. Bir compromise edilmiş worker komşusunu probe edemez çünkü komşu bağlantıyı kabul etmeyecektir — Tier-1 edge bu hipotetik durumda yenildi ve Tier-2 host firewall, yenilmemiş ikinci hattır.

Windows düğümlerinde host firewall, eşdeğer kurallarla yapılandırılmış Windows Defender Firewall with advanced security'dir. Gelen RDP, acil destek için dar bir operatör alt ağına kısıtlanmıştır; müşterinin remote-desktop protokolü (Moonlight veya eşdeğeri için ayrılmış bir streaming port'u) yalnızca müşterinin WireGuard peer adresinden izin verilir; diğer her şey reddedilir. Use case için — aynı şekilde yapılandırılmış bir makine filosunda küçük bir ruleset uygulamak — Windows Defender Firewall tam yeterlidir ve yönetim yüzeyi Group Policy ile entegre olur.

Grup üyeliği policy birimidir. Düğümler role ve müşteriye göre gruplandırılır: customer-A worker'ları bir grup, customer-B worker'ları başka, operatör yönetim düğümleri üçüncü, cache ve depolama dördüncü. Cross-grup bağlantılar açık bir kural gerektirir ve varsayılan olarak reddedilir. Bir customer-A worker, customer-B'nin cache'ini SMB-mount edemez, customer-B'nin workstation'ına RDP edemez ve bir customer-B manager'dan job çekemez — uygulama katmanı bunu uyguladığı için değil, host firewall TCP handshake'in tamamlanmasına izin vermediği için.

Host firewall kuralları, her düğümde versiyon kontrollü, gözden geçirilebilir ve tutarlı olmaları için configuration management ile yönetilir. Yirmi düğümden birinde yanlış yapılandırılmış bir firewall inceleme ile tespit edilmesi zor, drift detection ile yakalanması kolaydır.

WireGuard uçtan uca şifreleme

Bir bina sınırını aşan her bağlantı WireGuard ile şifrelenir. Artist workstation'ları cluster gateway'e WireGuard tüneller. Site-to-site bağlantılar gateway'ler arasında WireGuard tüneller. Operatör SSH oturumları operatörün laptop'undan cluster bastion'a WireGuard tüneller. Bir bina içindeki iç cluster LAN'ı WireGuard şifrelenmiş değildir — bu trafik kontrol ettiğimiz bir odadaki bir switch üzerindedir — ancak binayı terk eden her şey şifrelenir.

WireGuard'ın buradaki çekiciliği kriptografi ile hiç ilgisi olmayan bir özelliktir: plaintext fallback yoktur. WireGuard cipher suite'leri müzakere etmez, algoritmaları runtime'da seçmez ve "bu peer daha eski bir cipher istedi, o yüzden uyalım" kod yolu yoktur. Her tünel key exchange için Curve25519, data plane için ChaCha20-Poly1305, hashing için BLAKE2s ve message authentication için Poly1305 kullanır. Cipher seçimi protokol seviyesinde sabittir. TLS-style müzakere edilen protokollere yapılan anlamlı bir saldırı sınıfı — downgrade, weak-cipher selection, broken-cipher legacy fallback — uygulanmaz çünkü protokol o saldırıların hedeflediği müzakere adımına sahip değildir.

Peer başına anahtarlar ikinci özelliktir. Her peer'ın kendi public key'i vardır ve hub her peer'ı key'ine ve atanmış AllowedIPs'ine göre açıkça izin verir veya reddeder. Paylaşılan secret yok. Bir workstation'ın private key'i sızarsa, hub tarafı düzeltme o tek peer'ı kaldırmak ve o tek workstation için yeni bir keypair reissue etmektir; diğer her peer rahatsız edilmeden çalışmaya devam eder. Forward secrecy üçüncü özelliktir: WireGuard session key'leri düzenli olarak döner ve long-term key'ler yalnızca ilk handshake için kullanılır. Trafiği kaydeden ve sonra bir long-term key'i compromise eden bir saldırgan kaydedilen trafiği decrypt edemez çünkü efemeral değişimden türetilen session key artık var değildir.

Kernel seviyesinde uygulama dördüncü özelliktir ve mimarinin operasyonel olarak ölçekte tolere edilebilir olup olmadığını belirler. WireGuard 5.6'dan beri mainline Linux kernel'dedir. Tipik bir Xeon gateway'de kernel WireGuard tek haneli CPU yüzde maliyetinde peer başına gigabit sınıfı throughput'u sürdürür. Aynı zamanda routing, firewall ve DNS yapan bir gateway için kernel-versus-userspace crypto, rahat bir kutu ile doymuş bir kutu arasındaki farktır.

En az ayrıcalık erişim örüntüleri

Cluster içindeki her hesap, işi için minimum ayrıcalıklara sahiptir ve operatör rolleri tek bir rolün her şeyi yapamayacağı şekilde ayrılmıştır. İşlettiğimiz deployment'larda dört hesap sınıfı önemlidir.

Müşteri remote-desktop hesapları kendi verilerine ve DCC ortamına erişim ile müşterinin workstation yüzeyine login olur. Altta yatan işletim sistemine shell erişimleri yoktur. Müşteri remote-desktop protokolü aracılığıyla DCC'yi sürer, render'lar submit eder, output'ları indirir ve OS yönetim katmanına asla dokunmaz. Compromise edilmiş bir müşteri hesabı OS-level lisans haklarına, lisans sunucusu parolalarına veya paylaşılan cluster altyapısına ulaşamaz.

Operatör DevOps hesapları bastion aracılığıyla Linux düğümlerine SSH erişimine sahiptir. Bastion erişimi operatörün önce WireGuard üzerinden, sonra hardware-backed bir key ile bastion'a, sonra hesap başına bir key ile hedef düğüme kimlik doğrulamasını gerektirir. İki faktörlü kimlik doğrulama bastion'da zorlanır. Her SSH oturumu, operatörün kendi hesabının değiştiremeyeceği veya silemeyeceği merkezi bir audit log'a kaydedilir — başlangıç zamanı, kaynak adresi, hedef düğüm, süre ve komut geçmişi.

Monitoring agent'ları her düğümde topladıkları metriklere read-only erişimi olan ayrı bir hizmet hesabına sahiptir. Keyfi komutlar çalıştıramaz, uygulama verilerini okuyamaz veya kendi log dosyaları dışında herhangi bir kalıcı konuma yazamazlar. İlke, gözlemin değişiklik haklarını gerektirmemesi gerektiğidir. Depolama erişimi cache ve NAS katmanında SMB ACL'leri tarafından zorlanır: cache'i mount eden bir customer-A worker'ı yalnızca customer-A'nın dizin ağacını görür; SMB sunucusu bunu worker'a güvenmek yerine dosya sistemi seviyesinde uygular.

En önemli rol ayrımı operatör ile müşteri arasındakidir. Operatör, müşterinin açıkça yetkilendirmesi gereken audit edilmiş bir destek oturumu dışında müşteri workstation'larına remote-desktop erişimine sahip değildir. Müşterinin operatörün altyapısına OS-level erişimi yoktur. Bu sınır — WireGuard katmanında (ayrı peer yapılandırmaları), host firewall katmanında (ayrı erişim kuralları) ve uygulama katmanında (ayrı kimlik doğrulama realm'leri) zorlanan — müşterinin workload'ının yalnız kendisinin olduğuna güvenmesini sağlayan sınırdır.

Müşteri izolasyonu: multi-tenant versus dedicated cluster

Müşteri izolasyonunun iki pratik uygulaması vardır. Multi-tenant SaaS altyapısı birçok müşterinin job'larını paylaşılan bir filo üzerinde işletir ve onları OS seviyesinde izole eder — ayrı kullanıcı hesapları, dosya sistemi yolları, işlem grupları ve lisans check-out scope'ları. Dedicated cluster altyapısı bir müşterinin job'larını sözleşme süresi boyunca o tek müşteriye tahsis edilmiş donanım üzerinde işletir; başka bir müşterinin işlemleri, hesapları veya verileri aynı makinelere dokunmaz.

Multi-tenant izolasyon varsayılandır ve çoğu workload için doğru seçimdir — ekonomi daha iyidir ve işlem seviyesi izolasyon, dosya sistemi ACL'leri ve yukarıdaki host firewall kurallarıyla birleşince pratikte önemli olan cross-customer erişim örüntülerini önler. Dedicated cluster izolasyon, workload'un değeri, düzenleyici ortam veya sözleşmesel yükümlülükler daha güçlü bir sınır gerektirdiğinde doğru seçimdir. Motivasyon tehdit modeli: ya OS seviyesi izolasyonun henüz bilmediğimiz bir güvenlik açığı varsa, ya da operatörün kendi iç erişimi saldırı vektörünün kendisiyse? Dedicated donanımda yanıtlar fizik tarafından sınırlandırılır — müşterinin verileri müşterinin disklerinde yaşar, işlemler müşterinin CPU ve GPU'larında çalışır, müşterinin WireGuard hub'ı yalnızca peer'larına hizmet eder ve operatör erişimi oturum başına açık yetkilendirme gerektirecek şekilde yapılandırılabilir. Bir risk sınıfı "operatörün multi-tenant uygulamasına güvenmek"ten "müşterinin kendi donanım sınırına güvenmek"e geçer.

Customer-owned-credentials modeli — BYOC, müşterinin DCC lisans hakları ve asset-store credential'larının müşteri tarafından girildiği ve operatör tarafından asla görülmediği — dedicated cluster ile doğal eşleşmedir; tam model için customer-owned credentials yazısına bakın. Dedicated donanım artı customer-owned credentials, operatörün altyapıyı işlettiği ancak kimlik doğrulama materyalini, kaynak dosyaları veya proje verilerini görmediği anlamına gelir. Operatörün rolü "müşterinin verilerine erişimi olmak ve onları kullanmamayı seçmek" yerine "altyapıyı sağlıklı tutmak" olur.

Dedicated yerine multi-tenant seçmek workload'a özgüdür. Müşterileri üç koşuldan biri mevcut olduğunda dedicated seçerken görürüz: müşterinin legal veya compliance ekibi tarafından yazılı olarak belirlenmiş bir IP hassasiyet eşiği; gösterilebilir per-müşteri veri izolasyonu gerektiren bir düzenleyici çerçeve; veya maliyet farkının izolasyon avantajının baskın olmasına yetecek kadar küçük olduğu bir ölçek eşiği. Ayrı bir makale SaaS-versus-dedicated-cluster karar çerçevesini daha derinlemesine kapsar.

Compliance readiness (sertifikasyon iddiaları olmadan)

Önce dürüst ifşa: Super Renders Farm şu anda SOC 2 sertifikalı değildir, şu anda ISO 27001 sertifikalı değildir ve bir compliance reviewer'a "sertifikamız var, kanıt olarak alabilirsiniz" şeklinde temsil edeceğimiz başka bir resmi bilgi güvenliği sertifikasına sahip değildir. Kendi compliance programı tedarikçilerinin sertifikalı olmasını gerektiren herhangi bir müşteri bunu sözleşme imzalamadan önce bilmelidir.

Sağladığımız şey, bir müşterinin compliance programını inceleyen bir denetçinin inceleyebileceği teknik yapı taşlarından oluşan bir settir — bu makalede açıklanan mimarinin bileşenleri, SOC 2 ve ISO 27001'in teknik katmanda paylaştığı kontrol aileleri merceğinden görülüyor.

At-rest ve in-transit şifreleme. Müşteri ile cluster arasında ve binaları aşan cluster düğümleri arasında transit halindeki veriler WireGuard (Curve25519 + ChaCha20-Poly1305) tarafından şifrelenir. Cache ve depolama katmanındaki at-rest veriler, müşteri talep ettiğinde native OS encryption-at-rest özelliklerini kullanır; bu sözleşme başına yapılandırılabilirdir çünkü tradeoff'lar workload'a göre değişir. SMB3, cross-site trafikte in-transit şifrelemeyi gerektirecek şekilde yapılandırılmıştır.

Audit trail yeteneği. SSH oturum log'ları kaynak, hedef, süre ve komut geçmişi ile operatör hesaplarının değiştiremediği bir log host'a kaydedilir. WireGuard handshake log'ları her peer bağlantı denemesini kaydeder. Render job log'ları müşteri başına submission zamanı, parametreler, completion durumu ve kaynak kullanımını kaydeder. Bu log'lar talep üzerine müşterinin denetçisi için export edilebilir.

Erişim kontrolü ve segregasyon. Tier-1 + Tier-2 firewall modeli segregasyon kontrolüdür. Operatör-versus-müşteri rol ayrımı role tabanlı erişim kontrolüdür. Dedicated cluster modelindeki per-müşteri firewall grup üyelikleri müşteri izolasyon kontrolüdür. Her biri metin olarak bağımsız audit edilebilirdir. Veri imhası sözleşme sonunda dokümante edilmiş bir prosedür izler — dosya seviyesi silme, boş alan üzerine yazma ve operatör tarafından imzalanmış neyin ne zaman ve kim tarafından imha edildiğini kaydeden bir tanıklık mektubu. Tanıklık, müşterinin compliance programının kanıt olarak dosyaladığı artifaktdır.

Ağ monitoring. Cluster gateway'de flow logging ve her düğümde host seviyesi monitoring işletir. Bir SOC-2 "continuous monitoring" hedefinin gerektireceği seviyede sürekli network intrusion detection iç roadmap'tedir ancak şu anda dağıtılmamıştır.

Önemli olan çerçeveleme: operatörün altyapısı müşterinin compliance programının bir bileşenidir, programın kendisi değil. SOC 2 veya ISO 27001 peşinde koşan bir müşteri kontrollerinin tamamı üzerinde değerlendirilir; bunlardan rendering tedarikçisi bir input'tur. Bizim işimiz müşterinin programının güvenebileceği yapı taşları sağlamak ve hangi kontrollerin olgun, kısmi veya henüz scope'ta olmadığı konusunda dürüst olmaktır.

Tehdit modeli

Tehdit modeli içermeyen mimari belgeleri, mimarinin her şeye karşı savunma yaptığını ima etme eğilimindedir, ki bu asla doğru değildir. Bu mimarinin ele aldığının scope'u sınırlıdır; ele almadığı arızalar gerçektir ve açıkça adlandırmak değerlidir.

Mimari neye karşı savunma yapar. Dış scanning ve probing: Tier-1 default-deny duruşu ve WireGuard'ın authenticate-before-accept davranışı, cluster'ın kimliği doğrulanmamış bir scan'e tek yanıtının sessizlik olduğu anlamına gelir — fingerprint'lenecek banner yok, saldırılacak versiyon dizesi yok, brute-force'lanacak auth prompt yok. Tek düğüm compromise'inden sonra yanal hareket: Tier-2 host firewall, compromise edilmiş bir worker'ın komşularını tarayamayacağı veya pivot yapamayacağı, management plane'e veya operatör bastion'una ulaşamayacağı anlamına gelir. Blast radius bir düğüm artı düğümün meşru erişimi olduğu şeylerdir — anlamlı, ancak cluster-wide değil. Müşteriye karşı kullanılan operatör credential hırsızlığı: customer-owned credentials ile dedicated cluster üzerinde operatör müşterinin lisans haklarını, asset-store credential'larını veya proje decryption key'lerini tutmaz, bu nedenle operatörün credential store'unun compromise edilmesi müşteri auth materyalini ifşa etmez. Operatör personeli aracılığıyla veri exfiltration'ı, anlamlı ancak mutlak olmayan şekilde: operatör SSH erişimi audit edilmiş bastion oturumlarını, hardware-backed key'leri ve oturum başına yetkilendirmeyi gerektirir, kötü niyetli insider senaryosunun maliyetini önemli ölçüde yükseltir ancak sıfıra indirmez.

Mimari neye karşı tam savunma yapmaz. Supply-chain saldırıları: işletim sistemleri, DCC'ler, plugin'ler, render engine'leri ve kernel'in kendisi operatörden başka taraflarca yazılmış yazılımdır; azaltabiliriz (patch yönetimi, host hardening, compromise edilmiş bir binary'nin neye ulaşabileceğini sınırlayan segmentasyon) ancak ortadan kaldıramayız. Supply-chain riski çözdüğümüz bir kategori değil, tüm endüstri ile paylaştığımız bir kategoridir. Admin erişimi olan insider tehditleri: bastion erişimi, audit-log erişimi ve bu ayrıcalıkları kötüye kullanma niyeti sürekli olan bir operatör audit log'lar, iki faktörlü kimlik doğrulama, rol ayrımı ve per-müşteri dedicated cluster sınırı ile sınırlandırılmıştır — ancak ortadan kaldırılmamıştır. Operatör işe alımı, arka plan kontrolleri ve müşterilerin kendilerinin gözden geçirebileceği audit-trail görünürlüğü bunu ele alan kontrollerdir. Müşteri credential hijyeni: workstation compromise edildiği için müşterinin WireGuard private key'i sızarsa, saldırgan müşterinin sahip olduğu erişime sahiptir; operatör anormal örüntüleri algılayabilir ve peer'ı devre dışı bırakabilir ancak sızıntıyı önleyemez.

Mimari büyük risk kategorilerini kaldırır ve diğerlerini yönetilebilir seviyelere indirir; her kategoriyi kaldırmaz ve aksini öneren herhangi bir tedarikçi temsili şüpheyle incelenmelidir.

Sık Sorulan Sorular

Q: WireGuard enterprise render farm kullanımı için production-grade midir? A: WireGuard %5.6 sürümünden (Mart 2020) beri mainline Linux kernel'dedir, büyük altyapı operatörleri tarafından production'da kullanılır ve protokolü Tamarin prover ile resmi olarak doğrulanmıştır. Kriptografik primitifler (Curve25519, ChaCha20-Poly1305, BLAKE2s, Poly1305) güvenlik açısından hassas birçok sistemde kullanılan modern, peer-reviewed seçimlerdir. render farm taşıma için — uzun süreli tüneller, büyük akışlar, küçük operasyonel yüzey — yıllardır protokol seviyesinde olaylar yaşamadan işlettiğimiz production seçimidir.

Q: render farm tedarikçimiz compromise edilirse, verilerim ifşa olur mu? A: Multi-tenant modelinde, operatör altyapısının compromise edilmesi operatör sistemlerinin erişimi olan verileri yukarıdaki müşteri izolasyon kontrollerine göre ifşa edebilir. Customer-owned credentials ile dedicated cluster modelinde operatör müşterinin kimlik doğrulama materyalini tutmaz ve müşterinin verileri müşteriye tahsis edilmiş donanımda yaşar — operatörün paylaşılan altyapısının compromise edilmesi dedicated-cluster müşteri verilerini otomatik olarak ifşa etmez çünkü dedicated cluster ayrı bir sınırdır. Dedicated-plus-BYOC yüksek IP hassasiyetli workload'lar için en güçlü pratik cevaptır.

Q: Bir compliance review için audit log'lar sağlayabilir misiniz? A: Evet. SSH oturum log'ları, WireGuard handshake log'ları, render-job log'ları ve firewall flow log'ları, sözleşmede tanımlanan saklama süresine tabi olarak talep üzerine müşterinin denetçisi için export edilebilir. Export formatı denetçinin ihtiyaç duyduğu formattır (en yaygın olarak CSV veya JSON). Log host'una read-write erişim sağlamayız; export modeli audit trail bütünlüğünü korurken müşteriye ihtiyaç duyduğu kanıtı verir.

Q: Sözleşme sonu veri imhası nasıl doğrulanır? A: Dosya seviyesi silme, ilgili depolama cihazlarında boş alan üzerine yazma ile takip edilir, sonra scope'taki cihazları, tarih ve saati, prosedürü ve dahil olan personeli kaydeden operatör tarafından imzalanmış bir tanıklık mektubu. Bunu gerektiren sözleşmeler için, imha müşterinin temsilcisi tarafından tanıklık edilebilir. Tanıklık müşterinin compliance programının kanıt olarak dosyaladığı artifaktdır.

Q: Kendi personelinizden insider tehditleri ne olacak? A: Insider tehdidi rol ayrımı, bastion'da iki faktörlü kimlik doğrulama, operatör hesaplarının değiştiremediği audit log'lar ve per-müşteri dedicated cluster sınırı ile azaltılır. Sıfıra indirilmez ve bunu dürüstçe söylüyoruz. Müşterinin kendisinin talep üzerine audit log'ları incelemesi, insider kötüye kullanımına karşı en etkili kontrollerden biridir — müşteriyi operatör personelinin gerçekte ne yaptığı konusunda döngüye sokar.

Q: SAML veya single sign-on entegrasyonunu destekliyor musunuz? A: Müşteri tarafı SSO iç roadmap'tedir ve bugün genellikle mevcut bir özellik değildir. Kendi compliance nedenleriyle SSO'ya ihtiyaç duyan müşteriler bunu engagement scoping sırasında dile getirmelidir; bazı entegrasyonlar müşterinin identity provider'ının cluster'ın auth katmanına dokümante edilmiş bir yol üzerinden köprülenebildiği per-engagement bazında yapılmıştır.

Q: SOC 2 veya ISO 27001 denetçim mimarinizi inceleyebilir mi? A: Evet. Yukarıda ifşa edildiği gibi kendimiz sertifikalı değiliz, ancak müşteri denetçilerinden gelen vendor-review anketlerine ve mimari review taleplerine yanıt veriyoruz. Bu makalede açıklanan teknik yapı taşları, denetçinin yazılı yanıtlarımızda göreceği aynı yapı taşlarıdır; yapılandırmalar metin olarak audit edilebilirdir. Sağlayamayacağımız şey kendi sertifika belgemizdir çünkü şu anda bir tane tutmuyoruz.

Q: Intrusion detection kapsamınız nedir? A: Tier-1 edge'de flow logging ve her düğümde host seviyesi monitoring bugün dağıtılmıştır. Bir SOC-2 "continuous monitoring" hedefinin gerektireceği seviyede sürekli network intrusion detection iç roadmap'tedir ancak şu anda production'da değildir. Kendi compliance programı continuous-IDS kontrolü gerektiren müşteriler, gap'i kendi risk toleranslarına karşı değerlendirmelidir.

Bu güvenlik modelinin üzerine oturduğu ağ mimarisi için cross-country render farm mimari deep-dive'a bakın. Dedicated cluster ile eşleşen customer-owned-credentials modeli için BYOC yazısına bakın. Operasyonel deployment için 20 düğüm dedicated GPU render farm kılavuzumuza bakın. Satın alma karar çerçevesi için SaaS versus dedicated cluster karşılaştırmasına ve dedicated GPU cluster rental landing'ine bakın.