30 kişilik şirket için zero trust: VPN, ters proxy'ler ve canlıya ulaşan yama

Zero trust, güvenlik departmanı olan bir bankanın konusu gibi geliyor. Bu hafta Forrester, Red Hat ve Docker bunu yazdı ve her birinde satır aralarında aynı soru var: güvenlik departmanı olmayan, sunucudan sorumlu tek bir kişinin olduğu şirket bundan ne yapmalı. Birkaç şirkette o kişi benim. Aşağıda bende bundan ne çıktığı.

Ne çıktı

Forrester 23 Ekim'de “bira bütçesiyle Zero Trust” konusuna geri döndü ve metne “minimum uygulanabilir zero trust” adını verdi. Girişten muhatap belli: referans mimarileri ve BeyondCorp'u okumuş, olgunluk modellerinden birinde kendini bulmaya çalışmış ve nereden başlayacağını anlamamış kişi. Forrester'ın reçetesini aktarmayacağım, kendiminkini söyleyeceğim.

Red Hat 22 Ekim'de OpenShift'te zero trust serisinin dördüncü bölümünü yayınladı. Oradaki ifade yerinde: zero trust'ı tek cümleyle anlatmak kolay, “asla güvenme, her zaman doğrula”; tekrarlanabilir yapmak zor. Bu cümle pazartesi sabahı neyin kurulacağını ve denetçiye kontrolün çalıştığının nasıl gösterileceğini söylemiyor. OpenShift 30 kişilik şirket için doğru ölçek değil, ama pazartesi sorusu doğru.

Üç gün önce, 19 Ekim'de Red Hat yamalar hakkında yazdı ve bence haftanın ana metni bu. Yama günler içinde hazırdı, canlıya ise aylarca gitti. Müşterilerle konuşmalarda “bilmiyorduk” cevabı neredeyse hiç gelmiyor. Neredeyse her zaman gelen cevap “biliyorduk ama canlıya taşımak istismar penceresinden uzun sürdü”. Bu gecikmeyi en az değer verilen risk ölçütlerinden biri olarak adlandırıyorlar: AI istismara kadar geçen süreyi saatlere sıkıştırıyor, pek çok kuruluş ise yeniden derleme ve doğrulamaya hâlâ 40 ila 90 gün harcıyor.

Docker 21 Ekim'de Secure Software Factory'yi anlattı: AI ajanlarının kodu değiştirdiği, testleri çalıştırdığı ve sonucu insana teslim ettiği ekipler için referans mimari. Docker, Snyk ve Keycard'ın temmuzda yayınladığı Agent Baseline'dan büyüdü. Onlara göre ekipler hız kazanıyor ve yanında veritabanlarını silen ve onaysız canlıya push yapan ajanlar alıyor. Ana fikir: ajanın özerkliği ne kadar büyükse ona o kadar az güvenilebilir ve kontrol, çalıştığı ortamda yaşamalı. Zero trust'taki düşüncenin aynısı, yalnızca çalışan yerine program için.

Manufacturing Today 22 Ekim'de üretimler için sekiz siber güvenlik pratiği sıraladı: bağlı tezgâhlar ve endüstriyel nesnelerin interneti verimlilik getiriyor ve aynı zamanda yeni açıklar. Listenin kendisi duyuruda yok, aşağıdaki benimki.

Yüklenicinin her şeyi gördüğü üretim

Bir üretim şirketini ele alalım. Atölyede bir ağ var; içinde tezgâhlar, 1C sunucusu, çizimlerin durduğu ağ klasörleri ve lazeri ayarlamaya gelen yüklenicinin dizüstü bilgisayarı. Wi-Fi'a bağlandı ve artık içerideki her şeye erişebiliyor: SMB üzerinden klasörler, veritabanı, yazıcılar. Ağ “içeridekiler bizden” ilkesiyle kurulmuş.

Sonuç: “ağın içinde olmak” artık erişim hakkı değil. Hakkı, belirli bir kişiye ya da programa belirli bir servis verir ve onu servisten sorumlu olan kişi verir.

Bende nasıl kurulu

2023'ten beri çalıştığım ABD'deki hidroponik çiftlikte 2 sahada 25 kontrolcü var. Saha ağlarının gri IP'leri var, genel adres yok. Google Cloud'daki Debian sunucusunun kontrolcüleri görmesi için ters proxy'ler, NAT, firewall ve VPN kurdum. Birlikte bu, sunucunun bütün kontrolcülere erişebildiği ama dışarıdan ulaşılamayan tek bir ağ. Adresleri ve ağ ürünlerini açıklamıyorum, bu müşterinin özel altyapısı.

Şu anda 30'dan fazla kişinin çalıştığı ABD'deki PDR şirketinde güvenlik soruları bana geliyor. Sistemin birkaç koruma katmanı ve yedeği var. Sunucuya, VPN'e, ağ ekipmanına ve telefon sistemine kendim bakıyorum. Dünyada büyük bir sızıntı olduğunda bizi ilgilendirip ilgilendirmediğine bakıyorum. Kendi sunucunun kurulduğu 2022'den beri geri yükleme gerektiren ciddi bir arıza olmadı.

Excel spesifikasyonlarından parça hesaplaması yaptığım üretim şirketinde programın web sürümü yalnızca şirket ağının içinde açık ve ACL ile sınırlı. SMB üzerindeki ağ klasörlerine program VPN üzerinden gidiyor. Hesaplama mantığının kendisi sunucuda yaşıyor ve ona erişim olmadan istemci tarafı hiçbir şey hesaplamıyor: müşteri programın alınıp götürülememesini istiyordu.

Benim ölçeğimde zero trust işte bu: platformsuz ve departmansız, VPN, ters proxy'ler ve belirli bir servis için verilen haklarla.

30 kişilik şirkette ne yapardım

İnternete açık her şeyin listesini çıkarırdım: site, API, telefon sistemi, uzak erişim, kameralar, yazıcılar. Müşteriler için olmayan her şeyi VPN'in ya da ters proxy'nin arkasına alırdım.

Her servis için ona kimin ve neden gittiğini yazar, erişimi tam olarak o kişilere ve programlara verirdim. Yüklenici, iş süresi boyunca tek bir servise erişim alır.

Red Hat'in önerdiği gibi tek bir sayıyı ölçerdim: yamanın çıkışından canlıda çalışmasına kadar kaç gün geçiyor. Haftalarsa nerede takıldığını çözerdim: onayda mı, derlemede mi, yoksa yapacak kimse olmadığı için mi.

Yedekten geri yüklemeyi prova ederdim.

Geliştirmede AI asistanlarınız varsa onlara yükleniciyle aynı hakları verirdim: sınırlı bir ortam ve canlıdan hiçbir şey.

Durumu saklayan ve izinleri kontrol eden ortak merkez olarak sunucu üzerine: Sunucu: veri, erişim ve sürecin yürütülmesi. Yayınlanabilen ve geri getirilebilen altyapı: DevOps ve altyapı. Bu yazıdaki ağlar hidroponik çiftlik ve PDR şirketiyle teknik ortaklık vakalarında anlatılıyor. Yakın yazılardan: PHP2Shell ve kendi sunucularını kontrol etmek, iş mantığındaki açık ve küçük işletmeye neden Docker Compose yetiyor; daha önce kapalı devre ve internetsiz çalışma üzerine yazmıştım. Erişim listeniz yazılı değilse, şu anda her şeyin nasıl kurulu olduğunu anlatın, nereden başlayacağınızı önereyim. Görevi konuşalım.