Python ile Siber Güvenlik Otomasyonu ve Ağ Güvenliği Scriptleri

Python ile siber güvenlik otomasyonu nedir ve kime yarar?
Python ile siber güvenlik otomasyonu, kendi sistemlerinizi korumak için tekrar eden kontrolleri küçük betiklere devretmektir. Açık port listesi, şüpheli giriş denemesi, süresi dolan sertifika veya bozulan başlık gibi işleri elle değil, zamanlanmış kodla takip edersiniz. Böylece gözden kaçan hata sayısı azalır.
Ben 2012'den beri web siteleri, reklam altyapıları ve sunucular üzerinde çalışıyorum. Bu işin bir yüzü pazarlama, öteki yüzü ise sitelerin ayakta ve güvende kalması. Dolayısıyla bu yazıda anlattığım betikler, müşteri sitelerinde ve kendi sunucularımda savunma amacıyla kullandığım türden örnekler. Saldırı tekniği öğretmiyorum; kendi ağınızı daha iyi görmenizi hedefliyorum.
Yazı özellikle küçük ekipler için: tek başına site yöneten geliştiriciler, ajans teknik sorumluları ve sunucusunu kendisi yöneten işletmeler. Kurumsal SOC ekiplerinin kullandığı büyük ürünlerin yerini tutmaz; ancak bu ürünler olmadan da temel görünürlük kurabileceğinizi gösterir.
Başlamadan önce hangi yasal sınırları bilmelisiniz?
Bu bölümü en başa koyuyorum, çünkü en önemli kısım burası. Bir sisteme sahibinin açık izni olmadan erişmek, taramak veya trafiğini dinlemek pek çok ülkede suçtur. Türkiye'de Türk Ceza Kanunu'nun 243 ile 245. maddeleri bilişim sistemine girme, sistemi engelleme ve verileri bozma gibi fiilleri düzenler. Metnin tamamını Mevzuat Bilgi Sistemi üzerinden okuyabilirsiniz.
Bu nedenle yazıdaki her örneği yalnızca şu ortamlarda çalıştırın:
- Size ait olan ve yönetimi sizde bulunan cihazlar, sunucular ve ev ağınız.
- İşvereninizin veya müşterinizin yazılı izin verdiği sistemler, izin kapsamının içinde kalarak.
- Bu amaçla kurulmuş eğitim laboratuvarları ve kendi sanal makineleriniz.
Ayrıca paylaşımlı hosting, bulut sağlayıcı veya kurum ağı kullanıyorsanız sağlayıcının kullanım koşullarını da okuyun. Bazı sağlayıcılar kendi sunucunuzdan bile dışarıya tarama yapılmasını yasaklar. Kısacası teknik olarak yapabiliyor olmanız, yapmaya hakkınız olduğu anlamına gelmez. Hukuki bir soru işareti varsa kodu değil, bir avukatı çalıştırın.
Neden bu iş için Python seçiyorum?
Python'u seçmemin nedeni hız değil, okunabilirlik. Güvenlik betiğini altı ay sonra açtığınızda ne yaptığını hemen anlamanız gerekir. Python'un sade sözdizimi bunu kolaylaştırır. Üstelik standart kütüphane ağ, dosya, düzenli ifade ve zaman işlemlerini ek kurulum istemeden sunar.
İkinci neden ekosistem. Paket işleme için Scapy, HTTP istekleri için Requests, log ayrıştırma için standart re modülü ve gerektiğinde Pandas elinizin altındadır. Öte yandan Python her iş için doğru araç değildir. Çok yüksek hacimli trafiği gerçek zamanlı incelemek istiyorsanız Suricata veya Zeek gibi özel araçlar daha uygundur.
Pratikte Python ile siber güvenlik çalışması, bu büyük araçların arasındaki boşlukları doldurur. Örneğin bir IDS size alarm üretir, Python betiği ise o alarmı sizin raporunuza, WhatsApp bildiriminize veya bilet sisteminize taşır. Yani Python çoğu zaman yapıştırıcı rolündedir.
Güvenli bir çalışma ortamını nasıl kurarsınız?
Güvenlik betiklerini ana bilgisayarınızın genel Python kurulumuna karıştırmayın. Her proje için ayrı bir sanal ortam açın; python3 -m venv komutu bunun için yeterlidir. Böylece bir paketin sürümü diğer projeyi bozmaz ve hangi bağımlılığın nereden geldiğini bilirsiniz.
Kurulum sırasında dikkat ettiğim noktalar şunlar:
- Paketleri yalnızca resmi PyPI adıyla kurun; harf hatası içeren taklit paketler bilinen bir tedarik zinciri riskidir.
- Sürümleri bir requirements dosyasına sabitleyin ve düzenli olarak güncelleyin.
- API anahtarı, şifre ve token gibi sırları koda yazmayın; ortam değişkeninden veya ayrı bir yapılandırma dosyasından okuyun.
- Betikleri root yetkisiyle yalnızca gerçekten gerektiğinde çalıştırın. Scapy ile ham paket göndermek yetki ister, log okumak çoğu zaman istemez.
- Denemeler için bir sanal makine veya konteyner kullanın; yanlış bir döngü üretim sunucusunu yormasın.
Bu disiplin sıkıcı görünebilir. Ancak güvenlik aracı yazarken kendi aracınızın bir açık haline gelmesi, sahada gördüğüm en ironik hatalardan biridir.
Hangi kütüphane hangi savunma işine uyar?
Aşağıdaki tablo, bu yazıda değindiğim araçları hangi iş için kullandığımı özetliyor. Hepsi savunma amaçlı ve kendi sistemleriniz üzerinde çalışacak şekilde düşünülmüştür.
| Kütüphane | Tipik savunma işi | Yetki ihtiyacı | Dikkat noktası |
|---|---|---|---|
| socket (standart) | Kendi sunucunuzda açık port envanteri | Genelde gerekmez | Zaman aşımı koymazsanız betik takılır |
| Scapy | Kendi ağınızda cihaz keşfi, paket inceleme | Çoğu işlemde root gerekir | Yalnızca izinli ağ segmentinde |
| Requests | Güvenlik başlığı ve yönlendirme denetimi | Gerekmez | İstek sıklığını sınırlayın |
| re ve collections | Log ayrıştırma, sayım, eşik alarmı | Log dosyasını okuma izni | Kişisel veriyi maskeleyin |
| ssl (standart) | Sertifika bitiş tarihi takibi | Gerekmez | Uyarı eşiğini erken tutun |
| hashlib (standart) | Dosya bütünlüğü kontrolü | Dosya okuma izni | Temel özetleri güvenli yerde saklayın |
Tablodaki araçların çoğu standart kütüphanede. Dolayısıyla işe başlamak için büyük bir kurulum yapmanız gerekmez; önce elinizdekilerle küçük bir kontrol yazın, ihtiyaç büyüdükçe dış paket ekleyin.
Kendi sunucunuzda port envanterini socket ile nasıl çıkarırsınız?
Port taraması kelimesi kulağa saldırı gibi gelir, fakat savunma tarafında da temel bir ihtiyaçtır. Sunucunuzda hangi servislerin dışarı açık olduğunu bilmiyorsanız, güvenlik duvarı kuralınızın işe yarayıp yaramadığını da bilemezsiniz. Bu yüzden ben bunu tarama değil, envanter olarak görüyorum.
Mantık basittir. Standart socket modülüyle bir TCP soketi açarsınız, settimeout ile kısa bir zaman aşımı verirsiniz ve connect_ex çağrısıyla kendi sunucunuzun belirli portlarını denersiniz. Dönen değer sıfırsa port açıktır. Ardından sonucu beklenen listeyle karşılaştırırsınız: 22, 80 ve 443 açık olmalı, veritabanı portu ise dışarıdan kapalı olmalı gibi.
Burada önemli olan karşılaştırma adımıdır. Açık portları listelemek tek başına bir şey söylemez; beklenmeyen bir açık port ise gerçek bir bulgudur. Örneğin bir güncellemeden sonra veritabanının yanlışlıkla tüm arayüzleri dinlemeye başlaması, bu basit kontrolle yakalanabilecek türden bir hatadır.
Taramayı yalnızca sahibi olduğunuz IP adreslerine yönlendirin. Hangi adresin size ait olduğundan emin değilseniz IP sorgulama aracı ile önce doğrulayın. Başkasının adres aralığını denemek, iyi niyetle bile olsa sorun yaratır.
Scapy ile kendi ağınızı nasıl görünür kılarsınız?
Scapy, paketleri oluşturup gönderebilen ve yakalayabilen güçlü bir Python kütüphanesidir. Güçlü olduğu için sorumluluk da büyüktür. Ben onu ağırlıkla kendi ofis veya ev ağımda hangi cihazların bulunduğunu görmek için kullanıyorum. Scapy'nin resmi dokümantasyonu temel kullanım için iyi bir başlangıç noktasıdır.
Savunma amaçlı tipik kullanım, yerel ağ segmentinize ARP isteği gönderip yanıt veren cihazların IP ve MAC adreslerini listelemektir. Bu listeyi haftalık saklarsanız ağınıza yeni katılan bilinmeyen bir cihazı fark edersiniz. Örneğin misafir ağına bağlanması gereken bir cihazın ana ağda görünmesi, yapılandırma hatasına işaret eder.
İkinci kullanım pasif dinlemedir. Scapy'nin sniff fonksiyonuyla kendi makinenizden geçen trafiği filtreleyerek izleyebilirsiniz. Ancak burada kişisel verilerin gizliliği devreye girer. İş yerinde çalışanların trafiğini dinlemek, teknik izin olsa bile ayrı bir hukuki değerlendirme ister. Bu yüzden ben pasif dinlemeyi yalnızca kendi test makinelerimde ve sorun giderme sırasında, kısa sürelerle yapıyorum.
Log analizi betiği neleri yakalayabilir?
Bence Python ile siber güvenlik işinin en yüksek getirili alanı log analizidir. Sunucunuz zaten her şeyi kaydediyor; eksik olan, o kayıtları okuyan biri. Basit bir betik bu okuyucu rolünü üstlenir ve size yalnızca dikkat gerektiren satırları gösterir.
Tipik bir log betiğinin yakaladığı durumlar şunlardır:
- Aynı IP adresinden kısa sürede gelen çok sayıda başarısız SSH girişi.
- Web sunucusu logunda wp-login, .env veya yönetim paneli yollarına yoğun istekler.
- Olağan dışı sayıda 404 veya 500 yanıtı; bu bazen tarama, bazen de bozulan bir dağıtım demektir.
- Gece saatlerinde gelen başarılı yönetici girişleri.
- Bilinmeyen kullanıcı ajanları veya boş user-agent ile yapılan toplu istekler.
Böylece binlerce satırlık dosyayı değil, beş satırlık bir özeti okursunuz. Üstelik bu özet, fail2ban gibi araçların yapılandırmasını iyileştirmek için de değerli bir girdi olur: hangi yolların hedef alındığını görünce kurallarınızı ona göre sıkılaştırırsınız.
Başarısız giriş denemelerini nasıl sayarsınız?
Somut bir örnekle anlatayım. Linux sunucularda SSH olayları genellikle auth.log veya journal içinde tutulur. Betik dosyayı satır satır okur, düzenli ifadeyle "Failed password" içeren satırlardan IP adresini çeker ve collections.Counter ile her IP için sayım yapar.
Ardından bir eşik belirlersiniz. Örnek hesap: son bir saatte aynı adresten on başarısız deneme geldiyse bunu raporlarsınız. Bu eşik bir kural değil, başlangıç değeridir; kendi sunucunuzun normal davranışına bakarak ayarlarsınız. Çok düşük eşik gürültü üretir, çok yüksek eşik ise gerçek saldırıyı geç görür.
Dikkat etmeniz gereken iki nokta var. Birincisi, log dosyaları döner; betik yalnızca güncel dosyayı okursa dünkü olayları kaçırır. İkincisi, IP adresi KVKK kapsamında kişisel veri sayılabilir. Bu nedenle raporu paylaşacaksanız adresin son bölümünü maskelemek ve raporu gereğinden uzun saklamamak iyi bir alışkanlıktır.
Bu betiği otomatik engelleme yapacak şekilde büyütmeden önce birkaç hafta yalnızca raporlama modunda çalıştırmanızı öneririm. Böylece kendi ofis IP'nizi yanlışlıkla engelleme riskini görürsünüz.
Web sitenizin güvenlik başlıklarını requests ile nasıl denetlersiniz?
Web sitesi yöneten biri için en pratik otomasyonlardan biri başlık denetimidir. Requests kütüphanesiyle kendi sayfanıza bir GET isteği atar, yanıtın headers sözlüğünü incelersiniz. Requests dokümantasyonu bu kullanımı ayrıntılı anlatır.
Kontrol listeme genellikle şunları koyuyorum:
- Strict-Transport-Security: tarayıcıyı HTTPS kullanmaya zorlar.
- Content-Security-Policy: hangi kaynaklardan betik yüklenebileceğini sınırlar.
- X-Content-Type-Options: nosniff değeriyle tür tahmini hatalarını engeller.
- Referrer-Policy ve Permissions-Policy: gereksiz bilgi ve izin paylaşımını azaltır.
- Server ve X-Powered-By: sürüm bilgisini sızdırıp sızdırmadığını kontrol edersiniz.
Betiği her dağıtımdan sonra çalıştırırsanız bir güncellemenin başlığı sessizce silmesini hemen fark edersiniz. Ayrıca HTTP'den HTTPS'e ve www yönlendirmelerinin doğru çalıştığını da aynı betikle doğrulayabilirsiniz; tek seferlik kontroller için yönlendirme denetleyicisi de iş görür. Yönlendirme zincirleri aynı zamanda SEO'yu etkilediği için bu kontrol iki işe birden yarar.
SSL sertifikası ve alan adı sürelerini otomatik takip etmek mümkün mü?
Evet, üstelik standart kütüphaneyle. ssl modülüyle kendi alan adınıza güvenli bir bağlantı açar, getpeercert ile sertifika bilgisini alır ve notAfter alanından bitiş tarihini okursunuz. Bugünkü tarihle karşılaştırıp kalan gün sayısını hesaplarsınız.
Otomatik yenileme kullanan sitelerde bile bu kontrolü öneririm. Çünkü yenileme sessizce başarısız olabilir; DNS değişikliği, yanlış yapılandırılmış bir doğrulama dosyası veya dolmuş bir disk yenilemeyi durdurabilir. Sahada en sık gördüğüm senaryo budur: herkes otomatik olduğunu sanar, kimse kontrol etmez.
Uyarı eşiğini erken tutun. Örneğin kalan süre belli bir gün sayısının altına indiğinde e-posta veya mesaj gönderirsiniz. Aynı betiğe DNS kayıtlarının beklenen değerlerde olup olmadığını kontrol eden bir adım da ekleyebilirsiniz. Elle kontrol için DNS sorgulama aracı hızlı bir referans sağlar. E-posta tarafında SPF, DKIM ve DMARC kayıtlarını da izlemek isterseniz kurumsal e-posta altyapısı rehberim işinize yarar.
Dosya bütünlüğünü hashlib ile nasıl izlersiniz?
Web sitelerinde en sinsi saldırılardan biri, mevcut bir PHP veya JavaScript dosyasına sessizce kod eklenmesidir. Site çalışmaya devam eder, siz fark etmezsiniz. Dosya bütünlüğü izleme bu tür değişiklikleri yakalamak için basit ama etkili bir yöntemdir.
Yöntem şöyle işler. Önce temiz olduğundan emin olduğunuz bir anda kritik dizindeki her dosyanın SHA-256 özetini hashlib ile hesaplayıp bir temel listeye kaydedersiniz. Ardından betik her çalıştığında özetleri yeniden hesaplar ve temel listeyle karşılaştırır. Değişen, silinen veya yeni eklenen dosyaları raporlar.
Temel listeyi aynı sunucuda, web kök dizininde saklamayın. Saldırgan dosyayı değiştirebiliyorsa listeyi de değiştirebilir. Ben temel listeyi ayrı bir makinede tutuyor ve karşılaştırmayı oradan yapıyorum. Ayrıca her meşru güncellemeden sonra temel listeyi yenilemeyi unutmayın; aksi halde her rapor kendi dağıtımınızı alarm olarak gösterir ve kısa sürede kimse raporu okumaz.
Betikleri ne sıklıkla ve nasıl zamanlamalısınız?
Bir güvenlik betiği yalnızca düzenli çalıştığında değer üretir. Linux'ta cron veya systemd timer, Windows'ta Görev Zamanlayıcı bu iş için yeterlidir. Sıklık, kontrolün türüne göre değişir.
Saha tecrübesine dayalı başlangıç aralığı, garanti değil:
- Başarısız giriş ve log özeti: saatlik veya birkaç saatte bir.
- Port envanteri: günlük ve her yapılandırma değişikliğinden sonra.
- Güvenlik başlığı denetimi: her dağıtımdan sonra ve günde bir kez.
- Sertifika ve DNS kontrolü: günlük.
- Dosya bütünlüğü: kritik dizinler için saatlik, geri kalanı için günlük.
Zamanlamada iki hata sık görülür. Birincisi, betiğin kendi hatalarını sessizce yutmasıdır; betik çökerse hiçbir rapor gelmez ve siz her şeyin yolunda olduğunu sanırsınız. Bu yüzden betik başarıyla bittiğinde de kısa bir kalp atışı kaydı bırakmasını sağlayın. İkincisi, çakışmadır: önceki çalışma bitmeden yenisi başlarsa sunucu yorulur. Basit bir kilit dosyası bu sorunu çözer.
Uyarıları kime ve hangi kanaldan göndermelisiniz?
En iyi betik bile yanlış kanala bildirim gönderiyorsa işe yaramaz. Ben uyarıları önem derecesine göre ayırıyorum. Acil olanlar, örneğin dosya bütünlüğü ihlali veya beklenmeyen açık port, anında mesajla gider. Rutin olanlar ise günlük tek bir özet e-postasında toplanır.
Bu ayrım alarm yorgunluğunu önler. Her küçük olayda telefonunuz titrerse bir hafta sonra bildirimleri sessize alırsınız ve gerçek olay da o sessizliğin içinde kaybolur. Dolayısıyla eşikleri ve kanalları, uyarıların çoğu gerçekten aksiyon gerektirecek şekilde ayarlamak gerekir.
Bildirim içeriğini de sade tutun: ne oldu, hangi sunucuda, ne zaman ve ilk olarak ne yapmalısınız. Uyarıyı okuyan kişi betiği yazan kişi olmayabilir. Açık bir ilk adım yazmak, gece yarısı gelen bir mesajı panik yerine işe dönüştürür.
Otomasyon hangi noktada tehlikeli hale gelir?
Otomasyon karar vermeye başladığında risk artar. Raporlayan bir betik yanlış alarm verirse yalnızca zaman kaybedersiniz. Engelleyen bir betik yanlış karar verirse kendi müşterinizi veya kendinizi sistem dışında bırakabilirsiniz.
Bu yüzden otomatik aksiyon ekleyecekseniz şu önlemleri alın. Engelleme sürelerini kalıcı değil geçici tutun. Kendi yönetim IP adreslerinizi beyaz listeye ekleyin. Her otomatik aksiyonu ayrı bir log dosyasına yazın ki sonradan neyin neden engellendiğini görebilesiniz. Ayrıca betiğin kendisini kapatacak bir anahtar bırakın; sorun çıktığında kodu düzenlemek yerine tek bir ayarla durdurabilmelisiniz.
Bir de kapsam kayması var. Kendi sunucunuz için yazdığınız tarama betiğini müşteri sunucusuna, oradan da ilginç bulduğunuz başka bir siteye çevirmek çok kolaydır. Kod bu farkı bilmez; sınırı siz korursunuz. İzin listenizi kodun içine yazmak, yani betiğin yalnızca tanımlı adreslerde çalışması, bu kaymayı teknik olarak da engeller.
Python ile siber güvenlik becerisi web sitenize nasıl yansır?
Bu soruyu sık duyuyorum, çünkü müşterilerimin çoğu güvenlik uzmanı değil, işletme sahibi. Cevap basit: güvenli bir site hem kullanıcı hem arama motoru için daha güvenilirdir. Google, HTTPS kullanımını sayfa deneyimi sinyallerinden biri olarak değerlendirdiğini Search Central dokümantasyonunda belirtir.
Öte yandan ele geçirilmiş bir site çok daha pahalıya patlar. Spam sayfalar enjekte edilir, ziyaretçiler kötü amaçlı adreslere yönlendirilir ve tarayıcılar uyarı göstermeye başlar. Bu noktada yıllarca biriktirdiğiniz organik görünürlük kısa sürede zarar görebilir. Teknik SEO çalışmasının bir parçası olarak güvenliği de ele almamın nedeni bu; konunun geniş çerçevesini teknik SEO ipuçları yazımda anlattım.
Performans da işin içinde. Kötü amaçlı bir betik veya botların yarattığı yük sitenizi yavaşlatır. Hızın sıralamaya etkisini site hızı ve SEO yazısında ayrıntılı ele aldım. Kısacası Python ile siber güvenlik otomasyonu, pazarlama yatırımınızı koruyan görünmez bir sigortadır.
Kendi betiklerinizi yazmak mı, hazır araç kullanmak mı daha doğru?
İkisi birbirinin rakibi değil. Hazır araçlar olgun, test edilmiş ve topluluk tarafından desteklenir. Wazuh, fail2ban, Suricata veya OSSEC gibi çözümler kendi alanlarında sıfırdan yazacağınız bir betikten çok daha kapsamlıdır. Bu yüzden temel işler için tekerleği yeniden icat etmeyin.
Kendi betiğiniz ise iki durumda anlamlıdır. Birincisi, hazır aracın çıktısını kendi iş akışınıza bağlamanız gerektiğinde. İkincisi, işletmenize özel bir kontrol ihtiyacı olduğunda; örneğin belirli bir form uç noktasına gelen istek sayısının ani artışı gibi. Bu tür özel kurallar genel araçlarda ya yoktur ya da yapılandırması zahmetlidir.
Benim yaklaşımım şu: altyapıyı hazır araçlarla kurarım, Python'u aralarındaki boşlukları doldurmak ve raporları anlaşılır hale getirmek için kullanırım. Böylece bakım yükü makul kalır ve her betik net bir iş yapar.
Öğrenmeye nereden başlamalısınız?
Python ile siber güvenlik alanına yeni giriyorsanız sırayı tersten kurmayın. Önce dilin temellerini, sonra ağ kavramlarını, en son güvenlik araçlarını öğrenin. TCP ile UDP'nin farkını, DNS'in nasıl çalıştığını ve HTTP isteğinin yapısını bilmeden Scapy ile yazdığınız kod size pek bir şey anlatmaz.
Önerdiğim sıra şöyle:
- Python temelleri: dosya okuma, döngüler, fonksiyonlar, hata yönetimi.
- Standart kütüphaneden socket, ssl, hashlib, re ve logging modülleri. Python'un resmi socket dokümantasyonu iyi bir başlangıçtır.
- Kendi sunucunuzdaki log dosyalarını okuyup özetleyen küçük bir betik.
- Requests ile kendi sitenizin başlık denetimi.
- Son olarak, izole bir laboratuvarda Scapy ile paket inceleme.
Her adımda gerçek bir ihtiyaca dokunan küçük bir iş bitirin. Diğer yazılım yazılarına yazılım kategorisinden ulaşabilirsiniz. Güçlü şifre üretimini de kodla değil bir araçla hızlıca halletmek isterseniz şifre oluşturucu elinizin altında.
Python ile siber güvenlik betiklerini nasıl test edersiniz?
Güvenlik betiğinin en tehlikeli hali, çalışıyor gibi görünüp aslında hiçbir şey yakalamamasıdır. Bu yüzden her betiği, yakalaması gereken durumu bilerek üreterek test ediyorum. Log analizi betiği için sahte ama gerçekçi satırlardan oluşan küçük bir örnek dosya hazırlıyorum; içinde eşik üstü deneme yapan bir IP bulunuyor.
Ardından betiğin bu IP'yi raporladığını ve eşik altındaki adresleri raporlamadığını kontrol ediyorum. Python'un standart unittest modülü veya pytest bu iş için yeterlidir. Port envanteri için ise test makinesinde bilerek bir port açıp betiğin onu beklenmeyen port olarak işaretlediğini görüyorum.
Dosya bütünlüğü betiğinde de aynı mantık geçerli. Test dizinindeki bir dosyaya tek karakter ekler, betiğin değişikliği bulduğunu doğrularsınız. Böylece kodunuza güvenmek yerine davranışını ölçmüş olursunuz. Üstelik ileride betiği değiştirdiğinizde bu testler eski yeteneklerin bozulmadığını da gösterir.
Betik çıktılarını nasıl anlaşılır bir rapora dönüştürürsünüz?
Ham çıktı teknik ekip için yeterli olabilir, ancak işletme sahibi veya yönetici için anlamsızdır. Bu nedenle haftalık bir özet raporu hazırlamayı alışkanlık haline getirin. Rapor kısa olmalı ve üç soruya cevap vermeli: ne gördük, ne yaptık, ne bekliyor.
Pratikte betikler sonuçlarını JSON veya CSV olarak bir klasöre yazar, ayrı bir küçük betik de bunları birleştirip okunabilir bir metin üretir. İsterseniz Pandas ile haftalık eğilimleri de çıkarabilirsiniz; örneğin başarısız giriş sayısının haftadan haftaya nasıl değiştiğini görmek, sayının kendisinden daha anlamlıdır.
Raporda teknik jargonu azaltın. "Port 3306 dışarı açık" yerine "Veritabanı internetten erişilebilir durumdaydı, kapattık" yazmak, yönetimin konuyu doğru önceliklendirmesini sağlar. Yani otomasyonun son halkası kod değil, iletişimdir.
Yedek kontrolü neden bu listede olmalı?
Bütün önlemlere rağmen bir gün bir şey ters gidebilir. O gün sizi kurtaracak tek şey çalışan bir yedektir. Ne var ki yedeklerin sessizce başarısız olması, sertifika yenilemesi kadar sık karşılaştığım bir durumdur. Bu yüzden yedek kontrolünü de otomasyon listeme ekliyorum.
Basit bir Python betiği yedek dosyasının var olduğunu, beklenen saatten eski olmadığını ve boyutunun makul aralıkta olduğunu kontrol edebilir. Boyutu aniden sıfıra yakın düşen bir yedek, genellikle bir sorunun ilk işaretidir. Ayrıca belirli aralıklarla bir yedeği test ortamına geri yükleyip gerçekten açıldığını görmek gerekir; bu adımı tamamen otomatikleştirmek zor olsa da hatırlatmasını betiğe bırakabilirsiniz.
Yedeği aynı sunucuda tutmamak da önemli. Sunucu ele geçirilirse veya disk bozulursa, orada duran yedek de aynı kaderi paylaşır. Dolayısıyla yedeğin ayrı bir konuma taşındığını doğrulayan bir kontrol, listenin en değerli satırlarından biridir.
Sırları ve erişim anahtarlarını betiklerde nasıl korursunuz?
Güvenlik otomasyonu çoğu zaman bir yere bağlanır: bildirim servisine, e-posta sunucusuna veya bir API'ye. Bu bağlantılar için kullandığınız anahtarlar, betiğin en hassas parçasıdır. Anahtarı koda gömerseniz, kodu bir depoya yüklediğiniz anda sırrı da paylaşmış olursunuz.
Bu yüzden anahtarları ortam değişkenlerinden okuyun ve yapılandırma dosyasının izinlerini yalnızca betiği çalıştıran kullanıcıya açın. Ayrıca her betik için ayrı, yetkisi sınırlı bir anahtar kullanın. Örneğin yalnızca mesaj gönderebilen bir token, sızsa bile tüm hesabınızı açık etmez. Kısacası korumak için yazdığınız kod, kendi sırlarını da korumalıdır.
Bu otomasyonu bir web projesinin parçası yapmak ister misiniz?
Web sitenizi yeniden kurarken veya büyütürken güvenlik kontrollerini sonradan eklenen bir ek değil, projenin bir parçası olarak düşünmek en sağlıklısıdır. Başlık yapılandırması, yönlendirme düzeni, yedekleme ve izleme en baştan planlanırsa sonradan yama yapmak zorunda kalmazsınız.
Ben web tasarım projelerinde bu temel kontrolleri teslim listesine dahil ediyorum. Mevcut sitenizin teknik sağlığını ve görünürlüğünü birlikte ele almak isterseniz SEO danışmanlığı kapsamında da bakabiliriz. Her durumda ilk adım aynıdır: neyin açık olduğunu, neyin değiştiğini ve kimin haberdar olduğunu bilmek. Bu yazıdaki betikler tam olarak bunu sağlar.




