2026'da CyberChef Nasıl Self-Host Edilir: Güvenli Erişim, Stateless Hosting ve Güncellemeler
Docker, portlar, kalıcı veriler, TLS, güvenlik, yedeklemeler ve production kullanımını engelleyen sorunları kapsayan pratik bir CyberChef self-hosting rehberi. 2026.
En kısa CyberChef demosu, bir process'in 80 portunu dinlediğini kanıtlar. Production için daha güçlü kanıtlar gerekir. Container değiştirildikten sonra bile şu senaryoyu başarıyla tamamlamalıdır: çok adımlı bir recipe oluşturun, dışa aktarın, temsili bir dosyayı işleyin ve çıktının hash değerinin bilinen bir değerle eşleştiğini doğrulayın.
CyberChef belirli bir amaçla kullanıma alınıyor: encoding, decoding, parsing ve cryptography için browser workbench. En yaygın deployment tuzağı, server sağlıklı olsa bile büyük işlemlerin browser memory'sini tüketmesidir. Bu nedenle public URL yönetimi ve kalıcı state, image'ın başlatılması kadar önemsenmelidir.
En küçük uygulanabilir CyberChef topolojisini seçin
Kullanışlı bir CyberChef diyagramında public route, private port 80, state sınırı ve tüm destek gereksinimleri gösterilir. Hangi okların credentials, hangilerinin sıradan kullanıcı trafiği taşıdığını belirtin. Standart CyberChef build'i veritabanına veya ayrı bir persistent runtime service'e ihtiyaç duymaz. Web container'ını değiştirilebilir tutun; gelecekteki authentication, collaboration veya storage bileşenlerini ayrı ve belgelenmiş bir sınırın arkasına yerleştirin.
Diyagramı gerçek bir işlemle doğrulayın: çok adımlı bir recipe oluşturun, dışa aktarın, temsili bir dosyayı işleyin ve çıktının hash değerinin bilinen bir değerle eşleştiğini doğrulayın. Standart static deployment'ta asıl baskı, container-side compute yerine büyük recipe'ler için browser memory ve CPU kullanımından gelir; tüm HTTP request'lerini eşit kabul etmek yerine bu yolu izleyin.
İlk production'a uygun instance'ı çalıştırın
Container'ı gerçeğin kaynağı olarak değil, değiştirilebilir bir runtime olarak kullanın.
docker run -d \
--name cyberchef \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
ghcr.io/gchq/cyberchef:latest
Dış erişime açmadan önce local gereksinimi doğrulayın: standart client-side build için veritabanı gerekmez. Dışa açmadan önce container user'ını, yazılabilir path'leri ve bağlı listener'ı inceleyin. Şu işlemin tamamını çalıştırın — çok adımlı bir recipe oluşturun, dışa aktarın, temsili bir dosyayı işleyin ve çıktının hash değerinin bilinen bir değerle eşleştiğini doğrulayın — ve sonucu üreten tam image referansını kaydedin.
CyberChef'i server dışından test edin
Static interface'ı güvenilir bir HTTPS origin üzerinde yayınlayın. Seçilen hostname'i container'ın 80 numaralı portuna yönlendirin, original host ve HTTPS scheme bilgilerini forward edin ve ikinci bir direct origin yayınlamaktan kaçının.
CyberChef'i temiz bir external client üzerinden test edin. Ingress hatasını bilinen application sınırından ayırın — server sağlıklı olsa bile büyük işlemler browser memory'sini tüketebilir. Certificate, DNS veya 502 hatası routing'e aittir; CyberChef'e ulaşan ve daha sonra başarısız olan bir request ise application state'ine, capacity'ye veya destek gereksinimine aittir. Özel domain TLS rehberi ilk grubu ele alır.
CyberChef'teki tüm kalıcı byte'ları bulun
Standart CyberChef container'ının zorunlu bir application-data mount'u yoktur. Yine de recovery set'i açıkça tanımlanmalıdır: application data yoktur; deployment configuration ve image pin korunmalıdır. Deployment'ı stateful göstermek için boş bir volume oluşturmayın; bunun yerine tam image referansını ve gözden geçirilmiş configuration'ı koruyun.
CyberChef'i boş bir host üzerinde yeniden oluşturun ve acceptance transaction'ı çalıştırın. Pinned static build yeniden oluşturulabildiğinde ve dışa aktarılan bir recipe aynı bilinen çıktıyı ürettiğinde recovery başarılıdır. Bağlı herhangi bir database veya collaboration service kendi application-consistent backup plan'ini izlemeli, değiştirilebilir web container'ı ise code'dan yeniden oluşturulmalıdır. Git'ten production'a deployment rehberi bu reproducible sınırı açıklar.
Bilinen ve sorunsuz image için bir checksum veya digest tutun ve güncellemelerden sonra yeniden test edin. Stateless service için başarılı bir rebuild, restore testidir; external state için CyberChef runbook'u ayrı owner'ı ve recovery procedure'ünü belirtmelidir.
CyberChef'in değerli kısmını koruyun
CyberChef'i daha güvenli görünür kılmak için sahte bir environment secret eklemeyin. Asıl konu, hassas materyalin değiştirilmiş veya güvenilmeyen bir image üzerinde işlenmesidir. Bu nedenle operator'ler credentials, capture'lar veya encoded evidence yapıştıracaksa yalnızca official ya da reproducibly built bir image yayınlayın.
Gerektiğinde public route'u kısıtlayın, image digest'ini doğrulayın ve container'ı ihtiyaç duymadığı host mount'ları veya privilege'larla çalıştırmayın. Standart static deployment'ta container-side compute yerine büyük recipe'ler için browser memory ve CPU kullanımına göre limitler uygulayın. Log'lar, CyberChef tarafından işlenen hassas input'u saklamadan hataları ve süreleri kaydetmelidir.
Sağlıklı görünen bir CyberChef'i teşhis edin
Şu regression transaction'ını çalıştırırken standart static deployment'ta container-side compute yerine büyük recipe'ler için browser memory ve CPU kullanımını ölçün: çok adımlı bir recipe oluşturun, dışa aktarın, temsili bir dosyayı işleyin ve çıktının hash değerinin bilinen bir değerle eşleştiğini doğrulayın. Liveness probe'u basit tutun; conversion veya browser-side işlemler ayrı bir release check'in parçası olmalıdır, böylece ağır bir sample restart loop'u tetiklemez.
Upgrade riski, CyberChef recipe operation'larının ve bundled library'lerin çıktıyı veya compatibility'yi değiştirebilmesidir; bu nedenle pinned build için bir regression test gerekir. Candidate digest'i mevcut image'ın yanında çalıştırın, ikisine de aynı bilinen input'ları verin ve output'ları, header'ları ve timing'i karşılaştırın. Server sağlıklı olsa bile büyük işlemler browser memory'sini tüketiyorsa route'u değiştirmeden önce başarısız request'i ve image referansını koruyun.
CyberChef smoke test'ini release check'e dönüştürün
CyberChef release kaydı “iyi görünüyor” gibi ifadeler yerine gerçek bilgiler içermelidir. Seçilen image digest'ini, configuration checksum'ini, public hostname'i ve şu işlem için timestamp içeren sonucu saklayın: çok adımlı bir recipe oluşturun, dışa aktarın, temsili bir dosyayı işleyin ve çıktının hash değerinin bilinen bir değerle eşleştiğini doğrulayın. Check'in her deployment'tan sonra çalıştırılabilmesi için production dışı sample data kullanın.
İki lifecycle event'ini ayrı ayrı kanıtlayın. Container replacement normal çalışmayı korumalıdır; temiz bir recovery ise pinned static build'in yeniden oluşturulabildiğini ve dışa aktarılan bir recipe'nin aynı bilinen çıktıyı ürettiğini göstermelidir. Check'ler çalışırken standart static deployment'ta container-side compute yerine büyük recipe'ler için browser memory ve CPU kullanımını ölçün ve sonucu bu version için beklenen envelope olarak saklayın.
Geçersiz veya reddedilen bir durumu da test edin: şu sınırla ilişkili resource veya format limitine yakın, zararsız bir input gönderin: server sağlıklı olsa bile büyük işlemler browser memory'sini tüketebilir. CyberChef teşhis edilebilir şekilde başarısız olmalı ve sağlıklı state'in üzerine yazmamalıdır. Geçerli duruma dönün, sample'ı yeniden çalıştırın ve ilgili redacted log'ları ekleyin. Bu artifact'ler, gelecekteki rollback kararına somut kanıt sağlar.
Tekrarlanabilir infrastructure işlerini Dockup'a taşıyın
Stateless CyberChef için Dockup'ın görevi sınırlı ama faydalıdır: pinned image'ı başlatmak, port 80'i private tutmak, HTTPS route'u bağlamak ve storage icat etmeden container'ı değiştirmek. Deployment, Dockup infrastructure'ını veya customer-attached bir server'ı hedefleyebilir.
Application configuration'ı tamamlayın: static interface'ı güvenilir bir HTTPS origin üzerinde yayınlayın. Operator şu local gereksinimi doğrularken Dockup, CyberChef runtime ayarlarını korumalıdır: standart client-side build için veritabanı gerekmez. Şu acceptance action'ını çalıştırın: çok adımlı bir recipe oluşturun, dışa aktarın, temsili bir dosyayı işleyin ve çıktının hash değerinin bilinen bir değerle eşleştiğini doğrulayın. İsteğe bağlı authentication veya external service'ler ayrı configuration ve dependency'ler olarak gösterilmelidir; böylece deployment gerçeği doğru şekilde yansıtır.
Sık sorulan sorular
Production deployment için CyberChef neye ihtiyaç duyar?
CyberChef container'ını tek bir HTTPS origin üzerinden 80 numaralı porta yönlendirin. Standart CyberChef build'i veritabanına veya ayrı bir persistent runtime service'e ihtiyaç duymaz. Çok adımlı bir recipe oluşturup dışa aktaramıyor, temsili bir dosyayı işleyemiyor ve çıktının hash değerinin bilinen bir değerle eşleştiğini doğrulayamıyorsanız CyberChef'i hazır kabul etmeyin.
Hangi CyberChef verileri backup'a dahil edilmelidir?
Standart CyberChef image'ının zorunlu bir application-data mount'u yoktur. Deployment configuration'ını koruyun ve bağlı state'i ayrı olarak yedekleyin; pinned static build yeniden oluşturulabildiğinde ve dışa aktarılan bir recipe aynı bilinen çıktıyı ürettiğinde recovery başarılıdır.
Reverse proxy arkasında CyberChef için HTTPS gerekir mi?
Public CyberChef origin'i için HTTPS kullanın ve port 80'i internal route üzerinde tutun. CyberChef ayarını doğru uygulayın: static interface'ı güvenilir bir HTTPS origin üzerinde yayınlayın. CyberChef için HTTPS, credentials veya kullanıcı içeriğinin aktarım sırasında korunmasını ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.
CyberChef upgrade'i nasıl test edilmelidir?
Candidate CyberChef image'ını mevcut image'ın yanında deploy edin ve acceptance transaction'ı bilinen input'larla tekrarlayın. CyberChef recipe operation'larının ve bundled library'lerin çıktıyı veya compatibility'yi değiştirebilmesi nedeniyle özellikle dikkatli olun; pinned build için bir regression test gerekir. Standart container'da data migration yoktur; bu nedenle output ve compatibility check'leri geçene kadar önceki digest'i saklayın.