Edge Computing Mimarisinde DevSecOps Pratikleri

Edge sistemler büyüdükçe güvenlik konusu yalnızca merkezi veri merkezinde alınan önlemlerle çözülemiyor. Uzak lokasyonlarda çalışan cihazlar, kesintili ağ bağlantıları, fiziksel erişim riski ve farklı donanım mimarileri klasik DevOps yaklaşımının yeniden düşünülmesini gerektiriyor. Edge Computing Mimarisinde DevSecOps Pratikleri tam olarak bu noktada geliştirme, güvenlik ve operasyon disiplinlerini tek bir yaşam döngüsünde buluşturuyor. On yılı aşkın altyapı ve yazılım projelerinde gördüğüm ortak nokta şu oldu: güvenlik dağıtımın son kontrolü olduğunda sorunlar geç fark ediliyor, güvenlik akışın parçası olduğunda ise ekipler daha hızlı hareket ediyor. Bu rehberde Edge Computing mimarisinde DevSecOps nasıl uygulanır, edge sistemlerde CI/CD ve güvenlik otomasyonu nasıl kurulur ve üretim ortamında hangi kontroller gerçekten işe yarar sorularına uygulamalı bir bakış sunacağım.

Edge Computing Nedir?

Edge Computing, verinin üretildiği noktaya yakın yerde işlenmesini sağlayan dağıtık bir bilgi işlem modelidir. Amaç her veriyi önce merkezi bir cloud ortamına taşımak yerine gecikmeye duyarlı işlemleri cihaz, gateway veya yerel sunucu seviyesinde gerçekleştirmektir. Fabrika otomasyonu, mağaza sistemleri, akıllı şehir altyapısı, telekom ve IoT projeleri bunun yaygın örnekleridir. Edge yaklaşımı ağ gecikmesini azaltırken bant genişliği kullanımını da kontrol altında tutar. Bunun karşılığında güvenlik, operasyon ve güncelleme süreçlerinin çok daha fazla lokasyona yayılması gerekir.

Edge Computing Nasıl Çalışır?

Edge mimarisinde sensör, uygulama veya makine tarafından üretilen veri önce kendisine yakın bir işlem noktasına gönderilir. Bu nokta basit bir edge cihazı olabileceği gibi güçlü bir gateway veya Kubernetes cluster da olabilir. Gecikmeye duyarlı kararlar burada alınır ve yalnızca gerekli sonuçlar merkezi sisteme aktarılır. Bağlantı kesildiğinde kritik servislerin yerel olarak çalışmaya devam etmesi hedeflenir. Bu yapı tasarlanırken uygulamanın cloud bağlantısına sürekli ihtiyaç duymaması önemli bir mimari şarttır.

Cloud Computing ile Edge Computing Arasındaki Fark

Cloud Computing merkezi ve ölçeklenebilir işlem kaynakları sunarken Edge Computing işlemi verinin bulunduğu noktaya yaklaştırır. Cloud ortamında güçlü işlem kapasitesi ve merkezi yönetim avantajı bulunur. Edge tarafında ise düşük gecikme, yerel çalışma ve bağlantı kesintilerine dayanıklılık öne çıkar. Pratikte bu iki model birbirinin alternatifi değil tamamlayıcısıdır. Sağlam bir mimaride merkezi kontrol ve analiz cloud üzerinde, zamana duyarlı operasyon ise edge üzerinde yürütülebilir.

Fog Computing ile Edge Computing Arasındaki Fark

Fog Computing, edge cihazları ile merkezi cloud arasında ek bir dağıtık işlem katmanı oluşturur. Edge işlemleri çoğunlukla veri kaynağının hemen yanında yapılır. Fog katmanı ise bölgesel gateway, ara sunucu veya yerel veri merkezi gibi daha geniş bir alanı kapsayabilir. Her iki yaklaşım da gecikmeyi ve merkezi sistem bağımlılığını azaltmaya çalışır. Mimari seçim yapılırken cihaz sayısı, ağ yapısı ve merkezi yönetim ihtiyacı birlikte değerlendirilmelidir.

Edge Computing'in Temel Bileşenleri

Bir edge mimarisini yalnızca cihazlardan oluşan bir sistem olarak görmek eksik olur. Cihaz, gateway, sunucu, cluster ve merkezi control plane birbirini tamamlayan katmanlardır. DevSecOps tasarımı yapılırken her katmanın farklı saldırı yüzeyi olduğu kabul edilmelidir. Örneğin fiziksel cihaz için boot güvenliği öne çıkarken merkezi control plane tarafında yetkilendirme ve audit daha kritik hale gelir. Başarılı uygulamalarda bu katmanların güvenlik politikaları tek bir yönetişim modeli altında yönetilir.

Edge Device

Edge device, veriyi üreten veya doğrudan fiziksel süreçle etkileşime giren cihazdır. Endüstriyel bilgisayar, kamera, sensör gateway'i veya mağaza terminali buna örnek olabilir. Bu cihazların CPU, RAM ve disk kapasitesi çoğu zaman sınırlıdır. Ayrıca fiziksel erişim riski merkezi sunuculara göre daha yüksektir. Bu nedenle cihaz kimliği, disk şifreleme, secure boot ve güvenli güncelleme mekanizması temel gereksinimler arasındadır.

Edge Gateway

Edge gateway farklı cihazlardan gelen trafiği toplayan ve çoğu zaman protokol dönüşümü yapan ara katmandır. Yerel ağ ile merkezi sistem arasındaki güvenlik sınırlarından biri olarak çalışabilir. Gateway üzerinde firewall, veri filtreleme ve kimlik doğrulama görevleri yürütülebilir. Bu rol nedeniyle ele geçirilmesi birden fazla edge cihazını etkileyebilir. Gateway güvenliğinde minimum servis, düzenli güncelleme ve güçlü cihaz kimliği önemli bir başlangıç noktasıdır.

Edge Server

Edge server, cihazlara göre daha güçlü işlem kapasitesine sahip yerel sunucudur. Yapay görme, veri analizi, yerel API veya container workload çalıştırmak için kullanılabilir. Bu sunucular çoğu zaman saha ortamında bulunduğundan fiziksel ve ağ güvenliği birlikte ele alınmalıdır. İşletim sistemi sertleştirmesi ve workload izolasyonu kritik önem taşır. Güncellemelerin merkezi politika ile yönetilmesi de zaman içinde güvenlik seviyesinin korunmasını sağlar.

Edge Cluster

Edge cluster, birden fazla edge node'un ortak bir orkestrasyon katmanında çalışmasını sağlar. Kubernetes tabanlı sistemler bu modelin en bilinen örneklerinden biridir. Cluster kullanımı servis yönetimini kolaylaştırırken yeni güvenlik kontrollerini de gerekli hale getirir. RBAC, NetworkPolicy, admission control ve pod güvenliği bunların başında gelir. Cluster kaynaklarının düşük olduğu senaryolarda güvenlik araçlarının oluşturduğu ek yük ayrıca ölçülmelidir.

Merkezi Cloud / Control Plane

Merkezi cloud veya control plane cihaz filolarının politika, güncelleme, gözlemleme ve kimlik süreçlerini koordine eder. Buradaki bir güvenlik ihlali çok sayıda edge lokasyonuna yayılabileceği için erişim sınırları dar tutulmalıdır. Yönetici işlemleri güçlü kimlik doğrulama ve ayrıntılı audit kaydı ile izlenmelidir. Edge sistemler bağlantıyı kaybettiğinde temel işlevlerini sürdürmeye devam etmelidir. Bu nedenle merkezi yönetim güçlü olsa da edge workload'larının sürekli bağlantıya bağımlı hale getirilmemesi gerekir.

DevSecOps Nedir?

DevSecOps, güvenliği geliştirme ve operasyon süreçlerinin doğal bir parçası haline getiren çalışma modelidir. Güvenlik ekibinin yalnızca yayına çıkmadan önce kontrol yaptığı klasik süreçler yerine güvenlik kontrolleri kod yazımından runtime aşamasına kadar dağıtılır. Otomasyon bu yaklaşımın temelidir çünkü manuel güvenlik kontrolleri büyük edge filolarında ölçeklenmez. Ekipler ortak politika, ölçüm ve sorumluluk modeliyle hareket eder. Sonuçta amaç dağıtımı yavaşlatmak değil güvenli değişikliği daha sık ve daha öngörülebilir biçimde yapabilmektir.

DevOps'tan DevSecOps'a Geçiş

DevOps hızlı teslimat ve ekipler arası iş birliği üzerine kuruludur. DevSecOps bu modele güvenliği sürekli bir mühendislik sorumluluğu olarak ekler. Pipeline içine SAST, dependency kontrolü, secret scanning ve policy testleri yerleştirilir. Kritik bulgular erken aşamada build veya deployment sürecini durdurabilir. Böylece güvenlik kontrolü ayrı bir kapı olmaktan çıkar ve teslimat sisteminin kendisine dönüşür.

Security by Design

Security by Design güvenliğin sistem tamamlandıktan sonra eklenmemesini ifade eder. Kimlik, erişim, şifreleme ve güncelleme gereksinimleri mimari aşamada belirlenir. Edge sistemlerde bu yaklaşım daha değerlidir çünkü dağıtılmış cihazların sonradan değiştirilmesi pahalı olabilir. Donanım seçimi sırasında TPM desteği veya secure boot yeteneği gibi konuların düşünülmesi buna örnektir. Tasarım aşamasında alınan doğru kararlar ileride çok sayıda operasyon sorununu azaltır.

Shift Left Security

Shift Left Security güvenlik kontrollerini geliştirme sürecinin erken aşamalarına taşır. Developer daha pull request açmadan secret veya yanlış yapılandırmayı görebilir. CI sırasında kaynak kod, bağımlılıklar, container image ve IaC dosyaları taranabilir. Hata ne kadar erken bulunursa düzeltme maliyeti genellikle o kadar düşük olur. Edge sistemlerde binlerce cihaza hatalı sürüm göndermeden önce sorunu yakalamak özellikle önemlidir.

Shift Right Security

Shift Right Security üretim sonrasında çalışan sistemin sürekli gözlemlenmesini ifade eder. Pipeline kontrolleri bütün riskleri yakalayamaz çünkü bazı saldırılar yalnızca runtime davranışı sırasında görünür. Beklenmeyen process, dosya değişikliği veya ağ bağlantısı buna örnektir. Edge node üzerinde hafif runtime güvenlik kontrolleri kullanmak bu boşluğu azaltır. Shift Left ve Shift Right birlikte uygulandığında güvenlik yaşam döngüsü daha dengeli hale gelir.

Continuous Security

Continuous Security güvenliği belirli tarihlerde yapılan tek seferlik denetim yerine sürekli çalışan kontroller olarak ele alır. Yeni CVE yayınlandığında mevcut filonun hangi cihazlarının etkilendiği otomatik sorgulanabilir. Sertifika süresi yaklaşırken alarm oluşturulabilir. Policy ihlali runtime aşamasında tespit edilip merkezi sisteme bildirilebilir. Bu model edge operasyonlarında değişen risklerin daha hızlı yönetilmesine yardımcı olur.

Dev, Sec ve Ops Ekiplerinin Ortak Sorumluluğu

DevSecOps modelinde güvenlik yalnızca security ekibinin işi değildir. Developer güvenli kod ve bağımlılık seçiminden, operasyon ekibi güvenli deployment ve runtime yapılandırmasından sorumludur. Security ekibi ise uygulanabilir politikalar, tehdit modeli ve otomatik kontroller sağlar. Ekiplerin ortak metrikler kullanması iletişimi kolaylaştırır. Özellikle edge projelerinde ürün, altyapı ve donanım ekiplerinin de bu sorumluluk modeline dahil edilmesi gerekir.

Edge Computing'de DevSecOps Neden Farklıdır?

Edge sistemlerde DevSecOps uygulamak merkezi cloud ortamına göre farklı varsayımlar gerektirir. Cihazlar uzak lokasyonlarda olabilir, fiziksel olarak erişilebilir durumdadır ve ağ bağlantısı sık sık kesilebilir. Donanım kapasitesinin sınırlı olması bazı güvenlik araçlarının doğrudan çalıştırılmasını zorlaştırır. Ayrıca aynı filoda ARM ve x86 cihazların birlikte bulunması build ve test süreçlerini etkiler. Bu nedenle edge sistemlerde CI/CD ve güvenlik otomasyonu nasıl kurulur sorusunun yanıtı bağlantı kaybını, donanım çeşitliliğini ve saha operasyonunu birlikte ele almalıdır.

Dağıtık Altyapı

Edge altyapısının en belirgin özelliği merkezi olmayan yapıdır. Yüzlerce veya binlerce cihaz farklı ağlarda çalışabilir. Bu durum manuel operasyon yaklaşımını sürdürülemez hale getirir. Konfigürasyon, politika ve güncellemelerin merkezi olarak tanımlanıp yerelde uygulanması gerekir. GitOps ve fleet management yaklaşımları bu ihtiyacı karşılamak için güçlü seçenekler sunar.

Fiziksel Olarak Erişilebilir Cihazlar

Bir edge cihazına saldırganın fiziksel olarak dokunabilmesi tehdit modelini değiştirir. Disk sökülmesi, debug portlarının kullanılması veya cihazın tamamen çalınması ihtimalleri dikkate alınmalıdır. Sadece işletim sistemi seviyesinde erişim kontrolü yeterli olmaz. Secure boot, disk encryption ve donanımsal anahtar koruması gibi kontroller gerekir. Cihaz kaybolduğunda kimlik bilgilerinin hızlı biçimde iptal edilebilmesi de önemlidir.

Binlerce Uzak Lokasyon

Çok sayıda lokasyon manuel müdahaleyi pahalı ve yavaş hale getirir. Her cihaz için ayrı SSH oturumu açmak operasyonel olarak iyi bir model değildir. Güncelleme, politika ve gözlemleme süreçleri filo seviyesinde otomatikleştirilmelidir. Deployment ring ve canary yaklaşımı hatanın tüm lokasyonlara aynı anda yayılmasını önler. Merkezi görünürlük ile yerel dayanıklılık arasında dengeli bir tasarım kurulmalıdır.

Düşük ve Kesintili Bant Genişliği

Edge cihazlar her zaman hızlı ve kararlı internet bağlantısına sahip olmayabilir. Pipeline ve deployment tasarımı bu durumu istisna değil normal çalışma koşulu olarak görmelidir. Artifact cache, local registry ve store-and-forward logging gibi yöntemler bağlantı bağımlılığını azaltır. Büyük container image'ları güncelleme süresini ciddi şekilde etkileyebilir. Bu nedenle image boyutu ve delta update seçenekleri operasyon tasarımının parçası olmalıdır.

Sınırlı CPU, RAM ve Disk

Edge cihazların kaynakları çoğu veri merkezi sunucusundan daha sınırlıdır. Security agent veya service mesh eklemek cihaz üzerinde beklenmeyen kaynak tüketimine yol açabilir. Bu nedenle her güvenlik kontrolünün maliyeti ölçülmelidir. Hafif araçlar, merkezi analiz ve yerel filtreleme yaklaşımı genellikle daha verimli sonuç verir. Güvenlik tasarımı workload performansını bozmayacak biçimde yapılmalıdır.

ARM ve x86 Donanım Çeşitliliği

Farklı işlemci mimarileri build pipeline'ının multi-architecture çalışmasını gerektirir. Bir image'ın x86 üzerinde başarılı olması ARM cihazda aynı sonucu garanti etmez. Dependency ve native library uyumluluğu ayrıca test edilmelidir. CI ortamında her hedef mimari için build ve test üretmek iyi bir uygulamadır. Artifact manifest ve digest yönetimi de bu süreçte dikkatle yapılmalıdır.

Merkezi Güvenlik Kontrollerine Sürekli Erişememe

Edge node merkezi policy veya kimlik servisine sürekli erişemeyebilir. Bu nedenle temel güvenlik kararlarının belirli bir bölümünün yerelde uygulanması gerekir. Önceden dağıtılmış policy, kısa süreli cache ve güvenli offline çalışma modeli kullanılabilir. Bağlantı geri geldiğinde olay kayıtları ve durum bilgisi merkezi sisteme aktarılmalıdır. Merkezi servis erişilemediğinde sistemin varsayılan davranışı önceden belirlenmelidir.

Uzun Cihaz Yaşam Döngüleri

Edge cihazların sahada beş, on veya daha fazla yıl çalışması olağandır. Bu süre boyunca işletim sistemi, firmware ve cryptographic algoritmalar değişebilir. Satın alma aşamasında güncelleme desteği ve üretici yaşam döngüsü dikkate alınmalıdır. Destek süresi sona eren cihazlar güvenlik borcu oluşturur. Cihaz değiştirme planı DevSecOps yaşam döngüsünün parçası olmalıdır.

OT ve IoT Sistemleriyle Entegrasyon

Edge platformları sıklıkla OT ve IoT sistemleriyle aynı ağda çalışır. Bu sistemlerde availability gereksinimi çok yüksek olabilir ve klasik patch yaklaşımı doğrudan uygulanamayabilir. Network segmentasyonu ve kontrollü entegrasyon noktaları saldırı yüzeyini azaltır. Üretim hattını etkileyebilecek bir güncelleme önce temsilî test ortamında denenmelidir. IT ve OT ekiplerinin ortak değişiklik süreci oluşturması güvenlik açısından faydalıdır.

Edge DevSecOps Tehdit Modeli Nasıl Oluşturulur?

Tehdit modeli, güvenlik kontrollerini rastgele seçmek yerine gerçek risklere göre belirlemek için kullanılır. Önce korunacak varlıklar, veri akışları ve güven sınırları görünür hale getirilir. Sonra fiziksel cihazdan CI/CD pipeline'ına kadar saldırı yüzeyi incelenir. Benim saha projelerinde en faydalı bulduğum yaklaşım, mimari diyagram ile tehdit modelini aynı toplantıda değerlendirmektir. Böylece güvenlik ekibi teorik riskleri, operasyon ekibi ise gerçek çalışma koşullarını aynı çerçevede tartışabilir.

Korunması Gereken Varlıkları Belirlemek

İlk adım hangi varlıkların iş açısından değerli olduğunu belirlemektir. Cihaz kimliği, private key, müşteri verisi, firmware ve deployment artefact'ları bunlara örnektir. Her varlığın gizlilik, bütünlük ve erişilebilirlik ihtiyacı farklı olabilir. Kritik varlıklar belirlenmeden güvenlik önceliklendirmesi yapmak zorlaşır. Varlık envanteri vulnerability management sürecinde de kullanılmalıdır.

Trust Boundary'leri Tanımlamak

Trust boundary farklı güven seviyelerine sahip sistemlerin kesiştiği noktadır. Edge cihaz ile yerel ağ, gateway ile cloud veya CI runner ile artifact registry arasında böyle sınırlar bulunabilir. Her sınırda kimlik doğrulama ve yetkilendirme ihtiyacı değerlendirilmelidir. Network konumu tek başına güven göstergesi kabul edilmemelidir. Zero Trust yaklaşımı bu sınırların her bağlantıda yeniden doğrulanmasını destekler.

Data Flow Diagram Oluşturmak

Data Flow Diagram verinin sistem içinde nereden nereye hareket ettiğini gösterir. Hangi protokolün, kimliğin ve şifreleme yönteminin kullanıldığı diyagram üzerine eklenebilir. Bu çalışma gereksiz veri transferlerini de görünür hale getirir. Edge cihazdan cloud'a gönderilen verinin gerçekten gerekli olup olmadığı burada sorgulanabilir. Diyagram güncel tutulduğunda incident response sırasında da önemli bir referans sağlar.

STRIDE ile Tehdit Modelleme

STRIDE, tehditleri sistematik şekilde sınıflandırmak için kullanılan pratik bir yöntemdir. Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service ve Elevation of Privilege kategorilerini içerir. Her bileşen ve veri akışı bu başlıklarla ayrı ayrı incelenebilir. Yöntem özellikle ekiplerin tehdit modeli çalışmalarına ortak bir dil kazandırır. Bulunan risklerin olasılık ve iş etkisine göre sıralanması uygulamayı kolaylaştırır.

Spoofing

Spoofing bir kullanıcı, cihaz veya servisin başka bir kimliğe bürünmesini ifade eder. Edge cihazlarda kopyalanmış sertifika veya çalınmış private key önemli bir risk oluşturur. Hardware-backed key saklama bu riski azaltabilir. mTLS bağlantıları tarafların karşılıklı kimlik doğrulamasını sağlar. Kimlik iptal mekanizması olmadan güçlü sertifika sistemi de operasyonel olarak eksik kalır.

Tampering

Tampering yazılım, firmware, veri veya konfigürasyonun izinsiz değiştirilmesidir. İmzalı artifact ve secure boot mekanizmaları bu riske karşı koruma sağlar. GitOps repository değişikliklerinin review sürecinden geçmesi de önemlidir. Runtime sırasında file integrity monitoring beklenmeyen değişiklikleri fark edebilir. Bütünlük kontrolünün build aşamasından cihazın boot sürecine kadar devam etmesi gerekir.

Repudiation

Repudiation bir işlemi yapan tarafın daha sonra bu işlemi inkâr edebilmesi riskidir. Güvenilir audit log bu nedenle önemlidir. Deployment, policy değişikliği ve credential işlemleri kim tarafından yapıldığı bilgisiyle kaydedilmelidir. Log bütünlüğü de korunmalıdır. Merkezi sisteme bağlantı yoksa kayıtlar güvenli yerel buffer içinde saklanabilir.

Information Disclosure

Information Disclosure hassas verinin yetkisiz kişilere veya sistemlere açılmasıdır. Encryption at rest ve encryption in transit temel kontrollerdir. Edge üzerinde mümkün olduğunca az veri saklamak riski azaltır. Secret ve private key düz metin dosyalarda tutulmamalıdır. Logların da hassas bilgi sızdırıp sızdırmadığı kontrol edilmelidir.

Denial of Service

Denial of Service kaynakları tüketerek servisi kullanılamaz hale getirmeyi hedefler. Edge cihazların sınırlı kapasitesi bu saldırı türüne karşı hassasiyet oluşturabilir. Rate limit, network filtering ve resource limit uygulanabilir. Yerel servislerin merkezi bağlantı kesildiğinde çalışabilmesi erişilebilirliği artırır. Monitoring sistemi kaynak tüketimindeki olağan dışı artışları erken fark etmelidir.

Elevation of Privilege

Elevation of Privilege saldırganın mevcut yetkisinden daha güçlü bir yetki elde etmesidir. Privileged container, geniş Linux capability veya hatalı RBAC kuralı bu riski büyütebilir. Least privilege yaklaşımı her kullanıcı ve workload için uygulanmalıdır. Root olmayan container kullanımı etkili bir başlangıçtır. Runtime güvenliği beklenmeyen privilege escalation girişimlerini tespit etmeye yardımcı olur.

Edge'e Özgü Attack Surface

Edge saldırı yüzeyi tek bir uygulamadan çok daha geniştir. Fiziksel donanım, firmware, işletim sistemi, container runtime, Kubernetes, ağ, control plane ve CI/CD pipeline aynı zincirin parçalarıdır. Bir katmandaki zayıflık diğer katmanların güvenliğini etkileyebilir. Bu nedenle yalnızca uygulama güvenlik taraması yapmak yeterli değildir. Edge cihazlarda container Kubernetes ve DevSecOps pipeline güvenliği aynı tehdit modelinin içinde değerlendirilmelidir.

Fiziksel Cihaz

Fiziksel cihaz çalınabilir, açılabilir veya farklı bir ağa bağlanabilir. Disk şifreleme yerel verinin okunmasını zorlaştırır. Debug portlarının kapatılması donanım müdahalesini sınırlar. Cihaz kimliğinin donanıma bağlanması kopyalama riskini azaltır. Fiziksel olaylar merkezi sistemde güvenlik olayı olarak takip edilmelidir.

Firmware

Firmware cihazın güven zincirinin en erken yazılım katmanlarından biridir. Manipüle edilmiş firmware işletim sistemi başlamadan saldırgana kontrol sağlayabilir. İmzalı firmware ve doğrulanan update mekanizması bu riski azaltır. Firmware sürümleri asset inventory içinde takip edilmelidir. Güvenlik açığı bulunan eski sürümlere geri dönüş de engellenmelidir.

Operating System

İşletim sistemi edge workload'larının temel çalışma ortamıdır. Gereksiz servislerin kapatılması saldırı yüzeyini düşürür. Güvenlik yamaları kontrollü rollout ile uygulanmalıdır. Disk ve dosya izinleri minimum yetki prensibine göre yapılandırılmalıdır. OS sürümü ve destek durumu filo seviyesinde görünür olmalıdır.

Container Runtime

Container runtime workload izolasyonunun kritik bir bileşenidir. Güncel olmayan runtime sürümleri container escape riskini artırabilir. Privileged çalışma modu mümkün olduğunca engellenmelidir. Runtime socket erişimi sınırlı tutulmalıdır. Security monitoring container davranışındaki olağan dışı hareketleri izlemelidir.

Kubernetes

Kubernetes edge workload yönetimini kolaylaştırır ancak geniş bir güvenlik yüzeyi getirir. API erişimi, RBAC, service account ve admission politikaları dikkatle yapılandırılmalıdır. Node ve control plane iletişimi şifrelenmelidir. Varsayılan açık network iletişimi yerine NetworkPolicy tercih edilmelidir. Audit log kritik yönetim işlemlerinin takibini kolaylaştırır.

Network

Edge ağı güvenilir iç ağ olarak kabul edilmemelidir. Cihazlar farklı sağlayıcı, mağaza veya saha ağlarında çalışabilir. mTLS, firewall ve default-deny segmentasyon riski azaltır. Egress filtering ele geçirilmiş cihazın dış sistemlerle iletişimini sınırlar. DNS trafiği de güvenlik görünürlüğünün önemli bir parçasıdır.

Control Plane

Control plane filo çapında yetkiye sahip olduğu için yüksek değerli bir hedeftir. Yönetici erişimi MFA ve güçlü kimlik politikalarıyla korunmalıdır. API erişimi ağ seviyesinde de sınırlandırılmalıdır. Değişiklikler ayrıntılı olarak loglanmalıdır. Control plane ele geçirilse bile blast radius politika ve rol ayrımlarıyla azaltılmalıdır.

CI/CD Pipeline

CI/CD pipeline güvenilir yazılım üretiminin merkezinde yer alır. Runner ele geçirilirse güvenli kaynak koddan zararlı artifact üretilebilir. Pipeline credential'ları kısa ömürlü ve minimum yetkili olmalıdır. Üçüncü taraf action ve dependency sürümleri sabit referanslara bağlanmalıdır. Artifact signing ve provenance doğrulaması pipeline saldırılarının etkisini azaltan önemli kontrollerdir.

Edge Computing'de Fiziksel Güvenlik

Edge sistemler veri merkezi sınırları dışında çalıştığı için fiziksel güvenlik mimarinin ayrılmaz parçasıdır. Cihazın mağaza, fabrika, araç veya açık alanda bulunması saldırganın doğrudan donanıma ulaşmasına yol açabilir. Bu nedenle yalnızca parola ve firewall ile güvenlik sağlanamaz. Disk encryption, secure boot, debug port kontrolü ve tamper detection birlikte ele alınmalıdır. Cihazın kaybolduğu veya çalındığı senaryo incident response planında önceden tanımlanmalıdır.

Cihaz Çalınması Riski

Çalınan cihaz üzerinde yerel veri ve credential bulunabilir. Disk şifreleme bu bilgilerin doğrudan okunmasını zorlaştırır. Private key mümkünse TPM veya secure element içinde tutulmalıdır. Merkezi sistem cihaz sertifikasını hızlı biçimde iptal edebilmelidir. Yeni bağlantı denemeleri güvenlik olayı olarak izlenmelidir.

Fiziksel Tamper Riski

Cihaz kasasının açılması veya donanım bileşenlerinin değiştirilmesi tamper riski oluşturur. Sensör veya kasa switch'i bu müdahaleyi algılayabilir. Tespit sonrası cihaz belirli credential'ları kullanmayı durdurabilir. Olay merkezi sisteme kaydedilebilir. Kritik ortamlarda fiziksel mühür ve kontrollü kabin de ek savunma sağlar.

USB Portlarının Kontrolü

Açık USB portları yetkisiz depolama veya giriş cihazı bağlantısına izin verebilir. Kullanılmayan portlar BIOS, işletim sistemi veya fiziksel yöntemlerle kapatılabilir. USB device allowlist yaklaşımı kritik sahalarda yararlı olabilir. Bakım ihtiyacı varsa kontrollü servis prosedürü oluşturulmalıdır. Port politikaları cihaz image'ının standart konfigürasyonuna dahil edilmelidir.

JTAG ve UART Debug Arayüzleri

JTAG ve UART üretim ve geliştirme sırasında değerli debug araçlarıdır. Ancak sahadaki cihazlarda açık bırakılmaları ciddi güvenlik riski oluşturabilir. Debug erişimi kilitlenmeli veya yetkilendirilmiş servis moduna bağlanmalıdır. Donanım tasarımı sırasında bu gereksinim planlanmalıdır. Üretim aşamasında debug durumunu doğrulayan kalite kontrolü yapılması faydalıdır.

BIOS/UEFI Koruması

BIOS veya UEFI ayarları boot güvenliğini doğrudan etkiler. Yetkisiz boot cihazları engellenmelidir. Secure Boot etkinleştirilmeli ve gerekli anahtarlar kontrollü yönetilmelidir. Firmware yönetim parolaları standart varsayılan değerlerde bırakılmamalıdır. BIOS konfigürasyonu filo envanterinde takip edilebilir.

Disk Encryption

Disk encryption cihaz ele geçirildiğinde yerel verinin korunmasını sağlar. Şifreleme anahtarının aynı disk üzerinde açık biçimde tutulması korumayı zayıflatır. TPM destekli key release bu sorunu azaltabilir. Recovery key süreçleri güvenli ve denetlenebilir olmalıdır. Disk şifreleme performansı hedef donanım üzerinde test edilmelidir.

Tamper Detection

Tamper detection cihazın fiziksel durumunda beklenmeyen değişiklikleri belirlemeye yardımcı olur. Kasa açılması, boot ölçüm değişikliği veya sensör olayı sinyal olarak kullanılabilir. Sistem bu sinyallere göre cihazı quarantine moduna alabilir. Merkezi control plane olayın ciddiyetini değerlendirir. Yanlış pozitifleri azaltmak için saha operasyonlarıyla güvenlik politikası birlikte tasarlanmalıdır.

Cihaz Çalındığında Credential Revocation

Çalınan bir cihazın credential'ları hızla geçersiz hale getirilebilmelidir. Certificate revocation veya merkezi deny list uygulanabilir. Short-lived credential kullanımı müdahale süresini daha da azaltır. Cihaz kimliği ile kullanıcı veya servis kimliği birbirinden ayrılmalıdır. Böylece tek bir cihaz olayı tüm sistem credential'larının değiştirilmesini gerektirmez.

Hardware Root of Trust

Hardware Root of Trust, cihaz kimliği ve güvenli boot zinciri için donanım tabanlı bir güven başlangıç noktası sağlar. Yazılım tarafından kolayca kopyalanamayan anahtarların güvenli bir bileşende tutulması özellikle sahadaki edge cihazlarda değerlidir. TPM ve secure element bu amaçla kullanılan yaygın seçeneklerdir. Edge Computing ortamlarında zero trust secrets management ve vulnerability scanning tasarlanırken cihazın gerçekten beklenen donanım olup olmadığının doğrulanması güçlü bir temel oluşturur. Donanım güveni tek başına yeterli değildir ancak diğer güvenlik katmanlarının üzerine kurulabileceği sağlam bir başlangıç sağlar.

TPM Nedir?

TPM, cryptographic işlemler ve güvenli key saklama için tasarlanmış donanım bileşenidir. Platform ölçümlerini saklayabilir ve boot durumunun doğrulanmasına yardımcı olabilir. Private key TPM dışına çıkarılmadan imzalama işlemleri yapılabilir. Bu özellik cihaz kimliğinin kopyalanmasını zorlaştırır. Edge node attestation senaryolarında TPM yaygın olarak kullanılır.

Secure Element Nedir?

Secure Element hassas cryptographic materyali korumak için tasarlanmış izole bir donanım bileşenidir. Private key burada üretilebilir ve dışarı çıkarılmadan kullanılabilir. IoT ve düşük kaynaklı edge cihazlarda sık görülür. Cihaz certificate'i secure element içindeki anahtarla ilişkilendirilebilir. Fiziksel saldırılara karşı standart flash depolamaya göre daha güçlü koruma sunar.

Hardware Root of Trust Ne Sağlar?

Hardware Root of Trust güvenilir cihaz kimliği ve boot doğrulaması için temel sağlar. Yazılım katmanında değişiklik olsa bile donanımdaki anahtar korunabilir. Remote attestation sürecinde cihazın beklenen durumda olup olmadığı kontrol edilebilir. Credential kullanımının belirli platform durumlarına bağlanması mümkündür. Bu yapı özellikle fiziksel erişim riskinin yüksek olduğu edge sistemlerde değerlidir.

Device Identity ile İlişkisi

Device Identity bir edge cihazının sistem içindeki benzersiz kimliğidir. Hardware Root of Trust bu kimliğin private key'ini güvenli biçimde saklayabilir. Böylece sertifikanın başka bir cihaza kopyalanması zorlaşır. Control plane bağlantı sırasında hem certificate'i hem attestation bilgisini değerlendirebilir. Cihaz kimliğinin güvenilir olması Zero Trust modelinin önemli parçalarından biridir.

Cryptographic Key'lerin Donanımda Saklanması

Private key'lerin dosya sisteminde saklanması cihaz ele geçirildiğinde kopyalanma riskini artırır. Donanım destekli key saklama bu riski azaltır. Anahtar mümkünse cihaz dışına hiç çıkarılmamalıdır. Key rotation süreci de donanım özelliğiyle uyumlu tasarlanmalıdır. Recovery ve cihaz değişimi senaryoları önceden planlanmalıdır.

Secure Boot ve Measured Boot

Secure Boot cihazın yalnızca yetkilendirilmiş yazılım bileşenleriyle başlamasını amaçlar. Measured Boot ise boot sürecindeki bileşenlerin ölçümlerini kaydederek sonradan doğrulama yapılmasına imkan verir. Bu iki yöntem birlikte kullanıldığında fiziksel müdahale ve firmware manipülasyonu daha görünür hale gelir. Edge node'un sahada değiştirildiği veya boot zincirinin bozulduğu senaryolar erken tespit edilebilir. Özellikle kritik edge filolarında secure boot ile remote attestation birbirini tamamlayan kontrollerdir.

Secure Boot Nasıl Çalışır?

Secure Boot açılış sırasında boot bileşenlerinin dijital imzasını doğrular. Güven zinciri firmware seviyesinden başlayabilir. Geçersiz veya yetkisiz bileşen çalıştırılmadan boot durdurulur. Kullanılan güven anahtarları kontrollü biçimde yönetilmelidir. Güncelleme süreci yeni imzalı bileşenlerle uyumlu olmalıdır.

Bootloader Doğrulama

Bootloader işletim sisteminin yüklenmesinden önce çalışan kritik bir bileşendir. İmzası doğrulanmadığında saldırgan değiştirilmiş bootloader çalıştırabilir. Secure Boot bu kontrolü otomatik hale getirir. Bootloader update paketleri de imzalanmalıdır. Eski ve güvenlik açığı bulunan sürümlere geri dönüş sınırlandırılmalıdır.

Kernel Doğrulama

Kernel sistem üzerindeki en yüksek yetkili yazılım katmanlarından biridir. Manipüle edilmiş kernel bütün workload güvenliğini etkileyebilir. Boot zincirinde kernel image imzası doğrulanmalıdır. Kernel modülleri için de imza politikası uygulanabilir. Kernel sürümleri filo envanterinde görünür tutulmalıdır.

Firmware Doğrulama

Firmware doğrulaması cihazın düşük seviyeli yazılımının güvenilir kaynaktan geldiğini kanıtlamaya yardımcı olur. İmzasız firmware update kabul edilmemelidir. Signing key operasyonel olarak güçlü biçimde korunmalıdır. Release pipeline içinde firmware hash ve signature üretilebilir. Cihaz güncelleme öncesinde bu bilgileri doğrulamalıdır.

Measured Boot Nedir?

Measured Boot boot bileşenlerinin hash değerlerini güvenli ölçüm kayıtlarına ekler. Sistem bu ölçümleri merkezi attestation servisine gönderebilir. Beklenen ölçümlerden sapma cihazın değiştirilmiş olabileceğini gösterir. Tek başına boot'u engellemek yerine durum görünürlüğü sağlar. Secure Boot ile birlikte kullanıldığında daha güçlü bir güven modeli oluşturur.

Remote Attestation

Remote attestation uzak cihazın boot veya platform durumunu merkezi sisteme kanıtlamasını sağlar. TPM ölçümleri bu doğrulamada kullanılabilir. Control plane yalnızca beklenen güven seviyesindeki cihazlara erişim verebilir. Başarısız attestation otomatik quarantine sürecini tetikleyebilir. Böylece cihazın fiziksel olarak kontrol edilmediği lokasyonlarda da güven sinyali elde edilir.

Manipüle Edilmiş Edge Node'u Tespit Etmek

Manipüle edilmiş node yalnızca tek bir sinyalle tespit edilmemelidir. Attestation sonucu, configuration drift, runtime davranışı ve network anomalileri birlikte değerlendirilebilir. Beklenmeyen boot ölçümleri güçlü bir uyarıdır. Sistem node'un certificate kullanımını geçici olarak durdurabilir. Olay sonrası cihaz güvenli image ile yeniden provision edilebilir.

Edge Cihaz Kimliği Nasıl Yönetilir?

Cihaz kimliği edge güvenliğinin merkezinde yer alır çünkü ağ konumu güvenilir kabul edilemez. Her cihazın benzersiz ve doğrulanabilir bir kimliği bulunmalıdır. Kimlik üretim aşamasında verilebilir veya ilk provisioning sırasında güvenli biçimde oluşturulabilir. X.509 certificate, TPM ve secure element bu modelde birlikte kullanılabilir. Kimlik yaşam döngüsü yalnızca oluşturmayı değil rotation, revocation ve decommission süreçlerini de kapsamalıdır.

Her Cihaz İçin Benzersiz Kimlik

Paylaşılan cihaz credential'ları tek bir sızıntının tüm filoyu etkilemesine neden olur. Bu nedenle her edge cihazına benzersiz kimlik verilmelidir. Kimlik asset inventory ile ilişkilendirilmelidir. Certificate veya key gerektiğinde yalnızca ilgili cihaz için iptal edilebilir. Böylece incident response sırasında blast radius daha küçük tutulur.

Manufacturing-Time Identity

Manufacturing-Time Identity cihaz kimliğinin üretim aşamasında verilmesini ifade eder. Private key secure element veya TPM içinde üretilebilir. Kimliğin üretim zinciri boyunca izlenebilir olması önemlidir. Üretim sisteminin ele geçirilmesi tüm cihaz filosu için risk oluşturabilir. Bu nedenle manufacturing credential süreçleri de supply chain güvenliğinin parçasıdır.

Device Certificate

Device certificate cihazın merkezi sisteme kendisini cryptographic olarak tanıtmasını sağlar. Certificate cihazın benzersiz kimliğiyle eşleştirilmelidir. Private key mümkün olduğunca donanımda tutulmalıdır. Sertifika süresi sınırsız bırakılmamalıdır. Rotation ve revocation mekanizması filonun operasyon modeline dahil edilmelidir.

X.509 Sertifikaları

X.509 sertifikaları cihaz ve servis kimliğinde yaygın biçimde kullanılır. mTLS bağlantılarında iki tarafın birbirini doğrulamasını sağlar. Certificate Authority yapısının erişimi güçlü biçimde korunmalıdır. Sertifika subject ve extension alanları yetkilendirme kararlarında kullanılabilir. Büyük filolarda otomatik issuance ve renewal süreci gereklidir.

Certificate Rotation

Certificate rotation belirli aralıklarla yeni sertifika üretilmesini sağlar. Kısa geçerlilik süresi çalınmış credential'ın kullanılabileceği zamanı azaltır. Rotation bağlantı kesintisi durumunu da dikkate almalıdır. Cihaz yeni certificate'i önceden alabilir veya kontrollü grace period kullanılabilir. Süreç tamamen otomatik olmalıdır.

Certificate Revocation

Revocation güveni kaybedilen cihaz sertifikasının kullanılmasını engeller. Çalınan veya ele geçirilen cihaz için kritik bir kontroldür. Merkezi deny list veya certificate status mekanizması kullanılabilir. Offline edge senaryolarında revocation bilgisinin yerel cache'e güvenli biçimde dağıtılması gerekir. Revocation olayları audit kaydına eklenmelidir.

Cihazın İlk Provisioning Süreci

İlk provisioning cihazın güvenli filoya dahil edildiği aşamadır. Varsayılan parola veya ortak bootstrap key uzun süre kullanılmamalıdır. Cihaz ilk bağlantıda benzersiz kimliğini oluşturmalı veya güvenli biçimde almalıdır. Gerekli policy, certificate ve trust bundle bu aşamada yüklenebilir. Provisioning tamamlandığında bootstrap credential iptal edilmelidir.

Zero Trust Edge Mimarisi

Zero Trust modeli edge ortamlarında ağ konumuna güvenmek yerine her kullanıcı, cihaz ve workload bağlantısını ayrı olarak doğrular. Bu yaklaşım farklı lokasyonlarda çalışan edge sistemleri için doğal bir uyum sağlar. Bir cihaz şirket ağı içinde olsa bile otomatik olarak güvenilir kabul edilmez. Kimlik, cihaz durumu, policy ve çalışma bağlamı erişim kararına dahil edilir. Edge Computing Mimarisinde DevSecOps Pratikleri uygulanırken Zero Trust, pipeline'dan runtime'a kadar ortak güvenlik dili sağlayabilir.

Never Trust, Always Verify İlkesi

Bu ilke her erişim talebinin doğrulanmasını gerektirir. Önceki başarılı bağlantı gelecekteki bağlantı için sınırsız güven oluşturmaz. Kullanıcı, cihaz ve workload kimliği kontrol edilir. Gerekirse device posture veya attestation sinyali değerlendirilir. Yetki mümkün olan en dar kapsamda verilir.

Network Konumuna Güvenmeme

Edge cihazın belirli bir VLAN içinde olması güvenilir olduğunu kanıtlamaz. Yerel ağ ele geçirilmiş veya yanlış yapılandırılmış olabilir. Kimlik doğrulama uygulama ve servis seviyesinde devam etmelidir. mTLS bu modelde güçlü bir araçtır. Network segmentasyonu ise kimlik tabanlı güvenliğin ek savunma katmanıdır.

Kullanıcı Kimliği

Kullanıcı kimliği yönetim işlemlerinin kimin tarafından yapıldığını belirler. Ortak yönetici hesaplarından kaçınılmalıdır. MFA ve role-based erişim kullanılmalıdır. Yüksek riskli işlemler ek approval gerektirebilir. Audit log kullanıcı kimliğini her değişiklikle ilişkilendirmelidir.

Device Identity

Device Identity fiziksel edge node'un doğrulanabilir kimliğidir. Certificate ve hardware-backed private key bu kimliği güçlendirir. Kimliğin asset inventory ile eşleşmesi gerekir. Ele geçirilen cihazın kimliği iptal edilebilir. Device posture erişim kararına ek sinyal sağlayabilir.

Workload Identity

Workload Identity uygulama veya container'ın kendi kimliğine sahip olmasını sağlar. Böylece bütün workload'ların node credential'ını paylaşması gerekmez. Kısa ömürlü certificate statik secret kullanımını azaltır. Servis erişimi workload rolüne göre sınırlandırılabilir. SPIFFE benzeri modeller büyük ortamlarda bu süreci standartlaştırabilir.

Service Identity

Service Identity servisler arası iletişimde kimin kime bağlandığını doğrular. DNS adı tek başına güvenilir kimlik olarak görülmemelidir. Certificate tabanlı servis kimliği mTLS ile birlikte kullanılabilir. Yetkilendirme servis kimliğine göre yapılabilir. Bu yaklaşım lateral movement riskini azaltır.

Least Privilege

Least Privilege kullanıcı ve workload'a yalnızca gerekli izinlerin verilmesini ifade eder. Geniş administrator roller kısa vadede kolay görünse de uzun vadede riski artırır. Pipeline, runtime ve yönetim rolleri birbirinden ayrılmalıdır. Geçici görevlerde zaman sınırlı yetki kullanılabilir. Kullanılmayan izinler düzenli olarak gözden geçirilmelidir.

Continuous Verification

Continuous Verification güven kararının yalnızca oturum başında verilmemesini amaçlar. Certificate durumu, device posture ve policy uyumu zaman içinde değişebilir. Sistem bu sinyalleri sürekli değerlendirebilir. Risk arttığında erişim daraltılabilir veya cihaz quarantine edilebilir. Bu yaklaşım özellikle uzun süre çevrim içi kalan edge node'larda faydalıdır.

Workload Identity Yönetimi

Workload identity, edge üzerindeki servislerin statik kullanıcı adı ve parola paylaşmadan birbirini doğrulamasını sağlar. Özellikle container tabanlı mimarilerde her workload'a ayrı kimlik vermek lateral movement riskini azaltır. Kısa ömürlü certificate ve otomatik rotation operasyon yükünü düşürür. Edge ile cloud arasındaki servis trafiği mTLS ile korunabilir. Böylece credential yönetimi deployment package içine secret gömmek yerine dinamik kimlik modeline taşınır.

Statik Credential Problemi

Statik credential uzun süre aynı kaldığı için sızdırıldığında geniş zaman penceresi oluşturur. Container image içine gömülen key özellikle risklidir. Image registry veya build log üzerinden bilgi açığa çıkabilir. Statik secret yerine dinamik kimlik tercih edilmelidir. Zorunlu durumlarda erişim kapsamı ve geçerlilik süresi minimum tutulmalıdır.

Short-Lived Credential

Short-lived credential kısa süre geçerli olduğu için sızıntının etkisini sınırlar. Workload başlatıldığında otomatik olarak alınabilir. Süre dolduğunda yenileme kimlik sistemi üzerinden yapılır. Manuel secret rotation ihtiyacı azalır. Offline edge senaryosunda geçerlilik süresi bağlantı koşullarına göre dikkatle ayarlanmalıdır.

Workload Certificate

Workload certificate uygulamanın cryptographic kimliğini temsil eder. Her servis veya workload için ayrı certificate üretilebilir. mTLS bağlantısı sırasında karşı taraf kimliği doğrulanır. Certificate içindeki identity bilgisi authorization kararında kullanılabilir. Private key yaşam döngüsü workload ile birlikte yönetilmelidir.

SPIFFE/SPIRE Yaklaşımı

SPIFFE workload identity için ortak bir kimlik standardı sunar. SPIRE bu kimliklerin dağıtılması ve doğrulanması için kullanılabilecek bir uygulamadır. Workload'lar statik secret yerine kısa ömürlü identity belgesi alabilir. Edge node attestation ile kimlik verme süreci güçlendirilebilir. Kaynak kısıtlı cihazlarda agent maliyeti ölçülmelidir.

Service-to-Service Authentication

Servisler arası authentication her çağrının kim tarafından yapıldığını doğrular. Aynı cluster içinde olmak otomatik güven nedeni olmamalıdır. mTLS veya token tabanlı kısa süreli kimlik kullanılabilir. Authorization çağrıyı yapan service identity üzerinden uygulanabilir. Bu model mikro segmentasyon politikalarını daha anlamlı hale getirir.

Edge ve Cloud Arasında mTLS

mTLS hem edge hem cloud tarafının certificate ile birbirini doğrulamasını sağlar. Trafik şifrelenirken sunucu kimliğine ek olarak istemci kimliği de doğrulanır. Cihaz veya workload certificate'i bu bağlantıda kullanılabilir. Certificate rotation otomatik olmalıdır. Bağlantı kesintilerinde certificate expiry senaryosu ayrıca test edilmelidir.

Network Security ve Micro-Segmentation

Edge ağlarında güvenlik yalnızca dışarıdan gelen trafiği engellemekle sınırlı tutulmamalıdır. Ele geçirilmiş bir cihazın aynı lokasyondaki diğer sistemlere erişmesi de ciddi risk oluşturur. Micro-segmentation servis, workload ve cihaz grupları arasında kontrollü iletişim sağlar. Default-deny yaklaşımı yalnızca izin verilen trafiğin geçmesini hedefler. Kubernetes NetworkPolicy, firewall ve gateway politikaları birlikte kullanıldığında katmanlı bir ağ güvenliği oluşturulabilir.

Edge Network Segmentasyonu

Edge cihazlar işlevlerine göre farklı network segmentlerine ayrılabilir. Yönetim, workload ve OT trafiğinin aynı ağda tutulmaması tercih edilir. Segmentler arasındaki iletişim açık kurallarla sınırlandırılmalıdır. Firewall logları beklenmeyen bağlantıları görünür hale getirir. Segmentasyon incident sırasında etki alanını azaltır.

Default-Deny Yaklaşımı

Default-deny politikası tanımlanmamış iletişimi otomatik olarak engeller. Yalnızca gerekli servis akışlarına açık izin verilir. Bu yaklaşım yanlış yapılandırılmış yeni workload'ların gereksiz erişim kazanmasını önler. Policy değişiklikleri code review sürecinden geçebilir. Test ortamında uygulama bağımlılıklarının gerçekten gerekli bağlantıları belirlenmelidir.

Kubernetes NetworkPolicy

NetworkPolicy pod seviyesinde ağ erişimini sınırlandırmak için kullanılır. Namespace veya label tabanlı kurallar oluşturulabilir. Ingress ve egress ayrı ayrı kontrol edilebilir. Kullanılan CNI bileşeninin NetworkPolicy desteği doğrulanmalıdır. Policy'ler deployment öncesinde otomatik test edilebilir.

East-West Trafik Güvenliği

East-West trafik aynı ortam içindeki servisler arasında gerçekleşir. Saldırgan bir workload ele geçirdiğinde bu trafik üzerinden yatay hareket etmeye çalışabilir. mTLS ve NetworkPolicy birlikte koruma sağlar. Servis kimliği authorization kararında kullanılabilir. Olağan dışı east-west trafik runtime monitoring tarafından izlenmelidir.

North-South Trafik Güvenliği

North-South trafik edge ortamı ile dış ağlar arasındaki iletişimi ifade eder. Gateway, firewall ve ingress kontrolü bu noktada önemlidir. Dış bağlantılar TLS ile korunmalıdır. Gereksiz yönetim servisleri internete açık bırakılmamalıdır. Public erişim gerekiyorsa rate limit ve güçlü authentication uygulanmalıdır.

Egress Filtering

Egress filtering workload'ların hangi dış sistemlere bağlanabileceğini sınırlar. Ele geçirilmiş bir container'ın komuta kontrol sunucusuna bağlanmasını zorlaştırabilir. Registry, API ve update endpoint gibi gerekli hedefler allowlist'e alınabilir. IP yerine güvenilir domain veya proxy yaklaşımı bazı ortamlarda daha yönetilebilir olabilir. Egress logları güvenlik incelemelerinde önemli veri sağlar.

DNS Güvenliği

DNS trafiği saldırgan faaliyetleri hakkında güçlü sinyaller verebilir. Beklenmeyen domain sorguları compromise göstergesi olabilir. Edge ortamında güvenilir resolver kullanılması tercih edilir. DNS policy ile belirli workload'ların sorgu alanı sınırlandırılabilir. Bağlantı kesintileri nedeniyle gerekli DNS cache davranışı da test edilmelidir.

Firewall ve Gateway Politikaları

Firewall ve gateway edge güvenlik sınırının önemli parçalarıdır. Kurallar mümkün olduğunca merkezi policy üzerinden yönetilmelidir. Manuel ve belgelenmemiş kural ekleme configuration drift oluşturur. Yönetim erişimi ayrı network üzerinden sınırlandırılabilir. Policy değişiklikleri audit kaydında tutulmalıdır.

Edge Ortamında Service Mesh Kullanılmalı mı?

Service mesh mTLS, servis kimliği, trafik politikası ve observability açısından güçlü imkanlar sunar. Ancak edge ortamında karar verirken CPU, RAM ve network maliyeti mutlaka ölçülmelidir. Küçük cihazlarda her pod yanında sidecar çalıştırmak beklenenden daha yüksek kaynak tüketebilir. Daha güçlü edge cluster'larda service mesh güvenlik ve görünürlük açısından faydalı olabilir. Seçim teknoloji popülerliğine göre değil gerçek workload ve cihaz kapasitesine göre yapılmalıdır.

Service Mesh'in Avantajları

Service mesh uygulama kodunu değiştirmeden servisler arası güvenlik kontrolleri sunabilir. mTLS ve traffic policy merkezi olarak yönetilebilir. Service identity standart hale getirilebilir. Telemetry toplama daha tutarlı olur. Çok sayıda mikroservisin bulunduğu edge cluster'larda operasyon kolaylığı sağlayabilir.

mTLS

Service mesh servisler arası mTLS yönetimini otomatikleştirebilir. Certificate issuance ve rotation uygulamadan bağımsız yürütülür. Her servis diğer servisin kimliğini doğrular. Şifrelenmemiş internal trafik azaltılır. Kaynak maliyeti edge donanımı üzerinde ayrıca ölçülmelidir.

Service Identity

Mesh katmanı workload kimliğini iletişim politikasına bağlayabilir. IP adresi değişse bile servis kimliği sabit mantıkla yönetilebilir. Authorization kuralları identity üzerinden uygulanır. Bu özellik dinamik Kubernetes ortamında faydalıdır. Kimlik altyapısının control plane bağlantısı kesildiğinde davranışı test edilmelidir.

Traffic Policy

Traffic policy servisler arasındaki route, retry ve erişim kurallarını yönetir. Canary deployment sırasında belirli trafik oranı yeni sürüme yönlendirilebilir. Güvenlik açısından beklenmeyen servis çağrıları engellenebilir. Policy değişiklikleri Git üzerinden yönetilebilir. Edge bağlantı koşullarında retry davranışının aşırı trafik oluşturmadığı doğrulanmalıdır.

Observability

Service mesh servis trafiği hakkında ayrıntılı telemetry üretir. Request latency, hata oranı ve bağlantı bilgileri merkezi sisteme aktarılabilir. Güvenlik olaylarının servis bazında incelenmesi kolaylaşır. Ancak yüksek log ve metric hacmi düşük bant genişliğinde sorun oluşturabilir. Edge ortamında örnekleme ve yerel aggregation uygulanabilir.

Resource Overhead

Service mesh ek proxy ve control bileşenleri nedeniyle kaynak tüketir. Küçük ARM cihazlarda bu maliyet uygulamanın kendisinden daha belirgin olabilir. CPU, memory ve startup süresi ölçülmelidir. Sidecar yerine daha hafif mimariler değerlendirilebilir. Güvenlik faydası ile operasyon maliyeti birlikte değerlendirilmelidir.

Service Mesh'in Edge'de Uygun Olmadığı Senaryolar

Tek servis çalışan küçük cihazlarda service mesh gereksiz yük oluşturabilir. Çok düşük memory kapasitesi bulunan node'larda sidecar modeli uygun olmayabilir. Uzun süre tamamen offline çalışan sistemlerde merkezi control bağımlılığı sorun yaratabilir. Basit mTLS ve firewall politikası daha hafif çözüm olabilir. Mimari karar gerçek tehdit modeli ve kaynak profiline dayanmalıdır.

Edge DevSecOps CI/CD Mimarisi

Edge DevSecOps CI/CD mimarisi kaynak koddan çalışan edge workload'a kadar güven zincirini korumalıdır. Pipeline yalnızca build yapan bir sistem değil aynı zamanda security scanning, SBOM, signing, provenance ve policy validation katmanıdır. Üretilen artifact immutable digest ile registry'ye gönderilmeli ve edge'e dağıtılmadan önce kimliği doğrulanmalıdır. GitOps yaklaşımı deployment state'ini kodla yöneterek manuel değişiklikleri azaltır. Kurum içi registry tasarımını derinleştirmek isteyen ekipler https://www.diyarbakiryazilim.com.tr/posts/kurum-ici-docker-registry-kurulumu-ve-yonetimi adresindeki içeriği de inceleyebilir.

Source Code Repository

Source repository pipeline'ın başlangıç noktasıdır. Branch protection ve mandatory review uygulanmalıdır. MFA geliştirici hesaplarında zorunlu tutulabilir. Signed commit yüksek güven gerektiren projelerde ek kontrol sağlar. Repository erişimleri düzenli olarak gözden geçirilmelidir.

CI Runner

CI runner güvenilmeyen kaynak kodu ve build script'lerini çalıştırdığı için yüksek riskli bir bileşendir. Runner izolasyonu önemlidir. Mümkünse her build sonrası silinen ephemeral runner kullanılmalıdır. Production ağına doğrudan erişim verilmemelidir. Runner loglarında secret sızıntısı kontrol edilmelidir.

Security Scanning

Security scanning pipeline boyunca birden fazla katmanda yapılmalıdır. SAST, SCA, secret scan ve IaC kontrolleri birbirini tamamlar. Tek scanner bütün riskleri tespit edemez. Kritik sonuçlar build'i durduracak policy ile bağlanabilir. False positive yönetimi ekiplerin scanner'a güvenmesini korur.

Build

Build aşaması güvenilir ve tekrarlanabilir olmalıdır. Dependency sürümleri sabitlenmelidir. Build ortamı mümkün olduğunca ephemeral tutulmalıdır. Multi-architecture image üretimi hedef cihazlarla uyumlu test edilmelidir. Build çıktısının digest değeri sonraki aşamalarda korunmalıdır.

SBOM Generation

Her build için SBOM üretmek kullanılan dependency ve paketleri görünür hale getirir. SBOM artifact sürümüyle doğrudan ilişkilendirilmelidir. Yeni CVE çıktığında hangi image'ların etkilendiği daha hızlı bulunabilir. SBOM registry veya ayrı güvenilir depoda saklanabilir. Üretim tarihi ve build kimliği metadata içinde tutulmalıdır.

Artifact Signing

Artifact signing üretilen image veya firmware'in güvenilir kaynaktan geldiğini kanıtlar. İmza build sonrasında oluşturulmalıdır. Signing key erişimi CI sistemindeki normal credential'lardan ayrılmalıdır. Keyless signing uygun ortamda operasyon yükünü azaltabilir. Edge deployment sırasında signature doğrulanmadan artifact çalıştırılmamalıdır.

Container Registry

Registry üretim artifact'larının merkezi deposudur. Erişim rolleri push ve pull görevlerine göre ayrılmalıdır. Production image'ların üzerine yazılmasına izin verilmemesi tercih edilir. Immutable digest kullanımı hangi binary'nin çalıştığını netleştirir. Registry güvenliği software supply chain güvenliğinin kritik bir parçasıdır.

Policy Validation

Policy validation deployment manifest'inin güvenlik kurallarına uyup uymadığını kontrol eder. Privileged container, latest tag veya aşırı yetkili pod pipeline aşamasında reddedilebilir. Aynı policy admission control tarafında yeniden uygulanabilir. Böylece CI bypass edilse bile ikinci kontrol bulunur. Policy değişiklikleri de code review sürecine tabi olmalıdır.

GitOps Repository

GitOps repository üretimde istenen desired state'i tanımlar. Uygulama image digest'i ve Kubernetes manifest burada tutulabilir. Production değişiklikleri pull request üzerinden yönetilebilir. Repository erişimi yüksek güvenlik seviyesiyle korunmalıdır. Git geçmişi değişikliklerin kim tarafından yapıldığını takip etmeyi kolaylaştırır.

Edge Deployment

Edge deployment tek adımda bütün filoya yapılmamalıdır. Pilot ve canary grupları önce güncellenmelidir. Health ve security metrikleri normal kaldığında rollout genişletilir. Bağlantısı olmayan cihazlar güncellemeyi güvenli biçimde daha sonra alabilir. Deployment sistemi aynı artifact'ın bütün cihazlarda doğrulanmasını sağlamalıdır.

Runtime Monitoring

Deployment başarıyla tamamlandığında güvenlik süreci bitmez. Runtime monitoring process, network ve file davranışını izler. Beklenmeyen privilege escalation erken uyarı üretebilir. Edge bağlantısı kesik olduğunda olaylar yerel buffer'da tutulabilir. Merkezi bağlantı geri geldiğinde öncelikli güvenlik kayıtları senkronize edilir.

Shift-Left Security Edge Pipeline'a Nasıl Eklenir?

Shift-left yaklaşımında güvenlik geri bildirimini developer'a mümkün olduğunca erken vermek hedeflenir. Secret scanning, SAST, SCA, IaC ve container kontrolleri pull request aşamasına yerleştirilebilir. Amaç her uyarıda süreci durdurmak değil gerçek risk taşıyan bulguları hızlı biçimde ayırmaktır. Policy eşikleri ortamın risk seviyesine göre belirlenmelidir. İyi tasarlanmış bir pipeline güvenliği görünmez bir engel değil developer'ın günlük çalışma aracına dönüştürür.

Pre-Commit Security Kontrolleri

Pre-commit kontrolleri kod repository'ye ulaşmadan temel hataları yakalayabilir. Secret pattern, yanlış dosya izni veya policy hatası burada kontrol edilebilir. Kontroller hızlı olmalıdır. Çok uzun çalışan testler geliştiricilerin bunları devre dışı bırakmasına yol açabilir. Daha ağır taramalar CI aşamasına bırakılabilir.

Secret Scanning

Secret scanning API key, private key ve credential örüntülerini arar. Git geçmişine giren secret sonradan dosyadan silinse bile risk devam eder. Tespit edilen gerçek secret derhal rotate edilmelidir. False positive için kontrollü exception mekanizması bulunmalıdır. Pipeline logları da secret sızıntısı açısından incelenmelidir.

Static Application Security Testing (SAST)

SAST kaynak kodu çalıştırmadan güvenlik sorunlarını analiz eder. Injection, unsafe API veya hatalı input validation gibi problemleri işaretleyebilir. Sonuçlar developer'a pull request içinde gösterilebilir. Kritik severity bulgular policy ile build'i durdurabilir. Kural seti kullanılan dil ve framework'e göre ayarlanmalıdır.

Software Composition Analysis (SCA)

SCA üçüncü taraf dependency ve açık kaynak paketlerdeki bilinen riskleri tespit eder. Modern uygulamalarda kodun önemli bölümü dependency'lerden gelir. CVE bilgisi tek başına karar vermek için yeterli değildir. Exploitability ve runtime reachability dikkate alınmalıdır. Güncelleme yapılırken breaking change riski de test edilmelidir.

IaC Scanning

IaC scanning Terraform, Ansible veya cloud configuration içindeki güvenlik hatalarını arar. Açık firewall, zayıf encryption veya geniş IAM rolü erken yakalanabilir. Policy-as-code ile kurum standartları uygulanabilir. Tarama pull request aşamasında çalıştırılmalıdır. Production'a çıktıktan sonra aynı ayarların drift edip etmediği ayrıca izlenmelidir.

Container Image Scanning

Container image scanning OS paketleri ve uygulama dependency'lerindeki bilinen vulnerability'leri tespit eder. Base image seçimi sonuç üzerinde büyük etkiye sahiptir. Gereksiz paketler image'dan çıkarılmalıdır. Kritik açık bulunan image policy gereği registry promotion alamayabilir. Scan sonuçları SBOM ile ilişkilendirildiğinde filo analizi kolaylaşır.

Kubernetes Manifest Scanning

Manifest scanning workload güvenlik ayarlarını deployment öncesi kontrol eder. Privileged, hostNetwork, hostPath veya root çalışma gibi riskli konfigürasyonlar tespit edilebilir. Resource limit eksikliği de operasyon riski olarak işaretlenebilir. Kurum standardına göre policy seti oluşturulmalıdır. Aynı kurallar admission aşamasında da uygulanabilir.

Policy-as-Code Testleri

Policy-as-Code güvenlik kurallarını version control altında yönetilebilir hale getirir. Her policy değişikliği test edilebilir ve review alabilir. Örnek manifest'lerle olumlu ve olumsuz test senaryoları hazırlanabilir. Policy'nin production deployment'ı yanlışlıkla engellemesi böylece daha erken fark edilir. Edge filolarında merkezi policy ile yerel enforcement birlikte kullanılabilir.

CI/CD Pipeline'ın Kendisi Nasıl Güvenli Hale Getirilir?

Güvenli uygulama üretmek için kullanılan pipeline'ın kendisi güvensizse bütün güven zinciri bozulabilir. CI runner, third-party action, dependency, build script ve credential'lar ayrı saldırı yüzeyleri oluşturur. Pipeline erişimi production erişimiyle aynı seviyede görülmemelidir. Build ortamı izole ve kısa ömürlü tutulduğunda kalıcılık riski azalır. Software supply chain olaylarının önemli kısmı build altyapısına güven varsayımının sorgulanmamasından kaynaklanabilir.

Pipeline'ın da Bir Saldırı Yüzeyi Olduğunu Kabul Etmek

Pipeline kodu otomatik olarak çalıştırdığı için saldırgan açısından değerli hedeftir. Zararlı pull request runner üzerinde komut çalıştırabilir. Build credential'ları bu ortamdan korunmalıdır. Pipeline değişiklikleri normal uygulama kodu kadar dikkatli review edilmelidir. Audit log bütün yüksek yetkili işlemleri kaydetmelidir.

CI Runner İzolasyonu

Runner'lar production sistemlerinden ağ seviyesinde ayrılmalıdır. Build başına izole ortam tercih edilebilir. Shared runner kullanımında workload'lar arasında veri kalmaması doğrulanmalıdır. Host filesystem erişimi minimum tutulmalıdır. Runner image düzenli güncellenmelidir.

Ephemeral Runner

Ephemeral runner bir iş tamamlandıktan sonra tamamen silinir. Böylece önceki build'den kalan zararlı süreç veya dosya sonraki işe taşınmaz. Temiz image üzerinden yeniden oluşturulur. Credential yalnızca job süresince verilebilir. Büyük CI ortamlarında otomatik ölçekleme ile birlikte etkili bir modeldir.

Privileged Container Kullanımını Sınırlamak

Privileged container host üzerinde geniş yetkiler elde edebilir. Container build işlemleri için varsayılan olarak privileged moda ihtiyaç olduğu düşünülmemelidir. Rootless veya izole build yöntemleri değerlendirilebilir. Zorunlu kullanım ayrı runner pool ile sınırlandırılabilir. Bu runner'lara production credential verilmemelidir.

Build Network Egress Kontrolü

Build job'larının sınırsız internet erişimi supply chain riskini artırabilir. Gerekli package repository ve registry hedefleri allowlist'e alınabilir. Proxy üzerinden trafik kaydı tutulabilir. Beklenmeyen domain bağlantıları güvenlik alarmı üretebilir. Dependency mirror kullanımı hem güvenlik hem tekrar üretilebilirlik açısından fayda sağlar.

Pipeline Script Review

Pipeline script'leri production artifact'ın nasıl üretildiğini belirler. Küçük bir script değişikliği build çıktısını tamamen değiştirebilir. Bu dosyalar CODEOWNERS ile güvenlik veya platform ekibi review'una bağlanabilir. Direct push kapatılmalıdır. Değişiklik geçmişi audit için korunmalıdır.

Third-Party CI Action Riskleri

Üçüncü taraf action veya plugin pipeline içinde kod çalıştırır. Proje hesabı ele geçirilirse zararlı sürüm yayınlanabilir. Kullanılan bileşenler güvenilir kaynaklardan seçilmelidir. Sürüm pinning uygulanmalıdır. Kritik pipeline'larda bağımlılıkların iç mirror'a alınması değerlendirilebilir.

Dependency Pinning

Dependency pinning build sırasında hangi sürümün kullanılacağını kesinleştirir. Floating version kullanımı aynı koddan farklı çıktılar oluşmasına neden olabilir. Güvenlik açısından sonradan değiştirilmiş dependency'nin otomatik alınması riskini azaltır. Lock file'lar version control altında tutulmalıdır. Güncellemeler otomatik bot ile kontrollü pull request olarak yapılabilir.

Version Tag Yerine Immutable Reference

Mutable version tag zaman içinde farklı içeriğe işaret edebilir. Immutable reference belirli artifact veya source sürümünü sabitler. Böylece pipeline bugün ve yarın aynı referansı kullanır. Supply chain incelemesi sırasında hangi kodun çalıştığı netleşir. Güncelleme gerektiğinde referans bilinçli biçimde değiştirilir.

Commit SHA Pinning

Commit SHA üçüncü taraf action'ın tam kaynak sürümünü sabitler. Etiket daha sonra başka commit'e taşınsa bile pipeline etkilenmez. Bu yöntem yüksek güvenlik gerektiren workflow'larda değerlidir. SHA güncellemesi review sürecinden geçmelidir. Dependency update otomasyonu bu işi kolaylaştırabilir.

CI/CD Credential Yönetimi

Pipeline credential'ları production sistemlerine erişebildiği için yüksek değerli secret'lardır. Uzun süreli cloud key kullanmak yerine OIDC federation ve kısa ömürlü credential tercih edilmelidir. Build rolü production deployment rolünden ayrılmalıdır. Her job yalnızca ihtiyaç duyduğu izinleri almalıdır. Secret rotation ve audit süreçleri otomasyonun parçası olmalıdır.

Long-Lived Cloud Key Kullanımının Riskleri

Uzun ömürlü cloud key bir kez sızdığında aylarca kullanılabilir. Log, environment variable veya yanlış artifact içine girebilir. Anahtarın kim tarafından kullanıldığını ayırmak zorlaşır. Federation modeli bu kalıcı secret ihtiyacını azaltır. Mevcut long-lived key'ler düzenli envanter ve rotation sürecine alınmalıdır.

OIDC Federation

OIDC federation CI platformunun kimliğini cloud veya secret manager'a kanıtlamasını sağlar. Pipeline içine kalıcı access key koymaya gerek kalmaz. Job bilgisi ve repository gibi claim'ler authorization kararında kullanılabilir. Credential yalnızca kısa süre için üretilir. Production rolü belirli branch ve workflow ile sınırlandırılabilir.

Short-Lived Credential

Kısa süreli credential job tamamlandıktan sonra hızla geçersiz olur. Sızıntının kullanılabilir zamanını azaltır. Otomatik üretildiği için manuel rotation yükünü düşürür. Yetki kapsamı job ihtiyacına göre dar tutulabilir. Pipeline loglarında token değerleri maskelenmelidir.

Least-Privilege Pipeline Role

Pipeline rolüne yalnızca gerekli API işlemleri verilmelidir. Build job'ın production cluster yönetme yetkisine ihtiyacı yoktur. Deploy rolü ayrıca tanımlanabilir. Yetkiler repository ve environment bazında ayrılabilir. Kullanılmayan izinler düzenli review ile kaldırılmalıdır.

Production Credential'larını Build Credential'larından Ayırmak

Build ve production erişiminin aynı credential ile yapılması blast radius'u büyütür. Zararlı dependency build sırasında production ortamına ulaşabilir. Ayrı rol ve ağ politikaları bu riski azaltır. Promotion aşaması kontrollü trust boundary oluşturur. Production erişimi yalnızca doğrulanmış artifact için kullanılmalıdır.

Secret Rotation

Secret rotation credential'ın belirli aralıklarla değiştirilmesini sağlar. Otomatik rotation insan hatasını azaltır. Eski credential geçiş süresi sonunda iptal edilmelidir. Rotation başarısızlığı monitoring sisteminde görünür olmalıdır. Kritik secret'lar için acil rotation prosedürü hazırlanmalıdır.

Software Supply Chain Security

Software supply chain güvenliği kaynak koddan dependency'lere, build sisteminden registry'ye ve edge cihazdaki son artifact'a kadar bütün üretim zincirini kapsar. Güvenilir repository kullanmak tek başına yeterli değildir. Zararlı paket, ele geçirilmiş build runner veya değiştirilmiş container image aynı sonucu doğurabilir. SBOM, signing ve provenance bu zincirin görünürlüğünü artırır. Edge'e dağıtılacak her artifact için kaynağın ve bütünlüğün doğrulanması temel politika haline getirilmelidir.

Software Supply Chain Nedir?

Software supply chain yazılımın üretiminde kullanılan kod, dependency, araç, build sistemi ve dağıtım altyapısının tamamıdır. Bir ürün yalnızca geliştiricinin yazdığı source code'dan oluşmaz. Base image ve package repository de sonuç binary'sini etkiler. Her bileşen ayrı güven seviyesi gerektirir. Zincirin en zayıf halkası production sistemini etkileyebilir.

Dependency Riski

Dependency'ler dış kaynak kodu uygulamanın parçası haline getirir. Güvenlik açığı veya ele geçirilmiş package uygulamaya doğrudan taşınabilir. Sürüm pinning ve SCA riski azaltır. Kullanılmayan dependency'ler kaldırılmalıdır. Kritik dependency'lerin bakım ve release geçmişi de değerlendirilmelidir.

Malicious Package

Malicious package bilerek zararlı kod içeren dependency'dir. Install script üzerinden build ortamında credential çalmaya çalışabilir. Package kaynağı ve publisher bilgisi kontrol edilmelidir. İç repository mirror kullanmak ek kontrol noktası sağlar. Yeni dependency eklenmesi review gerektirebilir.

Typosquatting

Typosquatting popüler paket adına çok benzeyen zararlı package yayınlama yöntemidir. Küçük yazım hatası yanlış dependency'nin kurulmasına yol açabilir. Lock file ve internal allowlist bu riski azaltır. Dependency adı code review sırasında kontrol edilmelidir. Otomatik build'lerin bilinmeyen package kaynağına erişimi sınırlandırılabilir.

Compromised Build Pipeline

Ele geçirilmiş build pipeline source code güvenli olsa bile zararlı artifact üretebilir. Bu nedenle build provenance önemlidir. Runner izolasyonu ve least-privilege credential kullanılmalıdır. Artifact signing yalnızca doğrulanmış build ortamında yapılmalıdır. Şüpheli build provenance'a sahip artifact edge'e kabul edilmemelidir.

Registry Compromise

Registry compromise saldırganın image değiştirmesine veya yeni zararlı image eklemesine yol açabilir. Immutable digest ve signature verification bu riski azaltır. Push yetkisi dar kapsamlı olmalıdır. Registry audit log aktif tutulmalıdır. Edge yalnızca izin verilen registry ve imzalı artifact'tan deployment kabul etmelidir.

Manipüle Edilmiş Container Image

Container image build sonrasında değiştirilmiş olabilir. Tag adı bu değişikliği güvenilir şekilde göstermez. Digest belirli içeriği cryptographic olarak tanımlar. Signature bu digest'in yetkili üretici tarafından onaylandığını kanıtlar. Admission policy doğrulama başarısızsa deployment'ı durdurmalıdır.

Firmware Supply Chain Riski

Firmware cihazın düşük seviyeli davranışını kontrol ettiği için supply chain açısından kritiktir. Firmware build sistemi ayrı güvenlik kontrolleri gerektirir. İmzalanmamış firmware dağıtılmamalıdır. Update metadata da bütünlük açısından korunmalıdır. Firmware SBOM yeni vulnerability araştırmalarında değerli görünürlük sağlar.

SBOM Edge DevSecOps'ta Nasıl Kullanılır?

SBOM bir artifact içinde hangi yazılım bileşenlerinin bulunduğunu gösteren makine tarafından okunabilir envanterdir. Binlerce edge cihaz bulunan bir ortamda yeni CVE yayınlandığında hangi cihazların etkilenebileceğini hızla bulmak büyük avantaj sağlar. Container ve firmware için ayrı SBOM üretilebilir. SBOM her build ile ilişkilendirilmeli ve immutable artifact kimliğiyle saklanmalıdır. Edge Computing ortamlarında zero trust secrets management ve vulnerability scanning süreçleri bu envanterle birleştirildiğinde güvenlik ekibi yalnızca CVE sayısını değil gerçek cihaz etkisini değerlendirebilir.

Software Bill of Materials Nedir?

Software Bill of Materials yazılımın içerdiği bileşenlerin listelenmiş halidir. Paket adı, sürüm ve supplier gibi bilgiler bulunabilir. SBOM doğrudan vulnerability değildir. Risk analizine veri sağlar. Güncel asset inventory ile birleştirildiğinde daha anlamlı hale gelir.

Container SBOM

Container SBOM image içindeki OS package ve uygulama dependency'lerini listeler. Build sırasında otomatik üretilebilir. Image digest ile ilişkilendirilmesi önemlidir. Base image değiştiğinde yeni SBOM oluşmalıdır. Registry yanında saklanması operasyonu kolaylaştırır.

Firmware SBOM

Firmware SBOM cihaz firmware'i içindeki third-party bileşenleri görünür hale getirir. Uzun yaşam döngülü cihazlarda özellikle değerlidir. Yeni güvenlik açığı yayınlandığında hangi firmware sürümünün etkilendiği daha hızlı bulunur. Vendor bileşenleri de mümkün olduğunca dahil edilmelidir. Firmware release sürecinde otomatik üretim tercih edilmelidir.

SBOM Formatları

SBOM farklı standardize formatlarda üretilebilir. En yaygın seçenekler arasında SPDX ve CycloneDX bulunur. Araç ekosistemi ve entegrasyon gereksinimi seçimde önemlidir. Aynı organizasyonda ortak format kullanmak analiz süreçlerini kolaylaştırır. Format seçimi kadar SBOM'un doğru ve güncel olması da önemlidir.

SPDX

SPDX yazılım bileşenleri ve lisans bilgileri için yaygın kullanılan bir standarttır. Makine tarafından okunabilir formatları destekler. Supply chain araçlarıyla entegre edilebilir. Package ve dependency ilişkilerini ifade etmeye imkan verir. Kurumsal SBOM süreçlerinde güçlü bir seçenektir.

CycloneDX

CycloneDX güvenlik ve supply chain kullanımına odaklanan SBOM standardıdır. Component, dependency ve vulnerability ilişkilerini temsil edebilir. Container ve uygulama ekosisteminde sık kullanılır. Otomatik scanner'larla kolayca entegre edilebilir. Format seçimi mevcut toolchain ile uyumlu yapılmalıdır.

Her Build'de SBOM Üretmek

SBOM manuel üretildiğinde hızla güncelliğini kaybeder. CI pipeline her build sırasında otomatik SBOM oluşturmalıdır. Üretilen belge artifact digest'iyle eşleşmelidir. Build başarısızsa SBOM production kaydı olarak kullanılmamalıdır. Promotion aşamasında SBOM varlığı policy ile zorunlu hale getirilebilir.

SBOM'u Artifact ile İlişkilendirmek

SBOM hangi artifact'a ait olduğu net biçimde bilinmelidir. Image tag yerine digest kullanmak daha güvenilir bağ oluşturur. Attestation formatı bu ilişkiyi cryptographic olarak kanıtlayabilir. Registry metadata alanları da kullanılabilir. Vulnerability sorguları bu ilişki üzerinden doğru cihaz listesine ulaşır.

Yeni CVE Yayınlandığında Edge Filoyu Sorgulamak

Yeni CVE yayınlandığında önce etkilenen package ve sürüm belirlenir. SBOM veritabanında bu bileşene sahip artifact'lar aranır. Sonra asset inventory üzerinden hangi edge cihazların bu artifact'ı çalıştırdığı bulunur. Exposure ve business criticality ile önceliklendirme yapılır. Böylece bütün filoya gereksiz acil patch göndermek yerine risk odaklı müdahale yapılabilir.

SBOM Tek Başına Neden Yeterli Değildir?

SBOM görünürlük sağlar fakat tek başına bir risk kararı değildir. Bir package üzerinde CVE bulunması ilgili uygulamanın mutlaka sömürülebilir olduğu anlamına gelmez. Runtime reachability, exploitability, cihazın internete açıklığı ve iş açısından önemi birlikte değerlendirilmelidir. Aynı CVE internete açık ödeme terminalinde ve kapalı laboratuvar cihazında farklı önceliğe sahip olabilir. Etkili vulnerability management, SBOM verisini operasyon ve tehdit bağlamıyla birleştirir.

CVE Görünürlüğü ve Gerçek Risk Arasındaki Fark

CVE bir bileşende bilinen güvenlik sorununu gösterir. Gerçek risk ise o açığın mevcut sistemde kullanılabilir olup olmadığıyla ilgilidir. Network exposure ve yapılandırma bu farkı etkiler. Otomatik scanner sonuçları doğrudan patch sırasına dönüştürülmemelidir. Risk bağlamı eklenmelidir.

Exploitability

Exploitability açığın pratikte sömürülme olasılığını ifade eder. Public exploit bulunması önceliği yükseltebilir. Gerekli ön koşullar dikkate alınmalıdır. Açığın sadece local access gerektirmesi bazı edge senaryolarında yine ciddi olabilir. Fiziksel erişim ihtimali edge için ayrıca değerlendirilmelidir.

Runtime Reachability

Runtime reachability vulnerable kod yolunun gerçekten çalışıp çalışmadığını değerlendirir. Dependency image içinde bulunabilir ancak uygulama tarafından kullanılmıyor olabilir. Bu bilgi patch önceliğini daha doğru belirlemeye yardım eder. Yine de kullanılmayan package kaldırılmalıdır. Daha küçük software footprint genel riski azaltır.

Asset Criticality

Asset criticality cihazın iş operasyonu üzerindeki önemini gösterir. Üretim hattını yöneten edge node ile test laboratuvarındaki cihaz aynı önceliğe sahip değildir. Criticality asset inventory içinde tanımlanmalıdır. Vulnerability score bu bilgiyle birlikte değerlendirilmelidir. Patch SLA buna göre farklılaşabilir.

Edge Lokasyonunun Risk Seviyesi

Lokasyon fiziksel ve network riskini doğrudan etkileyebilir. Kontrollü veri merkezi ile halka açık kiosk aynı güvenlik şartlarına sahip değildir. Fiziksel erişim ve internet exposure risk skoruna dahil edilebilir. Yüksek riskli lokasyon daha sık monitoring gerektirebilir. Deployment ring'leri de lokasyon riskine göre oluşturulabilir.

Vulnerability Prioritization

Prioritization severity, exploitability, exposure ve business impact bilgilerini birleştirir. Tek başına CVSS puanına göre patch sıralamak yeterli değildir. Aktif exploit bilgisi önceliği yükseltebilir. Compensating control bulunan sistemlerde risk geçici olarak azaltılabilir. Karar süreci kayıt altına alınmalıdır.

SLSA ve Build Provenance

SLSA yaklaşımı yazılım artifact'larının nasıl üretildiği konusunda güvenilir kanıt oluşturmayı hedefler. Build provenance source repository, build sistemi ve üretilen artifact arasındaki ilişkiyi görünür hale getirir. Edge deployment sırasında yalnızca imzayı değil artifact'ın beklenen pipeline tarafından üretilip üretilmediğini kontrol etmek güçlü bir supply chain savunmasıdır. Provenance özellikle CI sisteminin yanlış veya yetkisiz şekilde kullanıldığı durumlarda değer kazanır. Bu yapı signing ve SBOM ile birlikte ele alındığında artifact güveni önemli ölçüde artar.

Provenance Nedir?

Provenance artifact'ın nereden ve nasıl üretildiğini açıklayan metadata'dır. Source revision ve build sistemi bilgisi içerebilir. Güvenilir provenance cryptographic olarak imzalanabilir. Deployment policy bu bilgiyi doğrulayabilir. Böylece yalnızca dosyanın bütünlüğü değil üretim süreci de kontrol edilir.

Artifact Nerede ve Nasıl Üretildi?

Artifact'ın hangi CI runner üzerinde üretildiği güven açısından önemlidir. Yetkisiz geliştirici laptop'ında üretilen image production'a kabul edilmemelidir. Build environment kimliği provenance içinde gösterilebilir. Pipeline konfigürasyonu da kayıt altına alınabilir. Bu bilgiler incident incelemesinde güçlü kanıt sağlar.

Source Provenance

Source provenance artifact'ın hangi repository ve commit'ten geldiğini gösterir. İmzalı veya korumalı branch bilgisi güven sinyali olabilir. Commit değişirse yeni build gereklidir. Source ile binary arasındaki ilişki izlenebilir hale gelir. Yetkisiz kaynak koddan üretim riski azalır.

Build Provenance

Build provenance üretim ortamı, builder kimliği ve parametreleri hakkında bilgi sağlar. Build'in güvenilir pipeline üzerinden geçtiği doğrulanabilir. Artifact digest provenance ile bağlanır. Manipüle edilmiş registry içeriği bu doğrulamada fark edilebilir. Policy production'a yalnızca uygun provenance taşıyan artifact kabul edebilir.

Build Ortamının Güvenilirliği

Build environment güvenilir değilse provenance değeri de düşer. Ephemeral runner ve hardened build image tercih edilmelidir. Runner yönetici erişimi sınırlandırılmalıdır. Build log ve audit verisi korunmalıdır. Builder identity merkezi trust policy içine dahil edilmelidir.

Artifact'ın Kaynak Koda Kadar İzlenebilirliği

Her production artifact belirli source commit'e kadar izlenebilmelidir. Digest, build ID ve commit SHA arasında açık ilişki kurulmalıdır. Bu ilişki release sırasında otomatik kaydedilmelidir. Bir güvenlik olayı çıktığında ilgili kod değişikliği hızla bulunabilir. Rollback yapılacak güvenilir sürüm de daha kolay belirlenir.

Edge Deployment Öncesi Provenance Doğrulama

Edge deployment agent artifact'ı çalıştırmadan önce provenance policy'sini kontrol edebilir. Beklenen builder kullanılmamışsa deployment reddedilir. Source repository veya branch allowlist'i uygulanabilir. Offline ortamlarda gerekli trust metadata önceden paketlenebilir. Doğrulama başarısızlığının merkezi sisteme raporlanması gerekir.

Artifact Signing ve Attestation

Artifact signing container image, firmware ve diğer dağıtım paketlerinin bütünlüğünü ve kaynağını doğrulamak için kullanılır. Attestation ise artifact hakkında SBOM, provenance veya test sonucu gibi ek iddiaları güvenilir biçimde ilişkilendirir. Production edge cihazları yalnızca yetkili pipeline tarafından imzalanmış artifact'ları çalıştırmalıdır. Signing key yönetimi sistemin en hassas noktalarından biridir. Keyless signing uygun kimlik altyapısı bulunan kurumlarda kalıcı key yönetim yükünü azaltabilir.

Container Image Neden İmzalanmalı?

Container registry tek başına image'ın güvenilir olduğunu garanti etmez. Registry hesabı ele geçirilmiş olabilir. Signature image digest'inin yetkili üretici tarafından onaylandığını gösterir. Admission policy imzayı deployment öncesi doğrulayabilir. Tag değişse bile digest ve signature ilişkisi korunur.

Firmware Neden İmzalanmalı?

Firmware cihazın en temel çalışma katmanlarından biridir. Yetkisiz firmware bütün sistemi kontrol edebilir. Digital signature update paketinin kaynağını doğrular. Cihaz public trust key ile imzayı kontrol eder. İmza doğrulanmazsa update uygulanmamalıdır.

Cosign ile Artifact Signing

Cosign container image ve diğer artifact'ları imzalamak için kullanılabilir. Registry ile doğal biçimde çalışabilir. Key tabanlı ve keyless modeller desteklenebilir. Signature verification admission policy içine eklenebilir. Pipeline üzerinde signing işlemi güvenilir build sonrasında yapılmalıdır.

Keyless Signing

Keyless signing uzun ömürlü signing key'i CI sisteminde saklama ihtiyacını azaltır. Kısa süreli kimlik ve şeffaflık kaydı kullanılabilir. Pipeline kimliği signing işlemiyle ilişkilendirilebilir. Trust policy kabul edilen issuer ve identity'leri sınırlar. Offline edge doğrulaması için gerekli trust materyali önceden hazırlanmalıdır.

Attestation

Attestation artifact hakkında doğrulanabilir metadata taşır. Security scan sonucu veya build provenance buna örnek olabilir. Attestation artifact digest'iyle bağlanmalıdır. Policy yalnızca belirli attestation şartlarını sağlayan artifact'a izin verebilir. Bu model security gate'leri daha güçlü hale getirir.

SBOM Attestation

SBOM attestation belirli SBOM'un belirli artifact'a ait olduğunu doğrulamaya yardımcı olur. Belge sonradan değiştirilirse doğrulama başarısız olur. Vulnerability platformu güvenilir SBOM'u kullanabilir. Release policy SBOM bulunmasını zorunlu tutabilir. Bu kontrol supply chain görünürlüğünü artırır.

Provenance Attestation

Provenance attestation build bilgisini artifact'a cryptographic olarak bağlar. Deployment sırasında builder identity doğrulanabilir. Beklenmeyen pipeline tarafından üretilen artifact reddedilebilir. Source revision politikası uygulanabilir. Bu yapı image signing ile birlikte daha güçlü sonuç verir.

İmzalanmamış Artifact'ın Edge'e Dağıtılmasını Önlemek

Signing ancak deployment sırasında doğrulanıyorsa gerçek güvenlik kontrolüne dönüşür. Edge cluster veya deployment agent imzasız artifact'ı varsayılan olarak reddetmelidir. Allowed registry, image digest ve signature verification kuralları tek policy setinde toplanabilir. Pipeline bypass edilse bile admission control son güvenlik kapısı olarak çalışır. Offline edge ortamında verification için gerekli public trust bilgileri yerel olarak güvenli biçimde saklanmalıdır.

Admission Control

Admission control Kubernetes objesi cluster'a kabul edilmeden önce policy uygular. İmza ve manifest güvenliği burada doğrulanabilir. Riskli pod konfigürasyonu reddedilebilir. Policy merkezi olarak geliştirilip edge cluster'lara dağıtılabilir. Bağlantı yokken yerel enforcement devam etmelidir.

Signature Verification

Signature verification artifact digest'i üzerindeki imzayı kontrol eder. Güvenilir signer identity veya public key policy içinde tanımlanır. İmza yoksa deployment durdurulur. Geçersiz imza güvenlik olayı olarak loglanır. Trust key rotation süreci dikkatle planlanmalıdır.

Allowed Registry Politikası

Allowed registry policy yalnızca onaylı registry kaynaklarından image kullanılmasına izin verir. Public registry'den doğrudan production deployment engellenebilir. Mirror veya internal registry kullanımı desteklenebilir. Registry adresi manifest kontrolünde doğrulanır. Bu politika supply chain kontrol alanını daraltır.

Image Digest Kullanımı

Image digest container içeriğinin immutable kimliğidir. Tag aynı kalsa bile içerik değişebilir. Digest kullanımı hangi image'ın deployment edildiğini kesinleştirir. GitOps manifest içinde digest tutulabilir. Rollback sırasında da güvenilir önceki sürüm kolayca seçilir.

latest Tag Kullanımını Engellemek

latest tag hangi sürümün çalışacağını belirsiz hale getirir. Production ortamında değişiklik takibini zorlaştırır. Policy latest tag'i doğrudan reddedebilir. Sürüm tag'i kullanılsa bile digest ile sabitlemek daha güvenlidir. Developer ortamında farklı kurallar uygulanabilir.

Policy Failure Durumunda Deployment'ı Durdurmak

Security policy başarısız olduğunda production deployment devam etmemelidir. Exception gerekiyorsa kayıtlı ve süreli onay süreci kullanılmalıdır. Sessizce bypass edilen policy zamanla etkisiz hale gelir. Failure nedeni developer'a açık biçimde gösterilmelidir. Kritik edge servislerinde rollback veya mevcut sürümde kalma davranışı tanımlanmalıdır.

Kubernetes Edge Ortamında DevSecOps

Kubernetes edge workload'larının declarative biçimde yönetilmesini kolaylaştırır ancak her edge projesinde aynı dağıtım uygun değildir. K3s, KubeEdge, MicroK8s ve standart Kubernetes farklı operasyon özellikleri sunar. Kaynak kullanımı, offline çalışma, güvenlik, fleet management ve upgrade modeli birlikte değerlendirilmelidir. Edge cihazlarda container Kubernetes ve DevSecOps pipeline güvenliği düşünülürken orkestrasyon katmanının cihaz kapasitesine uygun seçilmesi gerekir. Küçük bir gateway ile çok node'lu güçlü edge cluster aynı tasarım kararlarına sahip olmamalıdır.

K3s

K3s daha hafif Kubernetes dağıtımı olarak edge ve küçük cluster senaryolarında kullanılabilir. Kurulum ve kaynak tüketimi standart dağıtıma göre daha kolay yönetilebilir. Kubernetes API uyumluluğu birçok mevcut aracı kullanmayı mümkün kılar. Güvenlik ayarları yine açık biçimde yapılandırılmalıdır. Upgrade ve offline package dağıtım modeli üretim öncesinde test edilmelidir.

KubeEdge

KubeEdge cloud ve edge tarafını ayrı bileşenlerle yönetmeye odaklanır. Kesintili bağlantı senaryolarına yönelik özellikler sunabilir. Cihaz yönetimi ve edge workload modeli klasik cluster yaklaşımından farklı olabilir. Control plane bağlantı kaybı test edilmelidir. Seçim yapılırken ekip deneyimi ve bakım modeli dikkate alınmalıdır.

MicroK8s

MicroK8s küçük ve orta ölçekli Kubernetes kullanım senaryolarında pratik kurulum sağlayabilir. Add-on modeli bazı bileşenlerin hızlı etkinleştirilmesini kolaylaştırır. Edge donanımında gerçek kaynak tüketimi ölçülmelidir. Production güvenliği için varsayılan ayarlara güvenilmemelidir. Upgrade yöntemi disconnected lokasyonlarda ayrıca planlanmalıdır.

Standart Kubernetes

Standart Kubernetes geniş ekosistem ve esneklik sağlar. Daha güçlü edge server veya cluster'larda uygun olabilir. Control plane ve node bileşenlerinin operasyon maliyeti daha yüksektir. Security hardening daha ayrıntılı yönetim gerektirir. Ekip zaten Kubernetes deneyimine sahipse bu operasyon avantaj yaratabilir.

Edge Distribution Seçim Kriterleri

Dağıtım seçimi yalnızca kurulum kolaylığına göre yapılmamalıdır. Kaynak kullanımı, offline çalışma ve güvenlik özellikleri önemlidir. Fleet yönetimi ve upgrade mekanizması uzun vadeli operasyon maliyetini etkiler. Mevcut CI/CD ve observability araçlarıyla uyumluluk değerlendirilmelidir. En doğru seçim temsilî donanım üzerinde yapılan pilot testle belirlenir.

Kaynak Kullanımı

Control agent, kubelet ve ek güvenlik servisleri CPU ve RAM tüketir. Düşük donanımlı cihazlarda bu yük uygulama kapasitesini azaltabilir. Idle ve yoğun kullanım ölçülmelidir. Memory pressure senaryosu test edilmelidir. Seçilen platform cihazın uzun dönem kapasitesine uygun olmalıdır.

Offline Çalışma

Edge platform cloud bağlantısı kesildiğinde temel workload'ları çalıştırmaya devam etmelidir. Control plane kaybının pod davranışına etkisi test edilmelidir. Yerel image ve configuration cache önemlidir. Certificate expiry gibi uzun kesinti senaryoları unutulmamalıdır. Reconnect sonrasında reconciliation güvenli biçimde yapılmalıdır.

Security

Dağıtımın RBAC, NetworkPolicy ve admission desteği incelenmelidir. Güvenlik güncellemelerinin release hızı önemlidir. Varsayılan açık servisler kontrol edilmelidir. Supported version yaşam döngüsü takip edilmelidir. Hardening rehberi kurumsal baseline ile eşleştirilmelidir.

Fleet Management

Yüzlerce cluster tek tek yönetilemez. Merkezi policy ve versiyon görünürlüğü gerekir. Cihaz grupları deployment ring olarak tanımlanabilir. Konfigürasyon drift merkezi olarak raporlanmalıdır. Fleet sisteminin kendi yetkileri de minimum privilege ile sınırlandırılmalıdır.

Upgrade Yönetimi

Kubernetes ve edge dağıtım sürümleri düzenli olarak güncellenmelidir. Upgrade öncesi compatibility testi yapılmalıdır. Canary cluster grubu kullanılmalıdır. Başarısız upgrade için rollback veya recovery yöntemi bulunmalıdır. Offline lokasyonlarda paketlerin güvenli taşınması planlanmalıdır.

Kubernetes Control Plane ve Edge Node Güvenliği

Kubernetes güvenliği yalnızca pod ayarlarından oluşmaz. API server, RBAC, service account, etcd ve node authentication birlikte korunmalıdır. Edge node'ların fiziksel olarak kontrolsüz bölgelerde bulunması node credential güvenliğini daha önemli hale getirir. Control plane erişimi mümkün olduğunca özel yönetim ağıyla sınırlandırılmalıdır. Audit log bütün yönetim faaliyetlerinin izlenebilirliğini sağlar.

API Server Güvenliği

API Server cluster'ın merkezi yönetim kapısıdır. Public internet erişimi mümkün olduğunca sınırlandırılmalıdır. Güçlü authentication ve authorization uygulanmalıdır. Gereksiz anonymous erişim kapatılmalıdır. Audit log kritik API işlemlerini kaydetmelidir.

RBAC

RBAC kullanıcı ve service account yetkilerini role göre sınırlar. Cluster-admin rolü rutin operasyon için kullanılmamalıdır. Namespace bazlı roller tercih edilebilir. Kullanılmayan binding'ler temizlenmelidir. Yetki değişiklikleri review sürecine dahil edilmelidir.

Service Account

Her workload aynı service account'u paylaşmamalıdır. Minimum yetkiye sahip ayrı hesaplar oluşturulabilir. Token'ın otomatik mount edilmesi gerekmiyorsa kapatılmalıdır. Kısa ömürlü token tercih edilmelidir. Service account erişimleri audit edilmelidir.

etcd Encryption

etcd cluster state içinde hassas bilgiler barındırabilir. Encryption at rest secret verisinin doğrudan diskten okunmasını zorlaştırır. Encryption key güvenli biçimde yönetilmelidir. Backup'lar da aynı korumaya sahip olmalıdır. Key rotation prosedürü test edilmelidir.

Node Authentication

Node cluster'a bağlanırken doğrulanabilir kimlik kullanmalıdır. Certificate tabanlı authentication yaygın yaklaşımdır. Ele geçirilmiş node certificate'i iptal edilebilmelidir. Bootstrap credential kalıcı kullanılmamalıdır. Node identity asset inventory ile eşleştirilmelidir.

Node Authorization

Node yalnızca kendi workload ve gerekli kaynaklara erişebilmelidir. Geniş API yetkileri risk yaratır. Kubernetes node authorization mekanizmaları doğru yapılandırılmalıdır. Ele geçirilen node'un diğer node secret'larına erişmesi engellenmelidir. Yetki modeli testlerle doğrulanmalıdır.

Control Plane'e Network Erişimi

Control plane API erişimi güvenilir network yollarıyla sınırlandırılmalıdır. Edge node'ların sadece gerekli portlara erişmesi yeterlidir. Yönetici erişimi ayrı VPN veya bastion üzerinden yapılabilir. Firewall kuralları code olarak yönetilebilir. Beklenmeyen bağlantı denemeleri loglanmalıdır.

Kubernetes Audit Log

Audit log Kubernetes API üzerinde kimin ne yaptığını gösterir. Deployment, secret ve RBAC değişiklikleri kaydedilebilir. Log hacmi edge ve merkezi sistem kapasitesine göre filtrelenmelidir. Kritik olaylar yüksek öncelikle saklanmalıdır. Incident response sırasında audit kayıtları önemli kanıt sağlar.

Kubernetes Pod Security

Pod security workload'ın node üzerinde sahip olduğu yetkileri sınırlar. Root kullanıcı, privileged mode, hostPath ve geniş Linux capabilities container escape riskini artırabilir. Production workload'ları güvenli varsayılanlarla çalıştırmak gerekir. Policy-as-code bu kuralları bütün cluster'larda aynı şekilde uygulamayı kolaylaştırır. Güvenlik ayarlarının uygulama ihtiyacını bozmadığı staging ortamında doğrulanmalıdır.

Non-Root Container

Container'ın root kullanıcıyla çalışması gerekli değilse engellenmelidir. Non-root çalışma privilege escalation etkisini azaltabilir. Image içindeki dosya izinleri buna göre hazırlanmalıdır. Runtime user explicit olarak tanımlanabilir. CI pipeline manifest kontrolü yapmalıdır.

Read-Only Root Filesystem

Read-only root filesystem container içinde kalıcı dosya değişikliğini sınırlar. Uygulama yazma ihtiyacı için ayrı volume kullanılabilir. Zararlı dosya bırakma girişimini zorlaştırır. Uygulamanın geçici dosya kullanım modeli test edilmelidir. Policy uygun workload'larda bu ayarı zorunlu tutabilir.

Linux Capabilities

Linux capabilities root yetkilerini daha küçük parçalara böler. Container'lara varsayılan olarak gereksiz capability verilmemelidir. Önce tümü drop edilip gerekli olanlar eklenebilir. NET_ADMIN gibi güçlü capability dikkatle değerlendirilmelidir. Runtime policy capability kullanımını izleyebilir.

Privileged Container'ları Engellemek

Privileged container host üzerinde çok geniş kontrol sağlar. Production edge workload'larında varsayılan olarak yasaklanmalıdır. Gerçekten ihtiyaç varsa ayrı node ve özel policy kullanılabilir. Exception süreli ve kayıtlı olmalıdır. Admission control bu kuralı otomatik uygulayabilir.

HostPath Kullanımını Sınırlamak

HostPath container'ın node filesystem alanlarına erişmesini sağlar. Yanlış kullanım host verisinin açığa çıkmasına yol açabilir. Gerekli path'ler allowlist ile sınırlandırılabilir. Mümkünse alternatif volume türü tercih edilmelidir. Read-only mount ek koruma sağlayabilir.

Seccomp

Seccomp container'ın kullanabileceği system call'ları sınırlar. Varsayılan runtime profili çoğu workload için iyi başlangıçtır. Özel yüksek riskli servislerde daha dar profil hazırlanabilir. Policy seccomp olmadan deployment'ı engelleyebilir. Uygulama uyumluluğu test edilmelidir.

AppArmor / SELinux

AppArmor ve SELinux process erişimlerini ek güvenlik politikalarıyla sınırlar. Container escape veya yanlış dosya erişimi etkisini azaltabilir. Host işletim sistemi desteği doğrulanmalıdır. Profiller CI ortamında test edilmelidir. Edge filosunda standart profile geçiş kademeli yapılmalıdır.

Policy as Code

Policy as Code güvenlik ve uyumluluk kurallarını kod gibi version control altında yönetmeyi sağlar. Edge filolarında yüzlerce cluster'a manuel policy uygulamak yerine merkezi tanım kullanılabilir. Kyverno ve OPA Gatekeeper Kubernetes ortamlarında yaygın seçeneklerdir. Policy hem CI aşamasında test edilebilir hem runtime admission sırasında uygulanabilir. Merkezi policy ile yerel enforcement modeli bağlantı kesintilerinde bile güvenlik kontrolünün devam etmesini sağlar.

Policy as Code Nedir?

Policy as Code insan tarafından yazılan güvenlik kurallarını makine tarafından uygulanabilir hale getirir. Kural değişiklikleri commit geçmişinde izlenir. Pull request ve review uygulanabilir. Otomatik testler policy'nin beklenen davranışını doğrular. Kurum standardı böylece teknik kontrole dönüşür.

Kyverno

Kyverno Kubernetes kaynakları üzerinde policy tanımlamaya odaklanır. Validation, mutation ve bazı generation senaryolarını destekler. Kubernetes yapısına yakın policy tanımı ekiplerin öğrenmesini kolaylaştırabilir. CI ve admission aşamalarında kullanılabilir. Edge cluster kaynak tüketimi gerçek ortamda ölçülmelidir.

OPA Gatekeeper

OPA Gatekeeper Kubernetes admission policy için OPA tabanlı yaklaşım sunar. Constraint ve template modeliyle kurallar oluşturulabilir. Kurum genelinde ortak policy library kurulabilir. Audit modu mevcut ihlalleri görünür hale getirir. Enforcement öncesi audit kullanmak geçişi kolaylaştırır.

Deployment Öncesi Policy Testi

Manifest production'a ulaşmadan policy testinden geçmelidir. Böylece developer hatayı erken görür. Aynı policy staging ve production'da tutarlı davranmalıdır. Unit test örnekleri policy repository'sinde tutulabilir. CI failure mesajı düzeltme için açık bilgi vermelidir.

Runtime Policy Enforcement

CI kontrolü bypass edilebileceği için runtime admission katmanı da policy uygulamalıdır. Manuel kubectl değişiklikleri böylece kontrol dışına çıkamaz. İmzasız image veya privileged pod reddedilebilir. Audit log başarısız denemeleri kaydeder. Kritik exception kontrollü onay süreci gerektirir.

Merkezi Policy, Yerel Enforcement Modeli

Policy merkezi repository'de yönetilebilir. Edge cluster policy kopyasını yerel olarak uygular. Cloud bağlantısı kesilse bile enforcement devam eder. Bağlantı geri geldiğinde policy güncellemeleri senkronize edilir. Version bilgisi fleet dashboard üzerinde görünür tutulmalıdır.

GitOps ile Edge Deployment

GitOps edge filolarının desired state'ini Git repository üzerinden yönetmeyi sağlar. Pull-based deployment modeli özellikle dışarıdan inbound erişim verilmesinin istenmediği edge ağlarında avantajlıdır. Argo CD veya Flux gibi araçlar cluster'ın Git'teki tanıma yaklaşmasını sağlayabilir. Değişiklikler review ve audit geçmişiyle izlenebilir hale gelir. Ancak Git repository kritik bir control plane bileşeni olduğundan güçlü biçimde korunmalıdır.

GitOps Nedir?

GitOps sistem konfigürasyonunun declarative dosyalarla Git içinde tutulmasını temel alır. Production state değişiklikleri commit üzerinden yapılır. Agent mevcut state ile desired state arasındaki farkı izler. Drift oluştuğunda düzeltme yapılabilir. Git geçmişi değişiklik kaydı sağlar.

Desired State

Desired state sistemin nasıl olması gerektiğini tanımlar. Image digest, replica sayısı ve policy gibi ayarlar burada tutulabilir. Runtime gerçek durum bununla karşılaştırılır. Manuel değişiklikler görünür hale gelir. Güvenlik standardı da desired state'in parçası olabilir.

Pull-Based Deployment

Pull-based modelde edge agent merkezi Git veya artifact kaynağından değişikliği çeker. Merkezi sistemin edge ağa doğrudan bağlanması gerekmez. NAT veya firewall arkasındaki lokasyonlarda operasyon kolaylaşır. Agent yalnızca gerekli outbound erişime sahip olabilir. Offline durumda mevcut state korunur.

Argo CD

Argo CD Kubernetes için GitOps deployment ve reconciliation sağlar. Application state ile Git manifest'i karşılaştırabilir. Drift görünürlüğü sunar. Edge bağlantı ve kaynak profili üzerinde davranışı test edilmelidir. Merkezi veya dağıtık deployment modeli ihtiyaca göre seçilebilir.

Flux

Flux Git repository ve Kubernetes arasında declarative senkronizasyon sağlar. Image automation ve source yönetimi gibi bileşenleri bulunabilir. Küçük footprint ihtiyacı edge senaryosunda değerlendirilebilir. Security policy ile birlikte kullanılmalıdır. Git credential ve deploy key yönetimi dikkatle yapılmalıdır.

Edge Fleet'lerinde GitOps'un Avantajları

GitOps çok sayıda cluster'ın aynı yöntemle yönetilmesini sağlar. Manuel SSH ihtiyacını azaltır. Değişiklikler review alır ve geri alınabilir. Configuration drift daha kolay tespit edilir. Filo grupları farklı branch veya overlay yapılarıyla yönetilebilir.

Git Repository'nin Güvenliği

Git repository production state'i belirlediği için kritik güvenlik varlığıdır. MFA ve branch protection uygulanmalıdır. Direct push engellenmelidir. CODEOWNERS kritik dosyalar için ek review sağlar. Repository credential'ları kısa ömürlü veya dar kapsamlı tutulmalıdır.

GitOps Repository Ele Geçirilirse Ne Olur?

GitOps repository ele geçirilirse saldırgan production desired state'i değiştirmeye çalışabilir. Bu nedenle repository güvenliği tek başına yeterli görülmemelidir. Artifact signature verification, admission policy ve blast radius sınırları ikinci savunma katmanını oluşturur. Zararlı manifest imzalı olmayan image'a işaret ediyorsa cluster bu deployment'ı reddetmelidir. Güvenlik tasarımında hiçbir tek kontrolün mutlak güven noktası haline gelmemesi önemlidir.

Repository Branch Protection

Branch protection production branch'e doğrudan değişiklik yapılmasını engeller. Pull request ve approval zorunlu tutulabilir. Force push kapatılmalıdır. Status check başarısızsa merge engellenebilir. Yönetici bypass yetkileri sınırlı olmalıdır.

MFA

MFA çalınmış parolanın tek başına hesap ele geçirilmesine dönüşmesini zorlaştırır. Repository yöneticileri için zorunlu olmalıdır. Hardware-backed güvenlik anahtarları yüksek güvenlik isteyen ekiplerde tercih edilebilir. Recovery yöntemi güvenli tutulmalıdır. MFA bypass olayları audit edilmelidir.

CODEOWNERS

CODEOWNERS belirli dosyalar için zorunlu reviewer tanımlamaya yardımcı olur. Production manifest ve security policy platform ekibi review'una bağlanabilir. Tek kişinin kritik değişiklik yapması engellenebilir. Ownership listesi güncel tutulmalıdır. Ayrılan çalışanların erişimi hızla kaldırılmalıdır.

İki Kişilik Review

İki kişilik review kritik production değişikliklerinde insan kontrolünü güçlendirir. Özellikle policy ve pipeline dosyalarında değerlidir. Reviewer'ların gerçekten değişikliği anlaması gerekir. Otomatik bot approval yerine anlamlı inceleme yapılmalıdır. Acil durum bypass süreci ayrıca kayıt altına alınmalıdır.

Signed Commit

Signed commit değişikliğin belirli kimlik tarafından imzalandığını doğrulamaya yardımcı olur. Tek başına authorization değildir. Branch protection ile birlikte kullanılmalıdır. Signature verification otomatik kontrol haline getirilebilir. Signing identity yaşam döngüsü yönetilmelidir.

Policy Validation

Zararlı veya hatalı manifest repository'ye girse bile policy validation ikinci kontrol sağlar. CI merge öncesinde kural ihlalini tespit eder. Admission katmanı runtime öncesi tekrar doğrular. Böylece repository ele geçirilmesi doğrudan cluster kontrolüne dönüşmez. Policy de ayrı güven alanında korunmalıdır.

Artifact Signature Verification

Git manifest saldırgan tarafından değiştirilerek farklı image'a yönlendirilebilir. Signature verification yalnızca onaylı artifact'ın çalışmasına izin verir. Unknown signer tarafından imzalanan image reddedilir. Digest kullanımı tag manipulation riskini azaltır. Trust policy merkezi yönetilebilir.

Blast Radius Sınırlandırması

Tek repository veya credential bütün filoya sınırsız erişim vermemelidir. Production grupları ayrı environment veya repository'lerle bölünebilir. Deployment ring'leri farklı approval seviyeleri kullanabilir. Credential sadece ilgili edge grubuna yetki vermelidir. Böylece compromise etkisi bütün filoya yayılmaz.

Configuration Drift Yönetimi

Configuration drift production sisteminin tanımlanan desired state'ten zaman içinde uzaklaşmasıdır. Manuel SSH değişiklikleri, acil müdahaleler ve yerel konfigürasyon düzenlemeleri bu duruma yol açabilir. GitOps automatic reconciliation ile drift'i tespit edip geri çevirebilir. Security ve compliance drift ayrı metrikler olarak izlenmelidir. Tekrarlayan drift olayları proses veya otomasyon eksikliğinin işareti olabilir.

Desired State ve Actual State

Desired state Git veya configuration repository içinde tanımlanan hedef durumdur. Actual state cihazda gerçekten çalışan konfigürasyondur. Bu iki durum sürekli karşılaştırılabilir. Fark varsa drift olayı oluşur. Kritik güvenlik farkları yüksek öncelikli alarm üretebilir.

Manuel Değişikliklerin Tespit Edilmesi

Manuel değişiklikler emergency operasyon sırasında yapılabilir. Ancak kalıcı hale gelmeden merkezi state'e işlenmelidir. Agent filesystem veya Kubernetes state farkını tespit edebilir. Audit log değişikliği yapan kimliği gösterebilir. Kontrolsüz SSH erişimi minimuma indirilmelidir.

Automatic Reconciliation

Automatic reconciliation actual state'i desired state'e geri getirir. Bu özellik yanlışlıkla yapılan değişiklikleri hızlı düzeltir. Kritik üretim sistemlerinde otomatik düzeltmenin yan etkileri test edilmelidir. Bazı drift türlerinde önce alarm tercih edilebilir. Reconciliation sonucu loglanmalıdır.

Security Drift

Security drift firewall, RBAC veya pod güvenlik ayarlarının hedef politikadan sapmasıdır. Küçük bir değişiklik önemli risk yaratabilir. Policy agent bu farkı tespit edebilir. Kritik drift otomatik düzeltilebilir. Tekrarlanan drift kök neden analizi gerektirir.

Compliance Drift

Compliance drift teknik konfigürasyonun belirlenmiş uyumluluk standardından sapmasıdır. Encryption ayarının kapanması buna örnek olabilir. Evidence toplama otomatikleştirilebilir. Drift olayı compliance dashboard'a aktarılabilir. Düzeltme süresi kurum politikasına göre ölçülebilir.

Drift Alerting

Her drift aynı öneme sahip değildir. Kritik security control değişikliği anlık alarm gerektirebilir. Düşük riskli configuration farkı toplu raporlanabilir. Alert severity gerçek iş etkisine göre belirlenmelidir. Gürültülü alarm sistemi operasyon ekibinin önemli olayları kaçırmasına yol açabilir.

Disconnected ve Air-Gapped Edge DevSecOps

İnternete sürekli bağlanamayan edge ortamları DevSecOps tasarımında özel yaklaşım gerektirir. Artifact, vulnerability database, package ve Helm chart gibi bağımlılıklar önceden kontrollü biçimde taşınmalıdır. Yerel registry ve package repository operasyon sürekliliği sağlar. Air-gap bundle içindeki her dosyanın bütünlüğü ve imzası doğrulanmalıdır. İnternet erişimi olmayan sistemlerde güvenlik güncellemesinin imkansız olduğu düşünülmemeli, yalnızca farklı bir dağıtım kanalı tasarlanmalıdır.

İnternetsiz Edge Ortamlarının Problemleri

Disconnected ortam package repository ve registry erişimini kaybedebilir. Vulnerability feed güncelliği gecikebilir. Certificate yenileme zorlaşabilir. Merkezi logging anlık çalışmayabilir. Bu nedenle lokal cache ve kontrollü senkronizasyon gerekir.

Artifact'ları Önceden Paketlemek

Gerekli container image, manifest ve dependency önceden paketlenebilir. Paket belirli release ile ilişkilendirilmelidir. İçerik listesi ve digest kayıt altına alınmalıdır. Transfer sırasında signature doğrulanmalıdır. Gereksiz artifact paket boyutunu artırmamak için çıkarılmalıdır.

Yerel Container Registry

Local registry edge ortamının internete bağlı olmadan image çekmesini sağlar. Registry'nin kendisi güçlü authentication ile korunmalıdır. İzin verilen artifact'lar merkezi onay sonrası mirror edilebilir. Digest ve signature korunmalıdır. Registry backup ve disk kapasitesi izlenmelidir.

Yerel Package Repository

OS ve uygulama paketleri için lokal repository kurulabilir. Yalnızca onaylı sürümler içeri alınmalıdır. Metadata signature doğrulanmalıdır. Repository güncellemesi kontrollü staging sürecinden geçmelidir. Eski paketlerin tutulma politikası disk kapasitesine göre belirlenmelidir.

Offline Helm Chart Yönetimi

Helm chart ve dependency'leri internet gerektirmeyecek biçimde paketlenebilir. Chart sürümü sabitlenmelidir. Referans verilen image'ların da local registry'de bulunması gerekir. Chart signature veya provenance doğrulanabilir. Deployment öncesi template ve policy testleri yapılmalıdır.

Staging Zone

Staging zone internet bağlantılı dünya ile air-gap ortam arasında kontrollü geçiş alanıdır. Paketler burada scan ve signature kontrolünden geçer. Fiziksel medya kullanılıyorsa süreç kayıt altına alınır. Onay sonrası veri iç ortama aktarılır. Geri yönde veri çıkışı daha sıkı kurallara tabi olabilir.

Air-Gap Bundle

Air-gap bundle belirli release için gereken bütün artifact'ları tek paket altında toplayabilir. Manifest, image, SBOM ve signature birlikte taşınabilir. Bundle inventory oluşturulmalıdır. Hash doğrulaması transferin her aşamasında yapılabilir. Paket sürümü değiştirilemez şekilde kayıt altına alınmalıdır.

Paket Bütünlüğünü Doğrulamak

Offline transfer fiziksel medyaya güvenmek anlamına gelmemelidir. Artifact digest ve digital signature doğrulanmalıdır. Verification key iç ortamda güvenli biçimde saklanmalıdır. Hatalı veya imzasız paket reddedilmelidir. Doğrulama sonucu audit kaydına eklenebilir.

Offline Ortamda Vulnerability Management

Air-gapped sistemlerde vulnerability management internet erişimli ortamlardan farklı veri akışına sahiptir. CVE feed ve scanner database kontrollü paketler halinde iç ortama taşınmalıdır. Scanner yerel olarak çalışmalı ve SBOM verileriyle ilişkilendirilmelidir. Feed güncelliği ölçülebilir bir güvenlik metriği olarak takip edilmelidir. Kritik vulnerability çıktığında normal transfer döngüsünü beklemeyen acil güncelleme süreci bulunmalıdır.

Vulnerability Database Mirror

Scanner database internet bağlantılı staging ortamında güncellenebilir. Doğrulanan paket offline alana taşınır. Database sürümü ve tarihi kaydedilmelidir. Eski feed kullanımı görünür risk olarak raporlanmalıdır. Transfer otomasyonu güvenli süreçle yapılabilir.

Offline Scanner

Offline scanner internet bağlantısı olmadan local database ile tarama yapar. Container image ve filesystem analiz edilebilir. Sonuçlar merkezi olmayan rapor sisteminde tutulabilir. Database güncelliği scan doğruluğunu etkiler. Scanner binary ve rule set'in kendisi de imzalı paket olarak yönetilmelidir.

Güncelleme Paketlerinin Kontrollü Aktarılması

Security update paketleri staging zone üzerinden geçirilmelidir. Malware ve integrity kontrolü yapılabilir. Onaylı kişi veya süreç transferi kayıt altına alır. Package dependency'lerinin tamamı birlikte taşınmalıdır. İç ortamda yeniden doğrulama yapılmalıdır.

CVE Feed Güncelliği

CVE feed ne kadar eskiyse yeni açıkların gözden kaçma olasılığı o kadar artar. Feed yaşı metric olarak izlenebilir. Kritik ortamlarda maksimum kabul edilebilir gecikme belirlenmelidir. Güncelleme başarısızlığı alarm üretmelidir. Filo risk raporu feed tarihini açık biçimde göstermelidir.

Kritik Vulnerability İçin Acil Güncelleme Süreci

Aktif olarak sömürülen kritik açık normal patch takvimini beklememelidir. Acil paket staging sürecinden hızlandırılmış kontrolle geçirilir. Temsilî cihazda hızlı doğrulama yapılır. Canary rollout uygulanır. Başarısızlık durumunda rollback hazır olmalıdır.

Secrets Management Edge Ortamında Nasıl Yapılır?

Edge sistemlerde secret yönetiminin temel hedefi credential'ları source code, Git repository ve container image dışında tutmaktır. Merkezi secret manager kullanılabiliyorsa workload kısa ömürlü credential alabilir. Ancak bağlantı kesintisi nedeniyle güvenli local cache ve expiration davranışı ayrıca tasarlanmalıdır. Cihaz ele geçirildiğinde ilgili secret veya certificate hızlı biçimde iptal edilmelidir. Kurumsal Edge Computing DevSecOps altyapısı ve güvenlik hizmeti tasarlanırken secrets management genellikle kimlik, Zero Trust ve incident response süreçleriyle birlikte ele alınmalıdır.

Secret'ları Git'e Koymamak

Git geçmişine giren secret dosyadan silinse bile commit geçmişinde kalabilir. Bu nedenle secret hiçbir aşamada plain text repository'ye eklenmemelidir. Secret scanning erken uyarı sağlayabilir. Yanlışlıkla eklenen gerçek credential derhal rotate edilmelidir. Encrypted secret dosyaları bile key yönetimi açısından dikkatle değerlendirilmelidir.

Merkezi Secret Manager

Central secret manager credential issuance ve rotation süreçlerini tek noktada yönetebilir. Workload ihtiyacı olduğunda secret alır. Access policy identity üzerinden uygulanabilir. Audit log kimin hangi secret'a eriştiğini gösterir. Edge bağlantı kaybı senaryosunda fallback davranışı planlanmalıdır.

Vault

Vault dinamik secret ve short-lived credential yönetimi için kullanılabilir. Workload identity ile entegre edilebilir. Policy bazlı erişim sağlar. Edge node için local agent veya cache modeli değerlendirilebilir. Yüksek availability ve recovery tasarımı merkezi bileşen için önemlidir.

Short-Lived Secret

Kısa ömürlü secret sızıntının etkisini zaman açısından sınırlar. Workload başlatıldığında üretilebilir. Süre dolduğunda otomatik yenilenir. Offline çalışma süresiyle credential TTL arasında denge kurulmalıdır. Çok kısa TTL bağlantı kesintisinde servis kesintisine yol açabilir.

Edge Node'da Secret Cache

Bağlantı kesintilerinde bazı credential'ların local cache'de tutulması gerekebilir. Cache şifrelenmiş olmalıdır. Erişim yalnızca ilgili workload ile sınırlandırılmalıdır. TTL ve maksimum offline kullanım süresi tanımlanmalıdır. Cihaz ele geçirilirse cache içeriğinin kullanım riski tehdit modeline dahil edilmelidir.

Offline Çalışırken Credential Yönetimi

Offline sistem credential yenilemek için merkezi servise ulaşamayabilir. Önceden alınmış kısa süreli credential çalışma süresini karşılamalıdır. Çok uzun credential ise güvenlik riskini büyütür. Risk seviyesine göre kontrollü grace period uygulanabilir. Reconnect olduğunda identity ve revocation durumu yeniden doğrulanmalıdır.

Secret Rotation

Rotation secret yaşam döngüsünün rutin parçası olmalıdır. Manuel operasyon yerine otomatik süreç tercih edilir. Yeni secret dağıtıldıktan sonra eski secret kontrollü biçimde kapatılır. Uygulamanın kesintisiz geçiş desteklemesi önemlidir. Rotation failure monitoring sisteminde görünmelidir.

Cihaz Ele Geçirildiğinde Secret Revocation

Compromise edilen cihazın credential kullanımı hızla kesilmelidir. Cihaz certificate'i revoke edilebilir. Workload secret'ları ayrı kimliklere bağlıysa yalnızca ilgili kapsam rotate edilir. Merkezi policy cihazı quarantine grubuna alabilir. Yeniden güvenilir hale gelmeden production erişimi verilmemelidir.

Secure OTA Update

OTA update edge cihazların fiziksel müdahale olmadan güncellenmesini sağlar. Güvenli bir OTA sistemi yalnızca dosya indiren mekanizma değildir. Firmware signature, metadata signature, integrity verification, health check ve post-update doğrulaması birlikte çalışmalıdır. Güncelleme paketi güvenilir kaynaktan gelmeli ve cihaz üzerinde çalıştırılmadan önce doğrulanmalıdır. Binlerce uzak cihaz için güvenli OTA, operasyonel sürdürülebilirliğin temel koşullarından biridir.

OTA Güncelleme Nedir?

OTA update cihaz yazılımının network üzerinden uzaktan güncellenmesidir. Firmware, işletim sistemi veya uygulama paketi kapsanabilir. Cihazın saha ziyareti olmadan güncellenmesini sağlar. Güvenlik açığı düzeltmelerinin hızını artırır. Güvenilir rollback mekanizması olmadan riskli hale gelebilir.

Firmware Signing

Firmware signing update paketinin yetkili kaynaktan geldiğini doğrular. Signing private key güçlü biçimde korunmalıdır. Cihaz public key ile imza kontrolü yapar. Verification başarısızsa paket uygulanmaz. Key rotation senaryosu cihaz yaşam döngüsüne göre planlanmalıdır.

Update Metadata Signing

Yalnızca firmware dosyasının imzalanması bazı saldırılara karşı yeterli olmayabilir. Sürüm, hedef cihaz ve digest içeren metadata da imzalanabilir. Böylece saldırgan cihazı yanlış veya eski pakete yönlendiremez. Metadata expiry bilgisi içerebilir. Cihaz tüm doğrulamaları update öncesinde yapmalıdır.

Update Paketinin Bütünlüğünü Doğrulamak

Download sırasında paket bozulabilir veya değiştirilebilir. Hash ve signature kontrolü bütünlüğü doğrular. Verification tamamlanmadan install başlamamalıdır. Local cache içindeki paket de tekrar kontrol edilebilir. Hatalı paket otomatik olarak silinmelidir.

Update Öncesi Device Health Check

Güncelleme başlamadan cihazın yeterli disk ve güç durumuna sahip olması kontrol edilmelidir. Kritik workload durumu değerlendirilebilir. Network bağlantısının minimum kalite şartı aranabilir. Cihaz zaten güvenlik olayı içindeyse update yerine quarantine tercih edilebilir. Health check başarısızsa rollout ertelenmelidir.

Update Sonrası Verification

Update tamamlandıktan sonra yalnızca reboot başarılı oldu diye işlem bitmiş sayılmamalıdır. Service health, version ve security policy kontrol edilmelidir. Attestation yeni boot durumunu doğrulayabilir. Kritik metric'ler belirli süre gözlemlenebilir. Hata varsa otomatik rollback uygulanabilir.

OTA Güncellemelerinde Rollback Güvenliği

Rollback başarısız güncellemeden kurtulmak için şarttır ancak eski ve güvensiz sürüme dönmek ayrı risk oluşturur. A/B partition ve atomic update cihazın boot edilebilir durumda kalmasına yardımcı olur. Automatic rollback sağlık kontrollerine bağlanabilir. Anti-rollback protection bilinen vulnerable firmware sürümüne geri dönüşü engeller. Recovery partition ise ana image tamamen bozulduğunda kontrollü kurtarma yolu sunar.

Update Başarısız Olursa Ne Olur?

Başarısız update cihazı erişilemez hale getirebilir. Tasarım bu durumu normal hata senaryosu olarak görmelidir. Cihaz önceki çalışan sürüme dönebilmelidir. Boot counter veya health check rollback tetikleyebilir. Olay merkezi sisteme raporlanmalıdır.

A/B Partition

A/B partition iki ayrı sistem slotu kullanır. Yeni sürüm aktif olmayan bölüme yazılır. Doğrulama başarılı olduğunda boot hedefi değiştirilir. Yeni sürüm çalışmazsa eski bölüme geri dönülür. Disk kapasitesi maliyeti cihaz tasarımında hesaba katılmalıdır.

Atomic Update

Atomic update değişikliğin ya tamamen uygulanmasını ya da hiç uygulanmamasını hedefler. Yarım kalan dosya güncellemeleri azaltılır. Power loss senaryosunda cihazın tutarlı state'te kalmasına yardım eder. Filesystem ve update mekanizması bunu desteklemelidir. Testlerde update sırasında güç kesintisi mutlaka denenmelidir.

Automatic Rollback

Automatic rollback health check başarısızsa önceki sürüme döner. Servis startup, API health ve kritik metric sinyal olarak kullanılabilir. Sonsuz rollback döngüsü engellenmelidir. Başarısız sürüm quarantine listesine alınabilir. Merkezi sistem deployment ring'i otomatik durdurabilir.

Anti-Rollback Protection

Anti-rollback eski ve bilinen vulnerable sürüme dönülmesini engeller. Minimum kabul edilen firmware version cihaz veya policy üzerinde tutulabilir. Version metadata imzalı olmalıdır. Emergency recovery için kontrollü exception mekanizması gerekebilir. Bu mekanizma saldırganın eski açıkları yeniden etkinleştirmesini zorlaştırır.

Eski ve Vulnerable Firmware'e Dönüşü Engellemek

Rollback her zaman son çalışan sürüme değil güvenli kabul edilen sürüme yapılmalıdır. Known vulnerable version deny list'te tutulabilir. Firmware metadata minimum güvenli sürümü belirtebilir. Cihaz install öncesi bu kontrolü yapar. Security ekibi minimum sürüm politikasını filo çapında güncelleyebilir.

Recovery Partition

Recovery partition ana işletim sistemi açılmadığında minimal kurtarma ortamı sağlar. Bu bölüm mümkün olduğunca küçük ve imzalı olmalıdır. Remote re-provisioning başlatabilir. Normal workload credential'larını taşımaması tercih edilir. Recovery image da düzenli olarak güvenlik güncellemesi almalıdır.

Edge Fleet'lerinde Güvenli Deployment Stratejileri

Edge filosuna yapılan değişikliklerin en büyük risklerinden biri aynı hatayı bütün cihazlara aynı anda yaymaktır. Deployment ring, canary ve progressive delivery bu riski azaltır. Yeni sürüm önce küçük ve temsilî cihaz grubuna uygulanır. Health, security ve iş metrikleri normal kaldığında rollout genişletilir. Otomatik rollback ve ring bazlı durdurma mekanizması büyük ölçekli kesintilerin önüne geçebilir.

All-at-Once Deployment Riski

All-at-once deployment hatalı sürümü bütün filoya aynı anda taşır. Uzak lokasyonlarda fiziksel recovery çok maliyetli olabilir. Network veya donanım farkı bazı cihazlarda beklenmeyen problem yaratabilir. Rollout kademeli yapılmalıdır. Kritik güncellemede bile küçük canary aşaması korunmalıdır.

Deployment Ring'leri

Deployment ring cihazları risk ve kullanım amacına göre gruplar. Her grup yeni sürümü farklı zamanda alır. İlk ring düşük etkili test cihazlarından oluşur. Son ring kritik production filosudur. Geçiş koşulları otomatik metric ve onaylarla belirlenebilir.

Development

Development ring geliştirici ve laboratuvar cihazlarını içerir. Yeni build burada hızlı denenebilir. Veri ve workload production kritik olmamalıdır. Debug görünürlüğü daha yüksek olabilir. Başarılı sonuç sonraki ring'e geçiş sağlar.

Internal Test

Internal Test gerçek topolojiye daha yakın kontrollü cihazlardan oluşur. Policy ve update mekanizması burada doğrulanır. ARM ve x86 varyasyonları dahil edilmelidir. Network kesintisi gibi testler yapılabilir. Bu ring production öncesi teknik doğrulama sağlar.

Pilot Devices

Pilot devices gerçek saha koşullarında çalışan sınırlı cihaz grubudur. Kullanıcı etkisi kontrollü tutulur. Deployment sonrası health ve business metric'ler izlenir. Fiziksel lokasyon çeşitliliği seçilebilir. Beklenmeyen sorunlarda rollout burada durdurulur.

Canary Fleet

Canary fleet production cihazlarının küçük bir bölümüdür. Yeni release gerçek workload altında denenir. Error rate, CPU, security alert ve network davranışı takip edilir. Başarı kriteri otomatik tanımlanabilir. Sorun yoksa daha büyük production grubuna geçilir.

Production Fleet

Production fleet en geniş ve iş açısından kritik cihaz grubudur. Yalnızca önceki ring'leri geçen release buraya ulaşmalıdır. Rollout yine bölgesel veya yüzdesel yapılabilir. Otomatik rollback hazır tutulmalıdır. Deployment tamamlanınca coverage raporu oluşturulmalıdır.

Canary Deployment

Canary deployment yeni sürümü küçük cihaz yüzdesine dağıtır. Gerçek production koşulunda risk kontrollü biçimde ölçülür. Monitoring yalnızca teknik değil security metric'leri de içermelidir. Threshold aşılırsa rollout durur. Başarılı canary sonrası kapsam kademeli artırılır.

Blue-Green Deployment

Blue-Green yaklaşımı eski ve yeni sürümü ayrı çalışma alanlarında hazır tutar. Trafik doğrulama sonrasında yeni sürüme yönlendirilir. Hata durumunda eski ortama dönüş hızlıdır. Edge kaynak kapasitesi iki sürümü aynı anda çalıştırmaya yetmeyebilir. Bu nedenle her cihaz tipinde uygun değildir.

Progressive Delivery

Progressive delivery deployment kapsamını aşamalı artırır. Yüzde, lokasyon veya cihaz grubu bazında ilerlenebilir. Her aşamada metric değerlendirmesi yapılır. İnsan onayı ve otomatik threshold birlikte kullanılabilir. Edge filolarında risk yönetimi için güçlü bir modeldir.

Automatic Rollback

Automatic rollback release sonrası belirli başarısızlık sinyallerinde eski sürüme döner. Health check ve security alert birlikte değerlendirilebilir. Rollback artifact'ı da imzalı ve doğrulanmış olmalıdır. Sorunlu release yeniden rollout almamalıdır. Root cause çözülene kadar ring ilerlemesi durdurulur.

Edge-Specific Testing CI/CD'ye Nasıl Eklenir?

Edge uygulamalarını yalnızca güçlü CI sunucularında test etmek gerçek saha davranışını göstermeyebilir. Düşük CPU, düşük memory, disk doluluğu, yüksek latency ve packet loss gibi koşullar pipeline veya hardware test lab içinde simüle edilmelidir. ARM ve x86 build'ler ayrı doğrulanmalıdır. Network partition ve power loss gibi senaryolar özellikle stateful workload'larda kritik sonuçlar verebilir. Edge için kaliteli CI/CD, fonksiyon testinin yanında gerçek cihaz koşullarını da doğrular.

ARM ve x86 Build Testleri

Multi-architecture image her hedef platformda çalıştırılmalıdır. Native dependency farklı davranabilir. Build manifest doğru architecture bilgisini içermelidir. Performance farkları ölçülmelidir. Aynı test suite her mimaride çalıştırılabilir.

Düşük CPU Testi

CPU limiti gerçek cihaz kapasitesine düşürülebilir. Uygulamanın timeout ve queue davranışı gözlemlenir. Security agent'ın etkisi de ölçülmelidir. Deployment sırasında CPU spike oluşup oluşmadığı kontrol edilir. Kabul kriterleri cihaz sınıfına göre belirlenebilir.

Düşük Memory Testi

Memory pressure edge cihazlarda sık görülen problemdir. Container limitleri gerçekçi seviyede test edilmelidir. OOM durumunda servis recovery davranışı izlenir. Log buffer'ın memory tüketimi de hesaba katılmalıdır. Memory leak uzun süreli testlerle bulunabilir.

Disk Doluluk Testi

Disk doluluğu log ve update süreçlerini etkileyebilir. Uygulamanın disk yüzde yüz dolduğunda nasıl davrandığı test edilmelidir. Log rotation devreye girmelidir. OTA update yeterli boş alan yoksa başlamamalıdır. Kritik sistem dosyaları için rezerv alan bırakılabilir.

Düşük Bant Genişliği Testi

Bandwidth sınırı gerçek saha bağlantısını taklit edecek şekilde düşürülebilir. Artifact download süresi ölçülür. Timeout ayarları kontrol edilir. Log senkronizasyonunun workload trafiğini boğmadığı doğrulanır. Büyük image optimizasyon ihtiyacı görünür hale gelir.

High Latency Testi

High latency merkezi API ve edge servis etkileşimini etkiler. Retry ayarları aşırı yük üretmemelidir. mTLS handshake maliyeti ölçülebilir. UI veya kontrol fonksiyonlarının gecikmeye toleransı test edilir. Kritik kararların yerelde kalması gereken noktalar ortaya çıkar.

Packet Loss Testi

Packet loss kararsız bağlantı koşullarını simüle eder. Deployment ve telemetry protokollerinin retry davranışı incelenir. Duplicate işlem oluşmadığı doğrulanmalıdır. Update download resume özelliği test edilebilir. Network error loglarının gereksiz alarm üretmediği kontrol edilmelidir.

Network Partition Testi

Network partition edge ile cloud bağlantısını tamamen keser. Workload'ın yerel olarak çalışmaya devam etmesi beklenir. Secret expiry ve certificate davranışı gözlemlenir. Reconnect olduğunda state reconciliation kontrol edilir. Bu test üretim öncesi mutlaka yapılmalıdır.

Power Loss Testi

Power loss update veya disk yazımı sırasında veri bütünlüğünü bozabilir. Cihaz aniden kapatılarak recovery davranışı test edilmelidir. Atomic update ve journaling fayda sağlar. Boot sonrası filesystem kontrolü yapılabilir. Kritik verinin bozulmadığı doğrulanmalıdır.

Chaos Engineering Edge Ortamında Nasıl Kullanılır?

Chaos engineering edge sistemin beklenmeyen arızalara nasıl tepki verdiğini kontrollü biçimde test eder. Network kesintisi, cloud kaybı, node failure ve certificate expiry gibi olaylar üretim öncesinde simüle edilebilir. Amaç sistemi bozmak değil recovery mekanizmalarının gerçekten çalıştığını doğrulamaktır. Edge projelerinde teorik dayanıklılık ile gerçek davranış arasında fark bulunması oldukça yaygındır. Küçük ve güvenli deneylerle başlanmalı, sonuçlar otomatik test sürecine dönüştürülmelidir.

Network Kesintisi

Ağ tamamen kesilerek workload davranışı gözlemlenir. Local queue kapasitesi ölçülür. Timeout ve retry ayarları kontrol edilir. Bağlantı geri geldiğinde veri senkronizasyonu doğrulanır. Duplicate işlem oluşmamalıdır.

Cloud Bağlantısının Kaybolması

Cloud control plane erişimi kapatılabilir. Edge servislerin temel fonksiyonlarını sürdürmesi beklenir. Merkezi authentication bağımlılığı test edilir. Cached policy'nin çalıştığı doğrulanır. Reconnect sonrası state güvenli biçimde eşitlenmelidir.

Node Failure

Cluster içindeki node kapatılarak workload failover davranışı test edilir. Yeterli kapasite olup olmadığı görülür. Stateful workload verisi korunmalıdır. Alert doğru zamanda üretilmelidir. Recovery sonrası node yeniden güven doğrulamasından geçebilir.

Storage Failure

Disk veya volume erişimi kaybedildiğinde uygulamanın davranışı test edilir. Veri kaybı riski değerlendirilir. Local buffer'ın limitleri görülür. Servis controlled degradation moduna geçebilir. Monitoring storage hatasını hızlı tespit etmelidir.

Certificate Expiry

Certificate süresi kontrollü olarak sona erdirilebilir. Rotation mekanizmasının otomatik çalışması beklenir. Offline cihaz davranışı gözlemlenir. Expiry öncesi alert oluşturulmalıdır. Süresi dolan certificate sessizce kabul edilmemelidir.

Registry Erişim Hatası

Registry bağlantısı kesilerek deployment davranışı test edilir. Mevcut workload çalışmaya devam etmelidir. Cached image yeterli olabilir. Yeni deployment başarısızlığı açık şekilde raporlanmalıdır. Sistem sürekli ve yoğun retry ile ağı boğmamalıdır.

Başarısız OTA Update

Update paketinin ortasında bağlantı veya güç kesilebilir. Cihazın boot edilebilir durumda kalması doğrulanır. Automatic rollback test edilir. Hatalı paket tekrar tekrar kurulmaya çalışılmamalıdır. Olay merkezi sisteme ulaştığında rollout durdurulabilir.

Infrastructure as Code ile Edge Provisioning

Infrastructure as Code edge cihazların ve ilgili altyapının tekrar üretilebilir biçimde kurulmasını sağlar. Terraform, Ansible ve cloud-init gibi araçlar manuel yapılandırmayı azaltabilir. Aynı cihaz sınıfı için standart konfigürasyon oluşturmak güvenlik drift'ini önemli ölçüde azaltır. IaC dosyaları source code gibi review ve security scanning sürecinden geçmelidir. Provisioning ile security baseline aynı otomasyon içinde uygulanırsa yeni cihazların güvenli filoya katılması kolaylaşır.

Infrastructure as Code Nedir?

Infrastructure as Code altyapı tanımlarını version control altında dosyalarla yönetir. Manuel tıklama ve komut ihtiyacını azaltır. Değişiklik geçmişi görünür olur. Aynı konfigürasyon tekrar uygulanabilir. Security policy kod üzerinde test edilebilir.

Terraform

Terraform cloud, network ve bazı edge altyapı kaynaklarını declarative biçimde yönetebilir. Plan çıktısı deployment öncesi review edilir. State dosyası hassas bilgi içerebilir. Backend erişimi korunmalıdır. IaC scanner ile yanlış security configuration erken tespit edilebilir.

Ansible

Ansible işletim sistemi ve uygulama konfigürasyonlarını otomatikleştirebilir. Edge cihaz gruplarına farklı inventory uygulanabilir. Idempotent task'ler drift'i azaltır. SSH credential yönetimi güvenli yapılmalıdır. Mümkünse kalıcı manual admin erişimi azaltılmalıdır.

Cloud-Init

Cloud-init ilk boot sırasında temel cihaz konfigürasyonunu otomatikleştirebilir. Kullanıcı, network ve package ayarları verilebilir. Hassas secret doğrudan user-data içine konulmamalıdır. Bootstrap işlemi sonrasında geçici credential iptal edilmelidir. İlk provisioning süreciyle entegre edilebilir.

Declarative Configuration

Declarative model sistemin hedef durumunu tanımlar. Nasıl yapılacağından çok sonuç ifade edilir. Otomasyon aracı actual state'i bu hedefe getirir. Drift yönetimi daha kolay hale gelir. GitOps yaklaşımıyla doğal biçimde birleşir.

Aynı Edge Konfigürasyonunu Tekrarlanabilir Hale Getirmek

Her saha cihazının farklı manuel ayara sahip olması operasyon riskini artırır. Standard image ve IaC kullanımı cihazlar arasındaki farkı azaltır. Environment'a özel değerler kontrollü parameter olarak tutulabilir. Provisioning test ortamında tekrar denenebilir. Yeni cihaz ekleme süresi kısalır.

IaC Security Scanning

IaC dosyaları production altyapısını oluşturduğu için güvenlik açısından taranmalıdır. Public port, weak encryption veya geniş IAM policy erken bulunabilir. Scanner CI pipeline içinde çalışır. Kurum politikası custom rule olarak eklenebilir. Kritik ihlal merge işlemini durdurabilir.

Immutable Edge Infrastructure

Immutable infrastructure çalışan sistemi elle değiştirmek yerine değişikliği yeni image veya yeniden deployment üzerinden uygulamayı hedefler. Edge node'lara sürekli SSH ile müdahale etmek kısa vadede hızlı görünse de zamanla configuration drift oluşturur. Declarative OS configuration ve standard image yönetimi ortamı daha öngörülebilir hale getirir. Cattle vs Pets yaklaşımı cihazların benzersiz manuel varlıklar yerine tekrar üretilebilir üyeler olarak ele alınmasını sağlar. Donanım arızası veya compromise durumunda güvenli re-provisioning kolaylaşır.

Immutable Infrastructure Nedir?

Immutable model production sisteminde doğrudan kalıcı değişiklik yapılmasını azaltır. Yeni konfigürasyon yeni image veya deployment olarak gelir. Eski sürüm yeniden üretilebilir durumda kalır. Drift riski düşer. Rollback belirli artifact sürümüne dönüşle yapılabilir.

SSH ile Manuel Yönetimi Azaltmak

SSH tamamen yasaklanmak zorunda değildir ancak rutin yönetim aracı olmamalıdır. Manuel komutlar state farkına yol açar. Break-glass erişim güçlü audit ile korunmalıdır. Normal değişiklikler GitOps veya automation üzerinden yapılmalıdır. SSH erişimi geçici credential ile sınırlandırılabilir.

Declarative OS Configuration

OS servisleri, package sürümleri ve security ayarları deklaratif olarak tanımlanabilir. Değişiklikler version control üzerinden review alır. Yeni cihaz aynı baseline ile hazırlanır. Drift detection kolaylaşır. Re-provisioning süreleri kısalır.

Cattle vs Pets Yaklaşımı

Pets yaklaşımında her sunucu veya cihaz benzersiz ve elle korunması gereken varlık gibi görülür. Cattle yaklaşımında cihazlar standardize ve yeniden oluşturulabilir kabul edilir. Edge donanımı fiziksel olarak benzersiz olsa bile yazılım state'i standardize edilebilir. Compromise durumunda temiz image ile yeniden kurulum kolaylaşır. Bu yaklaşım manuel bakım ihtiyacını azaltır.

Değişiklikleri Yeniden Deployment ile Uygulamak

Konfigürasyon değişikliği doğrudan cihaz üzerinde yapılmak yerine pipeline'a girer. Test ve security scan sonrasında yeni artifact üretilir. Canary cihazlarda doğrulanır. Sonra filo kademeli güncellenir. Böylece değişiklik kanıtı ve rollback noktası korunur.

Edge Runtime Security

Runtime security pipeline'dan geçen güvenli artifact'ın production'da beklenen davranışını sürdürüp sürdürmediğini izler. Process, file, network ve privilege aktiviteleri önemli sinyaller üretir. Container escape veya beklenmeyen shell açılması gibi olaylar yalnızca build scanner ile görülmeyebilir. eBPF tabanlı araçlar Linux sistem çağrılarını düşük seviyede gözlemleyebilir. Falco gibi çözümler uygun rule set ve kaynak ayarıyla edge cluster'larda değerlendirilebilir.

Deployment Sonrası Güvenlik Neden Gereklidir?

Build sırasında temiz görünen uygulama runtime'da saldırıya uğrayabilir. Zero-day veya stolen credential buna örnektir. Davranış bazlı monitoring yeni sinyaller üretir. Runtime olayları incident response'a bağlanmalıdır. Security kontrolü deployment ile bitmemelidir.

Process Monitoring

Beklenmeyen process çalışması compromise göstergesi olabilir. Container içinde shell veya crypto miner process'i örnek verilebilir. Normal workload process profili oluşturulabilir. Yeni process yüksek riskli rule ile alarm üretebilir. False positive azaltmak için uygulama davranışı anlaşılmalıdır.

File Integrity Monitoring

Kritik binary veya configuration dosyalarının değişmesi izlenebilir. Immutable filesystem yaklaşımı bu riski azaltır. Değişiklik hash kontrolüyle tespit edilebilir. Yetkisiz modification alarm üretmelidir. Log ve geçici dosyalar ayrı policy ile ele alınmalıdır.

Network Behaviour

Workload'ın normalde bağlanmadığı dış IP veya domain risk sinyali olabilir. Egress telemetry bu davranışı görünür hale getirir. Baseline oluşturulabilir. Ani connection artışı da uyarı üretebilir. NetworkPolicy ihlalleri ayrıca izlenmelidir.

Container Escape Detection

Container escape saldırganın host seviyesine çıkmaya çalışmasıdır. Beklenmeyen namespace veya mount davranışı sinyal sağlayabilir. Privileged container'ı engellemek riski azaltır. Runtime security system call aktivitesini izleyebilir. Node compromise şüphesinde cihaz quarantine edilmelidir.

Privilege Escalation Detection

Process'in beklenmeyen şekilde daha yüksek yetki alması kritik olaydır. SUID, capability veya kernel exploit kaynaklı olabilir. Runtime rule bu davranışları izleyebilir. Non-root container saldırı etkisini azaltır. Alarm sonrası workload otomatik durdurma politikası değerlendirilebilir.

eBPF Tabanlı Runtime Security

eBPF Linux kernel olaylarını gözlemlemek için güçlü mekanizma sunar. System call ve network davranışı analiz edilebilir. Geleneksel agent'a göre farklı görünürlük sağlar. Kernel uyumluluğu edge dağıtımında test edilmelidir. Resource tüketimi düşük donanımda ölçülmelidir.

Falco

Falco runtime davranışını kurallar üzerinden izleyebilir. Container ve Kubernetes context'iyle güvenlik olayı üretebilir. Rule set uygulama davranışına göre özelleştirilebilir. Edge ortamında log hacmi ve CPU kullanımı ölçülmelidir. Kritik olaylar yerel olarak öncelikli buffer'a yazılabilir.

Edge Security Observability

Security observability yalnızca log toplamaktan daha geniş bir kavramdır. Metrics, traces, security events, audit logs, device health ve deployment olayları ortak görünürlük sağlamalıdır. Edge bağlantısı kesildiğinde telemetry tamamen kaybolmamalıdır. Yerel buffering ve önceliklendirme kullanılarak kritik güvenlik olayları bağlantı geri geldiğinde merkezi sisteme aktarılabilir. Gözlemleme tasarımının bant genişliği ve disk sınırlarını dikkate alması gerekir.

Metrics

Metrics CPU, memory, latency ve security counter gibi sayısal verileri gösterir. Edge cihaz başına temel sağlık profili oluşturulabilir. Anormal değerler alert üretir. Metric sampling bağlantı kapasitesine göre ayarlanmalıdır. Kritik metric'ler daha sık toplanabilir.

Logs

Logs uygulama ve sistem olaylarının ayrıntılı kaydını sağlar. Hassas veri log içine yazılmamalıdır. Rotation ve disk limitleri belirlenmelidir. Security log'ları daha yüksek saklama önceliğine sahip olabilir. Merkezi aktarım kesildiğinde local buffer kullanılabilir.

Traces

Distributed trace servisler arasındaki request akışını gösterir. Edge ile cloud arasındaki latency problemlerini anlamaya yardımcı olur. Security incident sırasında beklenmeyen servis çağrıları görülebilir. Trace hacmi yüksek olabilir. Sampling politikası bant genişliğine göre ayarlanmalıdır.

Security Events

Security events policy violation, runtime alert veya authentication failure gibi olayları içerir. Severity bilgisi bulunmalıdır. Kritik olaylar anında veya ilk bağlantıda gönderilmelidir. Duplicate event kontrolü yapılmalıdır. Incident sistemine otomatik aktarım değerlendirilebilir.

Audit Logs

Audit logs yönetim ve güvenlik kararlarının izini tutar. Kim, ne zaman, hangi değişikliği yaptı bilgisi önemlidir. Log bütünlüğü korunmalıdır. Clock drift olay sıralamasını bozabileceği için zaman senkronizasyonu düşünülmelidir. Compliance evidence olarak kullanılabilir.

Device Health

Device health sıcaklık, disk, boot durumu ve agent sağlığı gibi sinyalleri içerir. Güvenlik kararı device posture ile ilişkilendirilebilir. Aşırı sıcaklık donanım arızasının erken işareti olabilir. Health verisi deployment ring ilerlemesini etkileyebilir. Offline cihazların son görülen durumu ayrıca gösterilmelidir.

Deployment Events

Deployment events hangi sürümün ne zaman hangi cihaza gittiğini gösterir. Başarı, failure ve rollback bilgisi kaydedilir. Security alert ile release korelasyonu yapılabilir. Canary aşamasında özellikle önemlidir. Fleet coverage raporu bu veriden üretilebilir.

Kesintili Bağlantıda Logging

Merkezi logging altyapısı edge cihazın sürekli online olduğunu varsayarsa veri kaybı yaşanabilir. Local buffering ve store-and-forward modeli bağlantı kesintilerinde kayıtları cihazda geçici olarak tutar. Disk sınırı aşılırsa log önceliklendirmesi devreye girmelidir. Security ve audit kayıtları düşük önem seviyeli debug loglarından önce korunmalıdır. Bağlantı geri geldiğinde veri kontrollü hızda merkezi sisteme senkronize edilmelidir.

Merkezi Logging'in Problemi

Edge cihaz merkezi log sunucusuna sürekli ulaşamayabilir. Bağlantı kesildiğinde doğrudan gönderim yapan uygulama kayıt kaybedebilir. Retry mekanizması aşırı kaynak tüketebilir. Yerel buffer bu sorunu azaltır. Merkezi sistem son log zamanını izleyerek görünürlük kaybını fark etmelidir.

Local Buffering

Local buffer logları geçici disk alanında saklar. Boyut limiti açık biçimde belirlenmelidir. Buffer şifrelenebilir. Kritik loglar ayrı queue içinde tutulabilir. Disk dolarsa kontrollü silme politikası uygulanmalıdır.

Store-and-Forward

Store-and-forward modelinde kayıt önce yerel olarak güvenli biçimde saklanır. Bağlantı geldiğinde merkezi sisteme gönderilir. Gönderim teyit edilince lokal kopya silinebilir. Duplicate event idempotent biçimde ele alınmalıdır. Uzun kesintiler için kapasite planı yapılmalıdır.

Disk Limitleri

Log sistemi diskin tamamını tüketmemelidir. Maksimum yüzde veya byte limiti tanımlanabilir. Kritik uygulama verisi için rezerv alan bırakılır. Log compression kullanılabilir. Disk doluluk alarmı erken üretilmelidir.

Log Prioritization

Her log aynı öneme sahip değildir. Security alert ve audit kayıtları yüksek öncelik alabilir. Debug logları önce silinebilir. Severity ve source bazlı queue oluşturulabilir. Öncelik politikası incident gereksinimlerine göre hazırlanmalıdır.

Bağlantı Geldiğinde Merkezi Sisteme Senkronizasyon

Bağlantı geri geldiğinde bütün backlog aynı anda gönderilmemelidir. Rate limit workload trafiğinin etkilenmesini önler. Yeni kritik event eski düşük öncelikli logdan önce gönderilebilir. Sequence veya timestamp ile bütünlük korunmalıdır. Tamamlanan senkronizasyon metric olarak raporlanabilir.

Edge'de Monitoring ve Alerting

Monitoring edge cihazın hem operasyonel hem güvenlik sağlığını görünür hale getirir. CPU, memory ve disk gibi klasik metriklerin yanında device temperature, certificate expiration, policy violation ve configuration drift takip edilmelidir. Alert sistemi gerçek müdahale gerektiren olayları öne çıkarmalıdır. Binlerce cihazda aynı soruna ait binlerce ayrı alarm üretmek yerine filo düzeyinde korelasyon yapılabilir. Alarm kuralları deployment ring ve cihaz criticality bilgisiyle zenginleştirilebilir.

CPU ve Memory

CPU ve memory değerleri workload kapasitesi hakkında temel sinyal verir. Ani artış saldırı veya uygulama problemi göstergesi olabilir. Cihaz sınıfına göre farklı threshold tanımlanmalıdır. Uzun dönem trend capacity planning sağlar. Security agent overhead ayrıca izlenebilir.

Disk Kullanımı

Disk doluluğu log ve update süreçlerini durdurabilir. Threshold update başlamadan önce kontrol edilmelidir. Hızlı disk büyümesi anomali sinyali olabilir. Log rotation çalışması izlenmelidir. Kritik limitte otomatik temizlik kontrollü yapılabilir.

Network

Network latency, packet loss ve throughput izlenebilir. Bağlantı kesintileri operasyon context'i sağlar. Beklenmeyen dış trafik security alert üretebilir. Network baseline lokasyona göre farklı olabilir. Mobil bağlantı kullanan cihazlarda maliyet de ölçülebilir.

Device Temperature

Sıcaklık edge donanım sağlığında önemli metriktir. Aşırı sıcaklık performans düşürmeye veya kapanmaya yol açabilir. Cihaz fiziksel ortamındaki problem erken fark edilebilir. Thermal throttling uygulama latency'sini etkileyebilir. Alarm eşikleri üretici değerlerine göre ayarlanmalıdır.

Service Health

Service health yalnızca process'in çalışıp çalışmadığını kontrol etmemelidir. API response, dependency ve temel business function doğrulanabilir. Health check deployment kararında kullanılabilir. Sürekli başarısızlık otomatik rollback tetikleyebilir. Local ve central health görünümü ayrılabilir.

Certificate Expiration

Certificate süresi dolmadan önce alert üretilmelidir. Rotation sistemi otomatik olsa bile başarısızlık ihtimali vardır. Offline cihazlar daha erken uyarı gerektirebilir. Filo dashboard yaklaşan expiry sayılarını gösterebilir. Expired certificate production kesintisine dönüşmeden müdahale edilmelidir.

Security Policy Violation

Policy ihlali risk seviyesine göre sınıflandırılmalıdır. İmzasız artifact girişimi yüksek öncelikli olabilir. Düşük riskli configuration ihlali toplu raporlanabilir. Tekrarlanan violation root cause araştırması gerektirir. Alert doğrudan ilgili deployment ve kullanıcı kimliğiyle ilişkilendirilmelidir.

Failed Update

Update failure cihazı eski ve vulnerable sürümde bırakabilir. Bu nedenle yalnızca operasyon problemi değildir. Failure oranı deployment ring bazında izlenmelidir. Belirli eşiğin üzerinde rollout otomatik durabilir. Başarısız cihazlar ayrı remediation listesine alınmalıdır.

Configuration Drift

Configuration drift security baseline'dan sapmayı gösterir. Kritik dosya veya policy farkı hemen raporlanabilir. GitOps reconciliation sonucu ayrıca izlenmelidir. Sürekli geri gelen drift manuel müdahale göstergesi olabilir. Device identity ile birlikte loglanmalıdır.

Edge DevSecOps'ta Vulnerability Management

Vulnerability management yalnızca scanner çalıştırıp CVE listesi üretmek değildir. Asset inventory, SBOM, severity, exploitability, exposure ve business criticality birlikte değerlendirilmelidir. Böylece gerçekten riskli cihazlara öncelik verilebilir. Edge filosunda patch maliyeti yüksek olduğu için risk tabanlı sıralama daha da önem kazanır. Edge Computing Mimarisinde DevSecOps Pratikleri başarılı olduğunda vulnerability verisi doğrudan deployment ve remediation sürecine bağlanır.

CVE Discovery

Scanner ve advisory feed yeni CVE'leri tespit etmeye yardımcı olur. Container, OS ve firmware bileşenleri ayrı değerlendirilmelidir. Feed güncelliği takip edilmelidir. False positive kontrolü yapılmalıdır. Discovery sonucu asset inventory ile eşleştirilmelidir.

Asset Inventory

Asset inventory hangi cihazın hangi software sürümünü çalıştırdığını gösterir. Device model, location ve criticality bilgisi eklenebilir. SBOM ile bağlandığında dependency seviyesinde görünürlük sağlar. Güncel olmayan inventory risk analizini bozar. Provisioning ve decommission süreçleri envanteri otomatik güncellemelidir.

SBOM ile Etkilenen Cihazları Bulmak

CVE'nin etkilenen package sürümü belirlenir. SBOM verisi bu sürümü içeren artifact'ları bulur. Deployment inventory hangi cihazların bu artifact'ı kullandığını gösterir. Sonuç doğrudan remediation grubuna dönüştürülebilir. Bu yöntem bütün filoyu gereksiz güncellemekten kaçınmayı sağlar.

Severity

Severity açığın teknik etkisi hakkında temel sinyal sağlar. Ancak tek karar ölçütü değildir. CVSS yüksek olsa bile exposure olmayabilir. Düşük puanlı açık kritik iş sürecinde daha önemli olabilir. Severity diğer risk faktörleriyle birlikte kullanılmalıdır.

Exploitability

Public exploit bulunması remediation önceliğini artırabilir. Aktif exploitation bilgisi daha da kritiktir. Fiziksel erişim gerektiren açık edge cihazlarda yine gerçek risk olabilir. Preconditions incelenmelidir. Threat intelligence ile scanner verisi birleştirilebilir.

Exposure

Exposure vulnerable servisin saldırgan tarafından erişilebilirliğini ifade eder. Public internet erişimi riski yükseltebilir. Network segmentation riski azaltabilir. Local-only servis fiziksel saldırı senaryosunda yine önemli olabilir. Exposure bilgisi network inventory ile desteklenmelidir.

Business Criticality

Business criticality cihazın iş sürecindeki önemini gösterir. Kritik üretim kontrolü yapan cihaz öncelikli olabilir. Lokasyon ve servis tipi bu değeri etkiler. Envanterde açık biçimde tutulmalıdır. Patch SLA criticality seviyesine göre değişebilir.

Remediation Priority

Remediation priority bütün risk sinyallerinin birleşimidir. Severity, exploitability, exposure ve criticality birlikte değerlendirilir. Compensating control varsa geçici risk azaltımı yapılabilir. Karar kayıt altına alınmalıdır. Otomasyon öncelikli cihaz grubunu deployment ring'e aktarabilir.

Patch Management

Patch management edge filolarında test, rollout ve rollback disiplinini birlikte gerektirir. Kritik CVE çıktığında hızlı hareket etmek önemlidir ancak test edilmemiş patch'i bütün filoya göndermek ayrı risk yaratır. Patch SLA, açığın risk seviyesine göre tanımlanmalıdır. Canary cihazlarda doğrulanan güncelleme kademeli olarak genişletilmelidir. Patch coverage metriği kaç cihazın güvenli sürüme geçtiğini görünür hale getirir.

Patch SLA

Patch SLA risk seviyesine göre maksimum düzeltme süresini tanımlar. Kritik ve aktif exploit bulunan açıklar daha kısa süreye sahip olabilir. Offline cihazlar için ayrı operasyon planı gerekir. SLA başlangıç ve bitiş zamanı ölçülmelidir. Exception'lar kayıtlı risk kabulü gerektirmelidir.

Kritik CVE Süreci

Kritik CVE tespit edildiğinde etkilenen asset'lar hızla belirlenir. Exploitability ve exposure doğrulanır. Patch veya mitigation hazırlanır. Canary rollout yapılır. Süreç boyunca executive ve operasyon iletişimi net tutulmalıdır.

Patch Testi

Patch temsilî cihaz ve workload üzerinde test edilmelidir. Function, performance ve security sonuçları izlenir. ARM ve x86 varyasyonları ayrı denenebilir. Reboot gereksinimi operasyon planına eklenir. Başarılı test sonrası canary aşamasına geçilir.

Canary Patch

Patch küçük production grubuna uygulanır. Error rate ve device health izlenir. Yeni security alert oluşup oluşmadığı kontrol edilir. Belirli süre stabil kaldığında rollout genişletilir. Hata durumunda otomatik rollback yapılabilir.

Fleet Rollout

Fleet rollout deployment ring'leri boyunca ilerler. Lokasyon ve cihaz sınıfı bazında aşamalar oluşturulabilir. Bandwidth kapasitesine göre download rate sınırlandırılır. Offline cihazlar tekrar bağlandığında güvenli sürümü alır. Coverage dashboard rollout ilerlemesini gösterir.

Patch Başarısızlığında Rollback

Başarısız patch sistemi çalışamaz hale getirmemelidir. Önceki güvenli sürüm hazır tutulmalıdır. Health check rollback kararını tetikleyebilir. Vulnerable sürüme dönüş riski ayrıca değerlendirilir. Gerekirse geçici compensating control uygulanır.

Patch Coverage Ölçümü

Patch coverage güncellenmiş cihazların toplam etkilenen cihazlara oranını gösterir. Ring ve lokasyon bazında raporlanabilir. Offline cihazlar ayrı kategori olarak gösterilmelidir. Coverage düşükse operasyon engeli araştırılır. Metrik güvenlik KPI setine dahil edilebilir.

Edge Device Yaşam Döngüsü Güvenliği

Edge güvenliği cihaz üretildiği andan devre dışı bırakılana kadar devam eden bir yaşam döngüsüdür. Manufacturing, provisioning, deployment, operation, update, incident ve decommission aşamalarının her birinde farklı riskler bulunur. Güvenli ilk kimlik üretimi kadar cihaz sonunda verinin güvenli silinmesi de önemlidir. Yaşam döngüsü modeli sorumlulukların ekipler arasında kaybolmasını önler. DevSecOps yalnızca pipeline değil bu sürecin tamamını yöneten çalışma modeli olarak ele alınmalıdır.

Manufacturing

Üretim aşamasında cihaz identity ve hardware trust özellikleri hazırlanabilir. Ortak default password bırakılmamalıdır. Debug port durumu doğrulanmalıdır. Supply chain kayıtları tutulmalıdır. Üretim sistemlerinin erişimi güçlü biçimde korunmalıdır.

Provisioning

Provisioning cihazın filoya ilk güvenli katılımıdır. Bootstrap credential kısa süreli olmalıdır. Device certificate oluşturulur. Security baseline uygulanır. Asset inventory otomatik güncellenir.

Deployment

Deployment cihazın gerçek lokasyonda hizmete alınmasıdır. Network segment ve policy doğrulanmalıdır. İlk attestation yapılabilir. Gerekli workload imzalı artifact olarak yüklenir. Device health merkezi sistemde görünür olmalıdır.

Operation

Operation aşamasında monitoring ve runtime security sürekli çalışır. Certificate rotation yapılır. Configuration drift izlenir. Vulnerability durumu periyodik güncellenir. Manuel değişiklikler minimum tutulur.

Update

Update aşaması firmware, OS ve application değişikliklerini içerir. Paketler imzalı olmalıdır. Canary rollout uygulanmalıdır. Health check ve rollback mekanizması bulunmalıdır. Update coverage ölçülmelidir.

Incident

Incident sırasında cihaz isolate veya quarantine edilebilir. Certificate revoke edilir. Forensic veri korunur. Gerekirse güvenli image ile re-provisioning yapılır. Root cause sonucuna göre fleet-wide aksiyon uygulanabilir.

Decommission

Decommission kullanım ömrü biten cihazın güvenli biçimde sistemden çıkarılmasıdır. Certificate ve credential iptal edilir. Asset inventory durumu değiştirilir. Yerel veri güvenli silinir. Donanım disposal süreci kayıt altına alınır.

Secure Data Erasure

Secure data erasure cihaz üzerindeki hassas verinin geri getirilemeyecek biçimde kaldırılmasını amaçlar. Cryptographic erase şifreleme anahtarının güvenli silinmesini kullanabilir. Depolama tipine uygun yöntem seçilmelidir. İşlem doğrulanmalı ve kaydedilmelidir. Cihaz yeniden kullanılacaksa temiz provisioning uygulanmalıdır.

EOL ve Desteklenmeyen Edge Cihazlar

Edge cihazların uzun yaşam döngüsü sonunda işletim sistemi veya firmware desteği bitebilir. Desteklenmeyen sistemler yeni security patch alamadığı için zamanla artan risk oluşturur. Replacement hemen mümkün değilse network isolation ve compensating control kullanılabilir. Risk acceptance geçici ve kayıtlı karar olmalıdır. Uzun vadeli çözüm cihaz yenileme planıdır.

Unsupported Operating System

Desteklenmeyen OS güvenlik güncellemesi alamaz. Yeni CVE'ler açık kalabilir. İnternet erişimi mümkün olduğunca sınırlandırılmalıdır. Workload ve network isolasyonu artırılabilir. Replacement takvimi belirlenmelidir.

Firmware Güncellemesi Alamayan Cihaz

Firmware update desteği olmayan cihaz kalıcı risk oluşturabilir. Known vulnerability durumu izlenmelidir. Device criticality değerlendirilir. Compensating control uygulanabilir. Yeni satın alma kriterlerinde vendor support süresi açık şart olmalıdır.

Risk Acceptance

Risk acceptance güvenlik açığını görmezden gelmek değildir. İş etkisi ve mitigation değerlendirilerek kayıtlı karar verilir. Süre sınırı bulunmalıdır. Risk owner tanımlanmalıdır. Süre sonunda karar tekrar incelenmelidir.

Network Isolation

Legacy cihaz ayrı network segmentine alınabilir. Yalnızca gerekli servislerle iletişim kurmasına izin verilir. Internet egress kapatılabilir. Monitoring artırılabilir. Isolation replacement yerine kalıcı çözüm sayılmamalıdır.

Compensating Controls

Patch uygulanamadığında alternatif güvenlik kontrolü riski azaltabilir. Firewall rule, proxy veya application gateway buna örnektir. Kontrol vulnerability'nin exploit yoluna uygun olmalıdır. Etkinliği test edilmelidir. Geçici olduğu açık biçimde kaydedilmelidir.

Device Replacement Plan

Replacement plan destek bitmeden önce hazırlanmalıdır. Donanım bütçesi ve saha operasyonu planlanır. Yeni cihaz güvenlik baseline'ına uygun seçilir. Migration pilot cihazlarla başlanır. Eski cihaz güvenli decommission sürecinden geçirilir.

Edge Incident Response

Edge incident response merkezi sunucu olaylarından farklı operasyon adımları içerebilir. Cihaz fiziksel olarak uzak olabilir ve network bağlantısı güvenilir olmayabilir. İlk hedef olayın blast radius'unu azaltmak için cihazı veya segmenti izole etmektir. Certificate revocation ve fleet-wide credential rotation gerektiğinde hızlı uygulanmalıdır. Forensic veri toplandıktan sonra güvenli image ile re-provisioning çoğu durumda cihazı eski hale getirmekten daha güvenilir bir recovery yöntemi olabilir.

Incident Detection

Incident runtime alert, attestation failure veya network anomaly ile tespit edilebilir. Tek sinyal doğrudan compromise anlamına gelmeyebilir. Farklı telemetry kaynakları korele edilmelidir. Severity cihaz criticality ile birlikte değerlendirilir. Olay incident queue'ya aktarılır.

Edge Cihazı İzole Etmek

Şüpheli cihaz normal workload trafiğinden ayrılmalıdır. Quarantine network kullanılabilir. Yönetim ve forensic kanalı sınırlı biçimde açık kalabilir. Cihazın diğer edge node'lara erişimi kesilir. Isolation işlemi merkezi policy ile otomatikleştirilebilir.

Network Quarantine

Network quarantine cihazı sınırlı network segmentine taşır. Yalnızca incident servisleriyle iletişim kurmasına izin verilebilir. Normal production erişimi kapatılır. Firewall veya NAC sistemi kullanılabilir. Quarantine kaldırma işlemi approval gerektirebilir.

Certificate Revocation

Compromise edilen cihazın certificate'i hızlı biçimde revoke edilmelidir. Merkezi sistem yeni bağlantıyı reddeder. Revocation bilgisi diğer edge bileşenlerine dağıtılır. Short-lived certificate ek koruma sağlar. Re-provisioning sonrası yeni identity oluşturulabilir.

Fleet-Wide Credential Rotation

Paylaşılan credential compromise olduysa bütün filo etkilenebilir. Bu durumda geniş rotation gerekir. Benzersiz device identity kullanımı böyle olayların etkisini azaltır. Rotation ring'ler halinde yapılabilir. Eski credential kesin biçimde kapatılmalıdır.

Forensic Veri Toplama

Re-provisioning öncesi gerekli forensic bilgi güvenli biçimde alınmalıdır. Log, process list ve network connection verisi toplanabilir. Delil bütünlüğü hash ile korunabilir. Cihaz saat durumu kaydedilmelidir. Hassas veri toplama gereksinimi gizlilik politikalarıyla uyumlu olmalıdır.

Güvenli Image ile Re-Provisioning

Compromise sonrası tek tek zararlı dosya temizlemek güvenilir olmayabilir. Doğrulanmış temiz image ile yeniden provisioning tercih edilebilir. Device credential yenilenir. Secure boot ve attestation yeniden doğrulanır. Cihaz production ring'e dönmeden önce ek monitoring uygulanabilir.

Root Cause Analysis

Root cause analysis olayın yalnızca belirtilerini değil gerçek kaynağını bulmayı amaçlar. Pipeline, firmware, network veya credential kaynaklı olabilir. Sonuç threat model güncellemesine dönüştürülmelidir. Benzer cihazlar için fleet-wide kontrol yapılır. Kalıcı düzeltme automation ve policy içine eklenir.

Edge Cihazının Ele Geçirildiği Nasıl Anlaşılır?

Ele geçirilmiş edge cihazı tek bir belirtiyle her zaman anlaşılmaz. Attestation failure, beklenmeyen process, configuration drift, network anomaly, certificate davranışı ve file integrity değişikliği birlikte değerlendirilmelidir. Runtime security alert önemli sinyaldir ancak doğrulama için diğer telemetry kaynakları kullanılmalıdır. Özellikle düşük bağlantılı cihazlarda son güvenilir durum bilgisi takip edilmelidir. Farklı sinyaller ortak risk skoruna dönüştürülebilir.

Attestation Failure

Attestation failure boot veya platform ölçümlerinin beklenen değerle eşleşmediğini gösterebilir. Firmware değişikliği buna neden olabilir. Hemen compromise varsaymak yerine bakım geçmişi kontrol edilir. Beklenmeyen değişiklik varsa cihaz quarantine edilir. Yeni trust state yalnızca doğrulama sonrası kabul edilmelidir.

Beklenmeyen Process

Normal workload profilinde bulunmayan process güvenlik sinyali olabilir. Shell, scanner veya miner process'i örnek verilebilir. Runtime agent process ağacını kaydedebilir. Parent process ilişkisi analizi kolaylaştırır. Kritik olayda workload durdurulabilir.

Configuration Drift

Security konfigürasyonunun izinsiz değişmesi compromise göstergesi olabilir. Firewall veya service ayarı buna örnektir. GitOps agent farkı tespit eder. Değişikliğin kaynağı audit log üzerinden araştırılır. Beklenmeyen drift tekrarlanıyorsa cihaz isolate edilmelidir.

Beklenmeyen Network Trafiği

Cihazın bilinmeyen dış adreslerle iletişim kurması risk sinyalidir. Normal trafik baseline ile karşılaştırılır. DNS sorguları ek context sağlar. Egress filtering saldırı kanalını sınırlayabilir. Olay başka cihazlarda da aranmalıdır.

Certificate Anomalisi

Bir device certificate'in aynı anda farklı lokasyonlardan kullanılması kopyalama göstergesi olabilir. Beklenmeyen authentication failure da sinyal sağlayabilir. Certificate kullanım telemetry'si merkezi olarak analiz edilir. Şüpheli certificate hızlıca revoke edilebilir. Hardware-backed private key bu riski azaltır.

File Integrity Değişikliği

Kritik binary veya config hash değişimi yetkisiz modification göstergesi olabilir. Update ile ilişkili meşru değişiklik release metadata ile doğrulanmalıdır. Beklenmeyen değişiklik alarm üretir. Read-only filesystem riski azaltır. Forensic inceleme öncesi ilgili dosyalar korunabilir.

Runtime Security Alert

Runtime alert olayın gerçekleştiği anda davranış sinyali sağlar. Rule severity ve context önemlidir. Tek başına alarm yerine process, network ve identity bilgisi birleştirilmelidir. Critical alert otomatik quarantine tetikleyebilir. False positive düzenli rule tuning ile azaltılmalıdır.

Compliance as Code

Compliance as Code uyumluluk gereksinimlerini manuel kontrol listelerinden otomatik teknik kontrollere dönüştürür. Policy as Code, configuration evidence, build evidence ve audit log bu yaklaşımın parçalarıdır. Pipeline her release için gerekli kanıtları otomatik üretebilir. Böylece denetim zamanı geldiğinde aylar öncesinin ekran görüntülerini aramak yerine sürekli güncellenen evidence kullanılabilir. Edge filolarında ölçek nedeniyle otomatik evidence toplama büyük operasyon avantajı sağlar.

Compliance Kontrollerini Pipeline'a Taşımak

Gerekli security configuration build ve deployment aşamasında kontrol edilebilir. Encryption veya signing şartı policy haline getirilebilir. Başarısız kontrol release'i durdurur. Evidence otomatik saklanır. Denetim gereksinimi günlük engineering sürecinin parçasına dönüşür.

Policy as Code

Compliance policy version control altında tutulabilir. Değişiklik kim tarafından yapıldığıyla izlenir. Otomatik test policy davranışını doğrular. Aynı kural bütün edge cluster'lara uygulanabilir. Exception kayıtlı ve süreli tutulmalıdır.

Automated Evidence Collection

Evidence manuel toplanmak yerine pipeline ve runtime sisteminden otomatik alınabilir. Build ID, scan sonucu ve signature bilgisi saklanabilir. Configuration snapshot belirli aralıklarla kaydedilebilir. Audit log merkezi veya güvenli arşivde tutulur. Evidence bütünlüğü korunmalıdır.

Configuration Evidence

Configuration evidence sistemin belirli tarihte hangi security ayarlarına sahip olduğunu gösterir. Git commit ve actual state snapshot birlikte tutulabilir. Drift raporu ek kanıt sağlar. Sensitive secret değerleri evidence içine alınmamalıdır. Yalnızca gerekli metadata saklanmalıdır.

Build Evidence

Build evidence artifact'ın nasıl üretildiğini gösterir. CI job, source commit ve security scan sonucu kaydedilebilir. Provenance bu bilgiyi standart biçimde sağlayabilir. Artifact digest ile bağ kurulmalıdır. Release denetiminde tekrar üretilebilirlik kolaylaşır.

Deployment Evidence

Deployment evidence hangi artifact'ın hangi edge grubuna dağıtıldığını gösterir. Ring ilerleme zamanı kaydedilir. Signature verification sonucu tutulabilir. Failed ve rollback olayları da evidence kapsamına alınmalıdır. Device coverage raporu uyumluluk görünürlüğünü artırır.

Audit Log Evidence

Audit log yönetim faaliyetlerinin kimlik ve zaman bilgisini sağlar. Log bütünlüğü korunmalıdır. Retention süresi compliance gereksinimine göre belirlenir. Kritik yetki değişiklikleri kolay aranabilir olmalıdır. Offline edge logları bağlantı geldiğinde güvenli arşive aktarılabilir.

Edge Veri Egemenliği ve Gizlilik

Edge Computing'in önemli avantajlarından biri verinin kaynağa yakın işlenebilmesidir. Bu özellik data localization ve data minimization hedeflerini destekleyebilir. Her veriyi cloud'a göndermek yerine yalnızca gerekli özet veya sonuç aktarılabilir. Encryption at rest ve encryption in transit temel koruma sağlar. Veri retention politikası hem edge cihaz hem merkezi sistem için ayrı ayrı tanımlanmalıdır.

Data Localization

Data localization belirli verinin belirli coğrafi bölgede tutulmasını gerektirebilir. Edge processing bu gereksinime yardımcı olabilir. Cloud transfer yolları policy ile sınırlandırılmalıdır. Backup lokasyonu da dikkate alınmalıdır. Asset ve data flow inventory bu kontrolü destekler.

Data Minimization

Data minimization yalnızca gerekli verinin toplanmasını ve saklanmasını hedefler. Edge cihaz gereksiz raw veriyi merkezi sisteme göndermeyebilir. İşlendikten sonra geçici veri silinebilir. Loglarda kişisel veri azaltılmalıdır. Daha az veri daha küçük saldırı etkisi anlamına gelir.

Edge'de Yerel İşleme

Yerel processing düşük latency yanında gizlilik avantajı sağlayabilir. Kamera görüntüsü cloud'a göndermek yerine cihazda analiz edilebilir. Merkezi sisteme yalnızca olay sonucu aktarılabilir. Device compromise riski nedeniyle local storage yine korunmalıdır. Data retention süresi minimum tutulmalıdır.

Cloud'a Hangi Verinin Gönderileceğini Kontrol Etmek

Data flow policy cloud'a hangi alanların çıkabileceğini tanımlamalıdır. Gateway seviyesinde filtering yapılabilir. Hassas alanlar maskelenebilir. Uygulama değişikliği policy review gerektirebilir. Network egress monitoring veri sızıntısını fark etmeye yardımcı olur.

Encryption at Rest

Disk üzerinde tutulan hassas veri şifrelenmelidir. Key aynı disk üzerinde açık biçimde saklanmamalıdır. Hardware-backed key kullanımı değerlendirilebilir. Backup da şifrelenmelidir. Decommission sırasında key güvenli şekilde silinmelidir.

Encryption in Transit

Edge ile cloud arasındaki trafik TLS ile korunmalıdır. Servisler arası hassas trafik için mTLS kullanılabilir. Certificate doğrulaması kapatılmamalıdır. Eski protocol ve cipher seçenekleri sınırlandırılmalıdır. Certificate rotation otomatik olmalıdır.

Veri Retention

Retention verinin ne kadar süre saklanacağını belirler. Edge cihaz diski sınırlı olduğu için operasyon açısından da önemlidir. Legal ve business gereksinimleri birlikte değerlendirilir. Süre dolduğunda otomatik deletion uygulanabilir. Silme işlemi audit edilebilir.

Edge DevSecOps KPI ve Metrikleri

DevSecOps olgunluğu yalnızca kullanılan araç sayısıyla ölçülmemelidir. Deployment frequency, change failure rate, remediation süresi, patch coverage ve signed artifact coverage daha anlamlı sinyaller sunar. Security metric'lerin operasyon metric'leriyle birlikte değerlendirilmesi gerekir. Örneğin daha fazla vulnerability bulmak tek başına kötü sonuç değildir çünkü görünürlüğün arttığını gösterebilir. Ama vulnerability age sürekli yükseliyorsa remediation sürecinde gerçek bir darboğaz vardır.

Deployment Frequency

Deployment frequency değişikliklerin ne sıklıkla güvenli biçimde production'a ulaştığını gösterir. Çok düşük oran manuel süreçlere işaret edebilir. Çok yüksek oran da kalite metrikleriyle birlikte değerlendirilmelidir. Ring bazında ölçüm yapılabilir. Security gate süresi ayrıca izlenebilir.

Deployment Success Rate

Success rate rollout'un kaç cihazda problemsiz tamamlandığını gösterir. Hardware sınıfına göre ayrılabilir. Düşük oran update mekanizması veya test eksikliğini gösterebilir. Offline cihazlar ayrı kategori olmalıdır. Trend zaman içinde izlenmelidir.

Change Failure Rate

Change failure rate production değişikliklerinin ne kadarının incident veya rollback oluşturduğunu gösterir. Edge için ring bazında ölçüm faydalıdır. Yüksek oran test kapsamının yetersiz olduğunu gösterebilir. Security policy kaynaklı failure ayrı analiz edilebilir. Amaç release hızını kaliteyle birlikte iyileştirmektir.

Mean Time to Recovery

MTTR sistem arızasından normal çalışmaya dönme süresini ölçer. Uzak edge cihazlarda recovery süreleri lokasyona göre değişebilir. Otomatik rollback MTTR'ı düşürür. Re-provisioning süresi ayrıca ölçülebilir. Kritik cihazlar için hedef süre belirlenmelidir.

Mean Time to Remediate

MTTRem güvenlik bulgusunun tespitinden düzeltmeye kadar geçen süreyi ölçer. Severity seviyesine göre ayrılmalıdır. Patch test ve rollout süreleri görünür hale gelir. Uzun süre açık kalan vulnerability'ler risk oluşturur. Automation bu metriği iyileştirebilir.

Vulnerability Age

Vulnerability age açığın filoda ne kadar süredir açık kaldığını gösterir. Ortalama yerine percentil ve severity dağılımı daha anlamlı olabilir. Kritik açıklar ayrı izlenmelidir. Accepted risk kayıtları raporda ayrılabilir. Yaş artışı patch sürecindeki sorunu görünür kılar.

Patch Coverage

Patch coverage etkilenen cihazların ne kadarının güvenli sürüme geçtiğini gösterir. Offline cihazlar ayrıca gösterilmelidir. Yüzde yüz hedef her zaman anında mümkün olmayabilir. Ancak kritik filoda düşük coverage açık risk demektir. Dashboard ring bazında ilerleme sunabilir.

Signed Artifact Coverage

Signed artifact coverage production artifact'larının ne kadarının doğrulanabilir imzaya sahip olduğunu ölçer. Hedef ideal olarak yüzde yüz olmalıdır. Exception'lar açık biçimde görünmelidir. Container ve firmware ayrı raporlanabilir. Admission enforcement kapsama oranını güçlendirir.

SBOM Coverage

SBOM coverage production artifact'larının ne kadarında güncel SBOM bulunduğunu gösterir. Eski artifact'lar da kapsama dahil edilmelidir. SBOM'un artifact digest ile ilişkilendirilmesi gerekir. Eksik alanlar remediation listesi oluşturabilir. Bu metrik vulnerability response hızını etkiler.

Policy Compliance Rate

Policy compliance rate cihaz ve workload'ların güvenlik baseline'a uyumunu gösterir. Kritik policy'ler ayrı raporlanmalıdır. Exception sayısı izlenebilir. Drift kaynaklı ihlaller trend oluşturabilir. Yüksek oran yanında policy kalitesinin de doğru olması gerekir.

Device Trust Failure Rate

Device trust failure rate attestation veya identity doğrulamasında başarısız olan cihaz oranını gösterir. Ani artış firmware veya provisioning problemi olabilir. Lokasyon bazında analiz yapılabilir. Gerçek compromise sinyalleri ayrıca ayrılmalıdır. Trend hardware güven zincirinin sağlığını gösterir.

Edge DevSecOps Referans Toolchain

Referans toolchain seçerken amaç mümkün olan en fazla aracı kurmak olmamalıdır. Her araç gerçek bir risk veya operasyon ihtiyacını karşılamalıdır. Git, CI/CD, IaC, container scanning, SBOM, signing, policy, GitOps, runtime security, secrets ve observability katmanları birbirine bağlanmalıdır. Araçlar arasında artifact identity ve metadata akışı korunursa güvenlik görünürlüğü artar. Kurumun farklı teknoloji projelerindeki yaklaşımını görmek için https://www.diyarbakiryazilim.com.tr/projects adresindeki çalışmalar incelenebilir.

Source Control

Source control kod ve konfigürasyon değişikliklerinin merkezi kaydını tutar. Branch protection ve review uygulanmalıdır. Kullanıcı kimliği ve audit kritik öneme sahiptir. Pipeline tanımları da aynı güvenlik seviyesinde korunmalıdır. Git bu alanın temel teknolojilerinden biridir.

Git

Git source code ve declarative configuration için yaygın version control sistemidir. Commit geçmişi değişiklik izlenebilirliği sağlar. Signed commit ve protected branch gibi güvenlik katmanları eklenebilir. Secret'lar repository içinde tutulmamalıdır. Repository backup ve erişim politikası ayrıca planlanmalıdır.

CI/CD

CI/CD kaynak koddan güvenilir artifact üretip deployment sürecini otomatikleştirir. Security scanning bu akışın içine yerleştirilmelidir. Runner izolasyonu önemlidir. Credential kısa ömürlü tutulmalıdır. GitLab CI, GitHub Actions ve Jenkins farklı işletim modelleri sunar.

GitLab CI

GitLab CI repository ile entegre pipeline oluşturabilir. Runner'ların network ve yetki sınırları ayrı tasarlanmalıdır. Protected environment production erişimini sınırlayabilir. Security scanning job'ları pipeline'a eklenebilir. Self-hosted kullanımda platform güncellemeleri düzenli yapılmalıdır.

GitHub Actions

GitHub Actions workflow tabanlı CI/CD sağlar. Third-party action sürümleri immutable referansla pinlenmelidir. OIDC federation kalıcı cloud key ihtiyacını azaltabilir. Environment protection production deployment'a approval ekleyebilir. Workflow dosyaları CODEOWNERS ile korunabilir.

Jenkins

Jenkins esnek pipeline otomasyonu sağlar. Plugin sayısı ve güncelliği güvenlik açısından dikkatle yönetilmelidir. Controller erişimi sınırlandırılmalıdır. Ephemeral agent modeli tercih edilebilir. Credential store ve pipeline logları korunmalıdır.

Infrastructure as Code

IaC edge altyapısının tekrar üretilebilir olmasını sağlar. Terraform ve Ansible yaygın seçeneklerdir. Security scanning deployment öncesi yanlış ayarları bulabilir. State ve inventory verisi hassas olabilir. Değişiklikler pull request üzerinden yönetilebilir.

Terraform

Terraform declarative infrastructure provisioning sağlar. Plan çıktısı review sürecine eklenebilir. State erişimi minimum yetkiyle korunmalıdır. Module dependency'leri sabit sürümlere bağlanmalıdır. CI içinde IaC scanner çalıştırılabilir.

Ansible

Ansible configuration management ve provisioning görevlerinde kullanılabilir. Edge inventory cihaz gruplarını tanımlayabilir. Role yapısı standardizasyon sağlar. Secret veriler güvenli vault veya external manager ile yönetilmelidir. Playbook değişiklikleri test edilmelidir.

Container Security

Container security image build aşamasından runtime davranışına kadar devam eder. Base image mümkün olduğunca küçük tutulmalıdır. Vulnerability scan her build'de çalışabilir. Non-root ve read-only filesystem gibi ayarlar policy ile zorunlu hale getirilebilir. Trivy yaygın kullanılan scanner seçeneklerinden biridir.

Trivy

Trivy container image, filesystem ve configuration üzerinde güvenlik taraması yapabilir. CI pipeline'a kolayca eklenebilir. Vulnerability sonuçları severity policy ile değerlendirilebilir. Offline database mirror senaryoları planlanabilir. Sonuçlar gerçek risk bağlamıyla birlikte ele alınmalıdır.

SBOM

SBOM artifact içindeki bileşenleri görünür hale getirir. Her build için otomatik üretilmelidir. Syft ve CycloneDX ekosistemi bu alanda kullanılabilir. SBOM artifact digest ile ilişkilendirilmelidir. Vulnerability response süreci bu veriyi aktif kullanmalıdır.

Syft

Syft container image ve filesystem için SBOM üretebilir. CI pipeline içinde çalıştırılabilir. Farklı çıktı formatlarını destekleyebilir. Artifact digest ile birlikte kayıt altına alınmalıdır. Üretilen SBOM güvenli depoda saklanmalıdır.

CycloneDX

CycloneDX SBOM ve supply chain metadata için kullanılan standartlardan biridir. Dependency ilişkilerini ifade edebilir. Scanner ve risk platformlarıyla entegre edilebilir. Organizasyon genelinde ortak schema kullanımı faydalıdır. SBOM kalitesi kullanılan discovery yöntemine bağlıdır.

Signing

Signing artifact kaynağını ve bütünlüğünü doğrulamak için kullanılır. Container ve firmware için uygulanabilir. Signature verification deployment policy'nin parçası olmalıdır. Signing identity güçlü korunmalıdır. Sigstore ve Cosign bu alanda kullanılabilecek araçlardır.

Sigstore / Cosign

Sigstore ekosistemi software signing süreçlerini kolaylaştırmayı hedefler. Cosign container artifact imzalama ve doğrulama için kullanılabilir. Keyless model CI identity ile entegre edilebilir. Policy yalnızca izin verilen signer'ları kabul etmelidir. Offline doğrulama gereksinimleri ayrıca planlanmalıdır.

Policy as Code

Policy as Code güvenlik kurallarını otomatik ve version kontrollü hale getirir. Kubernetes manifest ve admission kontrolünde kullanılabilir. Kyverno ve OPA Gatekeeper yaygın seçeneklerdir. Policy testleri CI aşamasında çalışmalıdır. Runtime enforcement ikinci güvenlik katmanı sağlar.

Kyverno

Kyverno Kubernetes kaynaklarına odaklı policy motorudur. Validation ve mutation kuralları oluşturulabilir. YAML tabanlı yaklaşım bazı ekipler için öğrenmeyi kolaylaştırır. Audit ve enforce modları geçişi destekler. Edge kaynak tüketimi ölçülmelidir.

OPA Gatekeeper

OPA Gatekeeper admission policy enforcement sağlar. Rego tabanlı kurallar esnek kontrol imkanı sunar. Constraint template yaklaşımı reusable policy oluşturmayı kolaylaştırır. Audit modu mevcut ihlalleri görünür hale getirir. Policy repository code review ile korunmalıdır.

GitOps

GitOps desired state'i Git üzerinden yönetir. Edge cluster değişiklikleri pull-based olarak uygulanabilir. Argo CD ve Flux bu alanda yaygın araçlardır. Repository güvenliği kritik önem taşır. Artifact signature doğrulaması GitOps güvenliğini tamamlar.

Argo CD

Argo CD Kubernetes application state'ini Git ile karşılaştırır. Drift tespiti sağlar. Sync policy otomatik veya kontrollü olabilir. Access control ve project sınırları kullanılmalıdır. Edge topolojisinde merkezi bağlantı modeli test edilmelidir.

Flux

Flux Git tabanlı reconciliation sağlar. Kaynak ve image otomasyon bileşenleri bulunabilir. Edge cluster içinde hafif deployment seçenekleri değerlendirilebilir. Git credential güvenliği önemlidir. Policy ile birlikte kullanıldığında declarative fleet yönetimi güçlenir.

Runtime Security

Runtime security çalışan workload davranışını izler. Pipeline scanner'ın göremediği olayları yakalayabilir. Process, network ve filesystem aktivitesi önemli sinyallerdir. Falco bu alanda kullanılabilecek araçlardan biridir. Rule set edge workload davranışına göre ayarlanmalıdır.

Falco

Falco Linux ve container runtime olaylarını rule tabanlı analiz edebilir. Privilege escalation veya beklenmeyen shell davranışı tespit edilebilir. Kubernetes metadata ile olay zenginleştirilebilir. Resource tüketimi cihaz üzerinde ölçülmelidir. Kritik alert'ler incident response sistemine bağlanmalıdır.

Secrets

Secret yönetimi source repository'den ayrı tutulmalıdır. Short-lived credential tercih edilmelidir. Workload identity ile secret erişimi sınırlandırılabilir. Offline edge için güvenli cache modeli gerekir. Vault bu alanda kullanılan seçeneklerden biridir.

Vault

Vault secret issuance ve dynamic credential yönetimi sunabilir. Policy ile identity bazlı erişim uygulanır. Audit log erişimleri kaydeder. Edge bağlantı kesintileri için agent veya cache yaklaşımı değerlendirilebilir. Merkezi Vault erişilebilirliği kritik dependency olarak tasarlanmalıdır.

Observability

Observability metrics, logs ve traces verisini birleştirir. Edge cihaz sağlığı ve deployment davranışı görünür olur. Prometheus, Grafana ve OpenTelemetry bu katmanda kullanılabilir. Telemetry hacmi bağlantı kapasitesine göre optimize edilmelidir. Security event'leri de aynı context içinde incelenebilir.

Prometheus

Prometheus metric toplama ve sorgulama için yaygın çözümdür. Edge cluster'da local scraping yapılabilir. Merkezi sisteme remote write uygulanabilir. Bağlantı kesintisinde local retention gerekir. Cardinality kontrolü kaynak tüketimini azaltır.

Grafana

Grafana metric ve log verisini dashboard üzerinde sunabilir. Filo, lokasyon ve cihaz grubu görünümü oluşturulabilir. Security KPI'ları aynı panelde izlenebilir. Yetkilendirme ve dashboard erişimi korunmalıdır. Alert yönetimi operasyon sürecine bağlanabilir.

OpenTelemetry

OpenTelemetry metric, trace ve log telemetry için ortak standart yaklaşımı sunar. Uygulama bağımsız gözlemleme altyapısı kurulabilir. Collector edge üzerinde aggregation yapabilir. Sampling network yükünü azaltır. Merkezi backend seçimi ayrı mimari karardır.

Örnek Production-Ready Edge DevSecOps Akışı

Production-ready akış geliştiricinin pull request açmasıyla başlar ve runtime monitoring ile devam eder. Her aşama bir önceki aşamadan gelen artifact kimliğini korumalıdır. Security scan, SBOM, provenance, signing ve policy validation birbirine bağlı çalışmalıdır. Canary deployment sonrası sağlık ve güvenlik metrikleri normal kaldığında rollout büyütülür. Böylece hızlı teslimat ile kontrollü risk yönetimi aynı süreçte buluşur.

1. Developer Pull Request Açar

Değişiklik protected branch'e doğrudan gönderilmez. Pull request code review başlatır. İlgili CODEOWNERS otomatik atanabilir. Commit ve pipeline metadata kaydedilir. Security kontrolleri bu olayla tetiklenir.

2. SAST, SCA ve Secret Scan Çalışır

Kaynak kod ve dependency'ler otomatik taranır. Secret sızıntısı kontrol edilir. Kritik bulgu merge'i durdurabilir. Sonuç developer'a doğrudan gösterilir. Exception gerekiyorsa kayıtlı süreç kullanılır.

3. IaC ve Kubernetes Policy Testleri Yapılır

Terraform ve manifest dosyaları security policy'den geçer. Privileged workload veya açık network policy tespit edilebilir. Policy testleri CI içinde çalışır. Failure nedeni açık biçimde raporlanır. Başarılı kontrol build aşamasına geçiş sağlar.

4. Multi-Architecture Image Build Edilir

ARM ve x86 hedefleri için image üretilir. Dependency sürümleri pinlenir. Build ortamı ephemeral tutulur. Her architecture için test çalıştırılır. Çıktı digest değerleri kaydedilir.

5. Container Vulnerability Scan Yapılır

Build edilen image CVE açısından taranır. Severity yanında exploitability değerlendirilir. Kritik policy ihlali release'i durdurabilir. Sonuç build metadata ile ilişkilendirilir. Scanner database tarihi kayıt altına alınabilir.

6. SBOM Oluşturulur

Her image için SBOM üretilir. Artifact digest ile bağlanır. Standart format kullanılır. SBOM güvenilir registry veya metadata deposuna aktarılır. Release bu belge olmadan promotion alamayabilir.

7. Provenance Üretilir

Builder identity ve source commit provenance içine kaydedilir. Artifact'ın nerede üretildiği görünür olur. Metadata imzalanabilir. Deployment policy bu bilgiyi doğrulayabilir. Yetkisiz builder çıktısı reddedilir.

8. Artifact İmzalanır

Başarılı security gate sonrasında artifact imzalanır. Signing identity normal build credential'dan ayrılır. Digest üzerinde signature oluşturulur. Keyless model kullanılabilir. İmza registry metadata'sıyla birlikte saklanır.

9. Registry'ye Immutable Digest ile Push Edilir

Image güvenilir registry'ye gönderilir. Mutable tag yerine digest referansı kaydedilir. Production repository overwrite koruması kullanabilir. Registry audit log aktif tutulur. Push yetkisi yalnızca release job'a verilir.

10. GitOps Manifest'i Güncellenir

Manifest yeni image digest'ine güncellenir. Değişiklik pull request olarak açılabilir. Policy yeniden çalışır. Production approval uygulanır. Merge sonrası edge reconciliation başlar.

11. Admission Policy İmza ve Güvenlik Kontrolü Yapar

Cluster deployment öncesi artifact signature doğrular. Allowed registry policy kontrol edilir. Pod security ayarları değerlendirilir. Failure durumunda deployment reddedilir. Olay audit log'a yazılır.

12. Canary Edge Grubuna Deployment Yapılır

Yeni release küçük production grubuna gider. Farklı hardware ve lokasyon örnekleri seçilebilir. Deployment sonucu anlık izlenir. Sorun varsa rollout durdurulur. Stabilite süresi tamamlanınca sonraki aşamaya geçilir.

13. Health ve Security Metrikleri İzlenir

CPU, memory, error rate ve latency kontrol edilir. Runtime security alert sayısı izlenir. Network davranışı baseline ile karşılaştırılır. Threshold aşılırsa otomatik rollback yapılabilir. Sonuç deployment evidence olarak kaydedilir.

14. Rollout Kademeli Olarak Genişletilir

Canary başarılıysa cihaz yüzdesi artırılır. Deployment ring sırası korunur. Her aşamada metric kontrol edilir. Offline cihazlar daha sonra güvenli sürümü alır. Tam coverage raporu oluşturulur.

15. Runtime Security Sürekli İzlenir

Release tamamlandıktan sonra monitoring devam eder. Beklenmeyen process ve network davranışı izlenir. Yeni CVE yayınlandığında SBOM sorgulanır. Configuration drift tespit edilir. Böylece güvenlik yaşam döngüsü deployment sonrasında da sürer.

Edge DevSecOps Maturity Model

Olgunluk modeli kurumun mevcut durumunu görmesine ve bir sonraki yatırım adımını belirlemesine yardımcı olur. Her organizasyon doğrudan en yüksek seviyeden başlamak zorunda değildir. Önce tekrar üretilebilir build ve deployment kurulabilir, ardından security automation, GitOps, signing ve Zero Trust eklenebilir. Önemli olan her seviyede ölçülebilir kazanım elde etmektir. Tool sayısını artırmak yerine güvenlik ve operasyon sonucunu iyileştirmek hedeflenmelidir.

Seviye 0 — Manuel Edge Operasyonu

Cihazlar büyük ölçüde elle yönetilir. SSH ve manuel package update yaygındır. Merkezi inventory eksik olabilir. Configuration drift sık görülür. İlk hedef görünürlük ve standardizasyon olmalıdır.

Seviye 1 — Otomatik Build ve Deployment

CI pipeline standart artifact üretir. Deployment otomasyonu temel seviyede kurulur. Sürüm takibi iyileşir. Manuel hata azalır. Security scan henüz sınırlı olabilir.

Seviye 2 — Shift-Left Security

SAST, SCA ve secret scanning pipeline'a eklenir. IaC ve container scan yapılır. Developer erken geri bildirim alır. Kritik bulgu release'i durdurabilir. Security artık teslimat sürecinin parçasıdır.

Seviye 3 — GitOps ve Policy as Code

Desired state Git üzerinden yönetilir. Policy otomatik uygulanır. Drift tespiti etkinleşir. Manuel production değişikliği azalır. Edge filoları daha tutarlı hale gelir.

Seviye 4 — SBOM, Signing ve Provenance

Her artifact için SBOM üretilir. Image ve firmware imzalanır. Build provenance kaydedilir. Deployment bu kanıtları doğrular. Supply chain güveni önemli ölçüde güçlenir.

Seviye 5 — Zero Trust ve Runtime Enforcement

Device ve workload identity merkezi güvenlik modeline bağlanır. mTLS yaygınlaşır. Least privilege uygulanır. Runtime security davranışları izler. Policy ihlali production'da otomatik engellenebilir.

Seviye 6 — Otomatik Risk Tabanlı Remediation

Vulnerability verisi asset criticality ve exploitability ile birleştirilir. Sistem etkilenen cihaz grubunu otomatik belirler. Patch canary ring'e gönderilebilir. Metric başarısızsa rollout durur. İnsan onayı kritik karar noktalarında korunabilir.

Production'a Çıkmadan Önce Edge DevSecOps Kontrol Listesi

Production öncesi kontrol listesi teknik ekiplerin kritik güvenlik bileşenlerini atlamasını önler. Liste yalnızca bir kez doldurulacak belge değil release ve mimari review sürecinin yaşayan parçası olmalıdır. Her madde mümkünse otomatik kontrol veya doğrulanabilir evidence ile desteklenmelidir. Özellikle device identity, secure boot, signing, rollback ve incident response maddeleri saha ortamında doğrudan iş sürekliliğini etkiler. Aşağıdaki kontroller production hazırlığının pratik bir özeti olarak kullanılabilir.

Threat Model Oluşturuldu mu?

Varlıklar ve trust boundary'ler tanımlanmalıdır. Data flow görünür olmalıdır. Fiziksel saldırı senaryoları eklenmelidir. Pipeline ve supply chain dahil edilmelidir. Riskler önceliklendirilmelidir.

Secure Boot Aktif mi?

Cihaz yalnızca yetkili boot bileşenlerini çalıştırmalıdır. Firmware ve bootloader signature doğrulanmalıdır. Trust key yönetimi korunmalıdır. Update sonrası boot zinciri test edilmelidir. Manipüle edilmiş image reddedilmelidir.

Device Identity Var mı?

Her cihaz benzersiz kimliğe sahip olmalıdır. Shared credential kullanılmamalıdır. Private key mümkünse donanımda tutulmalıdır. Certificate rotation otomatik olmalıdır. Revocation prosedürü hazır olmalıdır.

Disk Encryption Var mı?

Yerel hassas veri şifrelenmelidir. Key güvenli saklanmalıdır. Recovery süreci test edilmelidir. Performance etkisi ölçülmelidir. Decommission sırasında key silinmelidir.

mTLS Kullanılıyor mu?

Edge ile cloud iletişimi karşılıklı doğrulanmalıdır. Service-to-service bağlantılarda da ihtiyaç değerlendirilmelidir. Certificate rotation otomatik olmalıdır. Expiry alert bulunmalıdır. Trust store yönetimi güvenli yapılmalıdır.

Default-Deny Network Politikası Var mı?

Tanımsız trafik varsayılan olarak engellenmelidir. Gerekli ingress ve egress açıkça izinli olmalıdır. NetworkPolicy veya firewall kullanılabilir. Policy test edilmelidir. Exception'lar kayıtlı olmalıdır.

CI Runner'lar İzole mi?

Runner production network'e sınırsız erişmemelidir. Ephemeral model tercih edilmelidir. Privileged build sınırlandırılmalıdır. Network egress kontrol edilmelidir. Runner image güncel tutulmalıdır.

Secrets Pipeline'da Güvenli mi?

Kalıcı key kullanımından kaçınılmalıdır. OIDC federation değerlendirilebilir. Secret loglarda görünmemelidir. Least-privilege role kullanılmalıdır. Rotation prosedürü otomatik olmalıdır.

SBOM Üretiliyor mu?

Her production artifact için SBOM bulunmalıdır. Digest ile ilişkilendirilmelidir. Format standart olmalıdır. Güvenilir depoda saklanmalıdır. CVE response gerçekten bu veriyi kullanmalıdır.

Artifact'lar İmzalanıyor mu?

Container ve firmware imzalanmalıdır. Signing identity korunmalıdır. Signature artifact digest üzerinde olmalıdır. Key rotation düşünülmelidir. Deployment sırasında doğrulama yapılmalıdır.

Provenance Oluşturuluyor mu?

Build source ve builder identity kaydedilmelidir. Artifact ile bağ kurulmalıdır. Güvenilir format kullanılmalıdır. Provenance imzalanabilir. Production policy verification yapmalıdır.

İmzasız Deployment Engelleniyor mu?

Admission veya deployment agent signature kontrolü yapmalıdır. İmzasız artifact reddedilmelidir. Unknown signer kabul edilmemelidir. Failure audit edilmelidir. Offline verification senaryosu test edilmelidir.

GitOps Repository Korunuyor mu?

MFA ve branch protection kullanılmalıdır. Production değişiklikleri review almalıdır. CODEOWNERS uygulanabilir. Direct push kapatılmalıdır. Repository access düzenli gözden geçirilmelidir.

Policy as Code Kullanılıyor mu?

Güvenlik kuralları version control altında olmalıdır. CI içinde test edilmelidir. Runtime enforcement bulunmalıdır. Policy exception kayıtlı olmalıdır. Edge cluster policy sürümü görünür olmalıdır.

Network Partition Test Edildi mi?

Cloud bağlantısı bilinçli olarak kesilmelidir. Local workload sürekliliği doğrulanmalıdır. Secret ve certificate davranışı izlenmelidir. Reconnect reconciliation test edilmelidir. Veri kaybı olmamalıdır.

OTA Rollback Test Edildi mi?

Başarısız update senaryosu bilinçli oluşturulmalıdır. Eski güvenli sürüme dönüş doğrulanmalıdır. Power loss sırasında test yapılmalıdır. Anti-rollback policy kontrol edilmelidir. Recovery partition denenmelidir.

Canary Deployment Var mı?

Yeni release önce küçük cihaz grubuna gitmelidir. Başarı metric'leri tanımlanmalıdır. Automatic stop ve rollback bulunmalıdır. Farklı hardware sınıfları canary içinde yer almalıdır. Rollout kademeli genişletilmelidir.

Runtime Security Kuruldu mu?

Process ve network davranışı izlenmelidir. Privilege escalation rule bulunmalıdır. Critical alert incident sistemine gitmelidir. Kaynak tüketimi ölçülmelidir. Rule set düzenli güncellenmelidir.

Offline Logging Test Edildi mi?

Bağlantı kesildiğinde log kaybolmamalıdır. Local buffer limiti doğrulanmalıdır. Security log önceliği test edilmelidir. Reconnect senkronizasyonu çalışmalıdır. Disk doluluk davranışı kontrol edilmelidir.

Incident Response Planı Hazır mı?

Quarantine ve revocation adımları tanımlanmalıdır. Sorumlu ekipler belli olmalıdır. Forensic toplama prosedürü bulunmalıdır. Re-provisioning yöntemi test edilmelidir. Tatbikat düzenli yapılmalıdır.

Sık Yapılan Edge DevSecOps Hataları

Edge projelerinde sorunların önemli bölümü teknolojiden çok yanlış varsayımlardan kaynaklanır. Cloud için çalışan pipeline'ı hiçbir değişiklik yapmadan edge'e taşımak bunların başında gelir. Sürekli internet, sınırsız kaynak ve fiziksel güvenlik varsayımları saha koşullarında hızla bozulabilir. Signing, rollback ve runtime security gibi katmanlar sonradan eklenecek özellikler olarak görülmemelidir. Başlangıçta doğru prensipler seçildiğinde operasyon maliyeti önemli ölçüde azalır.

Cloud CI/CD Pipeline'ını Değiştirmeden Edge'e Taşımak

Cloud pipeline sürekli bağlantı varsayabilir. Edge cihaz bu varsayımı karşılamayabilir. Artifact cache ve offline rollout gerekir. Hardware çeşitliliği test edilmelidir. Pipeline saha şartlarına göre uyarlanmalıdır.

Fiziksel Güvenliği Görmezden Gelmek

Edge cihaz data center içinde olmayabilir. Disk sökülebilir veya debug port kullanılabilir. Secure boot ve disk encryption gerekir. Tamper senaryosu threat model'e eklenmelidir. Credential revoke mekanizması hazır olmalıdır.

Cihazlara Kalıcı Credential Yerleştirmek

Kalıcı credential yıllarca aynı cihazda kalabilir. Sızıntının etkisi çok büyür. Unique device identity tercih edilmelidir. Short-lived credential kullanılmalıdır. Hardware-backed private key güçlü koruma sağlar.

İmzasız Firmware Dağıtmak

İmzasız firmware kaynağı doğrulanamaz. Saldırgan değiştirilmiş paket dağıtabilir. Cihaz update öncesi signature kontrolü yapmalıdır. Signing key korunmalıdır. Anti-rollback de eklenmelidir.

Container Tag'lerine Güvenmek

Tag mutable olabilir. Aynı tag farklı image içeriğine işaret edebilir. Production manifest digest kullanmalıdır. Signature digest üzerinden doğrulanmalıdır. GitOps repository exact artifact kimliğini saklamalıdır.

Yalnızca Vulnerability Scanner Kullanmayı DevSecOps Sanmak

Scanner yalnızca güvenlik araçlarından biridir. Identity, signing, policy ve runtime security de gereklidir. CVE listesi tek başına risk kararı değildir. Operasyon ve incident süreçleri birlikte düşünülmelidir. DevSecOps uçtan uca yaşam döngüsü yaklaşımıdır.

SBOM Üretip Hiç Kullanmamak

SBOM yalnızca compliance belgesi olarak kalmamalıdır. Yeni CVE çıktığında sorgulanmalıdır. Asset inventory ile eşleştirilmelidir. Remediation kararını hızlandırmalıdır. Coverage ve kullanım metriği birlikte izlenebilir.

İnternetin Her Zaman Çalışacağını Varsaymak

Edge bağlantısı kesilebilir. Secret, logging ve deployment tasarımı offline durumu desteklemelidir. Local cache gerekir. Reconnect sonrası state senkronizasyonu test edilmelidir. Network partition CI testlerine dahil edilmelidir.

Tüm Filoya Aynı Anda Güncelleme Göndermek

Tek hata bütün cihazları etkileyebilir. Deployment ring kullanılmalıdır. Canary grup gerçek production örneklerinden oluşmalıdır. Health metric rollout'u kontrol etmelidir. Sorun varsa otomatik stop uygulanmalıdır.

Rollback Mekanizması Tasarlamamak

Update her zaman başarılı olmayabilir. Uzak cihaz için fiziksel müdahale pahalıdır. A/B partition veya güvenilir recovery yöntemi gerekir. Rollback test edilmelidir. Vulnerable sürüme dönüş ayrıca engellenmelidir.

Edge Node'lara Manuel SSH ile Müdahale Etmek

Rutin SSH operasyonu configuration drift üretir. Değişiklikler kayıt dışı kalabilir. GitOps ve IaC tercih edilmelidir. Break-glass SSH geçici ve audit edilmiş olmalıdır. Son durumda cihaz desired state'e geri dönmelidir.

Runtime Security'yi İhmal Etmek

Pipeline bütün runtime saldırılarını yakalayamaz. Compromised credential production sonrasında kullanılabilir. Process ve network monitoring gerekir. Critical alert isolation sürecine bağlanmalıdır. Shift-left runtime güvenliğiyle tamamlanmalıdır.

Sık Sorulan Sorular

Edge güvenliği konusunda kurumların karşılaştığı sorular çoğunlukla kimlik, Kubernetes, offline çalışma, signing ve vulnerability management çevresinde toplanır. Teknik seçimler cihaz kapasitesi ve iş ihtiyacına göre değişebilir. Aşağıdaki yanıtlar mimari karar için temel bir çerçeve sunar. Daha ayrıntılı tasarım yapılırken gerçek cihaz, ağ ve deployment modeli mutlaka değerlendirilmelidir. Özellikle kritik saha sistemlerinde laboratuvar testi ile production pilotunun birlikte kullanılması faydalıdır.

Edge Computing'de DevSecOps nedir?

Edge DevSecOps güvenliği geliştirme, deployment ve cihaz yaşam döngüsüne dağıtan yaklaşımdır. CI/CD içinde security scanning bulunur. Artifact signing ve provenance kullanılır. Device ve workload identity runtime güvenliğini destekler. Monitoring ve incident response süreçle birlikte çalışır.

Edge ortamlarında DevSecOps neden gereklidir?

Edge cihazlar uzak ve fiziksel olarak erişilebilir olabilir. Network bağlantısı kesilebilir. Manuel güvenlik kontrolü büyük filolarda ölçeklenmez. Otomasyon güvenlik standardını tutarlı hale getirir. Erken kontrol riskin bütün filoya yayılmasını önler.

Edge Computing güvenli midir?

Edge Computing doğru tasarlandığında güçlü güvenlik seviyesine ulaşabilir. Ancak dağıtık yapı yeni riskler getirir. Device identity ve secure boot önemlidir. Network segmentation ve signing kullanılmalıdır. Güvenlik cihaz yaşam döngüsünün tamamında sürdürülmelidir.

Kubernetes edge ortamında kullanılabilir mi?

Evet, uygun donanım ve dağıtım seçimiyle kullanılabilir. Kaynak tüketimi ölçülmelidir. K3s gibi hafif seçenekler değerlendirilebilir. Offline çalışma davranışı test edilmelidir. Kubernetes güvenlik policy'leri production öncesi uygulanmalıdır.

K3s ile KubeEdge arasındaki fark nedir?

K3s hafif Kubernetes dağıtımı olarak genel cluster işletimine odaklanır. KubeEdge cloud-edge bağlantısı ve edge device senaryoları için farklı mimari sunar. Offline davranış ve control plane modeli farklı olabilir. Ekip deneyimi seçimde önemlidir. Karar gerçek saha testiyle verilmelidir.

Edge cihazlarda Zero Trust nasıl uygulanır?

Network konumu güvenilir kabul edilmez. Her cihaz benzersiz identity taşır. Workload ve servis kimliği ayrı yönetilir. mTLS ve least privilege uygulanır. Device posture sürekli doğrulanabilir.

Edge cihaz kimliği nasıl oluşturulur?

Cihaza benzersiz cryptographic identity verilmelidir. Private key TPM veya secure element içinde üretilebilir. X.509 certificate kullanılabilir. İlk provisioning güvenli bootstrap süreciyle yapılır. Rotation ve revocation yaşam döngüsüne dahil edilir.

Secure Boot nedir?

Secure Boot yalnızca güvenilir imzaya sahip boot bileşenlerinin çalışmasını sağlar. Firmware trust key üzerinden doğrulama yapar. Bootloader ve kernel zincir halinde kontrol edilebilir. Yetkisiz image boot edemez. Measured Boot ile birlikte kullanıldığında remote attestation güçlenir.

Edge cihazlarda secret nasıl yönetilir?

Secret Git veya container image içine konmamalıdır. Central secret manager tercih edilebilir. Short-lived credential kullanılabilir. Offline durum için encrypted local cache gerekebilir. Compromise durumunda revocation hızlı yapılmalıdır.

Air-gapped ortamda CI/CD nasıl çalışır?

Artifact'lar internet bağlantılı staging zone'da hazırlanabilir. Security scan ve signature doğrulaması yapılır. Air-gap bundle kontrollü şekilde iç ortama aktarılır. Local registry ve package repository kullanılır. Deployment agent bundle içeriğini tekrar doğrular.

İnternet bağlantısı olmayan edge cihazları nasıl güncellenir?

Update paketleri önceden hazırlanabilir. Local repository veya fiziksel kontrollü transfer kullanılabilir. Paket imzalı olmalıdır. Cihaz integrity verification yapmalıdır. Rollback mekanizması hazır tutulmalıdır.

OTA update nasıl güvenli hale getirilir?

Firmware ve metadata imzalanmalıdır. Update paketi install öncesi doğrulanmalıdır. Device health kontrolü yapılmalıdır. Canary rollout uygulanmalıdır. Başarısız update otomatik rollback ile geri alınmalıdır.

Firmware signing neden gereklidir?

Firmware signing paketin yetkili üreticiden geldiğini kanıtlamaya yardımcı olur. Manipüle edilmiş update reddedilir. Boot güven zinciri korunur. Signing key güçlü biçimde yönetilmelidir. Signature verification cihaz üzerinde zorunlu olmalıdır.

SBOM nedir ve edge ortamında neden önemlidir?

SBOM artifact içindeki software bileşenlerini listeler. Yeni CVE çıktığında etkilenen image ve firmware sürümleri bulunabilir. Asset inventory ile birlikte cihaz bazında sorgulama yapılır. Uzun yaşam döngülü edge cihazlarında görünürlük sağlar. Her build için otomatik üretim tercih edilmelidir.

SLSA nedir?

SLSA software supply chain güvenliği için yapılandırılmış güven seviyeleri ve kontroller sunan yaklaşımdır. Build provenance önemli bileşenidir. Artifact'ın hangi source ve builder üzerinden üretildiğini görünür hale getirir. Pipeline güvenliği güçlendirilir. Deployment yalnızca beklenen provenance'a sahip artifact kabul edebilir.

Container image nasıl imzalanır?

Image build sonrası digest üzerinden imzalanabilir. Cosign gibi araçlar kullanılabilir. Signing key veya keyless identity modeli seçilebilir. Signature registry yanında saklanabilir. Admission control deployment öncesi doğrulama yapmalıdır.

GitOps edge computing'de nasıl kullanılır?

Edge desired state Git repository'de tutulur. Agent değişiklikleri pull eder. Network bağlantısı kesildiğinde mevcut state devam eder. Reconnect sonrası reconciliation yapılır. Repository ve artifact signature güvenliği birlikte uygulanmalıdır.

Edge lokasyonlarında canary deployment nasıl yapılır?

Production cihazların küçük ve temsilî grubu seçilir. Yeni release önce bu gruba gider. Health ve security metric'leri belirli süre izlenir. Problem varsa rollout durdurulur. Başarılı sonuçta cihaz yüzdesi kademeli artırılır.

Edge ortamında vulnerability management nasıl yapılır?

Asset inventory ve SBOM temel görünürlük sağlar. Scanner yeni CVE'leri belirler. Exploitability, exposure ve business criticality ile risk sıralanır. Patch önce canary cihazlarda uygulanır. Coverage metric filo genelindeki durumu gösterir.

Edge cihaz ele geçirilirse ne yapılmalıdır?

Cihaz hızlı biçimde quarantine edilmelidir. Device certificate revoke edilmelidir. Gerekli forensic veriler toplanmalıdır. Paylaşılan credential varsa rotation yapılmalıdır. Güvenilir image ile re-provisioning sonrası tekrar attestation yapılmalıdır.

Sonuç: Güvenli ve Ölçeklenebilir Edge DevSecOps Mimarisi Nasıl Kurulur?

Güvenli edge mimarisi tek bir scanner, firewall veya Kubernetes ayarıyla kurulmaz. Donanım güveninden cihaz kimliğine, CI/CD pipeline'dan artifact signing'e, GitOps'tan runtime monitoring'e kadar birbirini tamamlayan kontroller gerekir. Edge Computing Mimarisinde DevSecOps Pratikleri uygulandığında amaç her cihazı tek tek yönetmek değil güvenli davranışı platformun varsayılanı haline getirmektir. Kesintili bağlantı, fiziksel erişim ve uzun cihaz yaşam döngüsü tasarımın normal koşulları olarak kabul edilmelidir. Kurumunuza uygun edge ve DevSecOps mimarisini değerlendirmek, eğitim veya danışmanlık ihtiyaçlarını konuşmak için https://www.diyarbakiryazilim.com.tr/about üzerinden Diyarbakır Yazılım Topluluğu hakkında bilgi alabilirsiniz.

Edge'i Küçük Bir Cloud Olarak Görmeyin

Edge farklı fiziksel ve network koşullarına sahiptir. Cloud varsayımlarını doğrudan taşımak risk yaratır. Offline çalışma birinci sınıf gereksinim olmalıdır. Kaynak sınırları security tooling seçiminde dikkate alınmalıdır. Saha koşulları test planına eklenmelidir.

Cihaz Kimliğini Güvenliğin Temeline Yerleştirin

Her cihaz benzersiz identity taşımalıdır. Shared secret kullanılmamalıdır. Hardware-backed private key güçlü temel sağlar. Certificate rotation otomatik olmalıdır. Compromise durumunda revocation hızlı çalışmalıdır.

Hardware'den Application'a Bir Trust Chain Oluşturun

Güven yalnızca application seviyesinde başlamamalıdır. Secure Boot firmware bütünlüğünü korur. Measured Boot attestation sinyali üretir. Signed artifact application katmanına kadar zinciri sürdürür. Runtime monitoring bu güveni çalışma süresinde kontrol eder.

Güvenliği CI/CD Pipeline'ın Her Aşamasına Dağıtın

Secret scan, SAST ve SCA erken aşamada çalışmalıdır. Build sonrası image scan yapılmalıdır. SBOM ve provenance üretilmelidir. Artifact signing promotion öncesi tamamlanmalıdır. Deployment policy son doğrulama katmanı olmalıdır.

Her Artifact'ın Kaynağını ve Bütünlüğünü Doğrulayın

Tag adı tek başına güven sağlamaz. Immutable digest kullanılmalıdır. Signature kaynağı doğrular. Provenance build sürecini görünür hale getirir. Edge yalnızca gerekli trust şartlarını sağlayan artifact'ı çalıştırmalıdır.

GitOps ile Declarative Fleet Management Kullanın

Desired state Git üzerinde yönetilebilir. Pull-based model edge ağları için uygundur. Drift otomatik tespit edilir. Manuel SSH ihtiyacı azalır. Repository güvenliği ve admission control birlikte korunmalıdır.

Kesintili Ağ Bağlantısını Normal Çalışma Koşulu Olarak Tasarlayın

Edge cihaz bağlantısını kaybedebilir. Workload temel görevini yerelde sürdürmelidir. Log ve telemetry buffer kullanılmalıdır. Secret expiry ve certificate rotation offline durumda test edilmelidir. Reconnect sonrası reconciliation güvenli biçimde yapılmalıdır.

OTA Güncellemelerini İmzalı, Kademeli ve Geri Alınabilir Yapın

Update paketi mutlaka imzalanmalıdır. Canary deployment kullanılmalıdır. Device health rollout kararını etkileyebilir. Automatic rollback başarısız release'i geri almalıdır. Anti-rollback eski ve güvensiz sürüme dönüşü engellemelidir.

Shift Left'i Runtime Security ile Tamamlayın

Pipeline erken güvenlik hatalarını yakalar. Ancak production davranışı farklı riskler oluşturabilir. Runtime process ve network monitoring gerekir. Critical alert incident response'a bağlanmalıdır. Güvenlik böylece source code'dan çalışma anına kadar devam eder.

DevSecOps'u Pipeline Değil Uçtan Uca Edge Cihaz Yaşam Döngüsü Olarak Yönetin

Gerçek DevSecOps üretim pipeline'ından daha geniştir. Manufacturing identity ile başlar. Provisioning, deployment, operation ve update boyunca devam eder. Incident ve decommission aşamaları aynı modelin parçalarıdır. Bu yaklaşım kurumsal edge platformunun yıllar boyunca güvenli ve yönetilebilir kalmasını sağlar.

Sık Sorulan Sorular

Aşağıdaki sorular özellikle Edge Computing ve DevSecOps entegrasyonu planlayan ekiplerin proje başlangıcında sık gündeme getirdiği konuları kapsar. Yanıtların her biri tek bir ürüne bağlı kalmadan uygulanabilir mimari prensiplere odaklanır. Gerçek üretim ortamında cihaz sayısı, bağlantı modeli, donanım gücü ve compliance ihtiyaçları kararları değiştirebilir. Bu nedenle teknik tasarımın temsilî edge cihazlarda test edilmesi önemlidir. Danışmanlık gerektiren projelerde ilk adım mevcut mimari ve tehdit modelinin birlikte değerlendirilmesidir.

Edge Computing mimarisinde DevSecOps pratikleri nasıl uygulanır?

Önce cihaz, network, workload ve software supply chain için tehdit modeli oluşturulur. Ardından CI/CD içine secret scan, SAST, SCA, IaC kontrolü, container scanning, SBOM, provenance ve signing eklenir. Deployment GitOps ve policy-as-code ile yönetilir. Production tarafında device identity, mTLS, runtime security ve observability sürekli çalışır. Böylece güvenlik tek bir aşamaya değil cihazın bütün yaşam döngüsüne dağıtılır.

Dağıtık edge cihazlarında CI/CD süreçleri güvenli ve ölçeklenebilir şekilde nasıl yönetilir?

Deployment doğrudan bütün filoya yapılmamalıdır. Cihazlar development, pilot, canary ve production ring'lerine ayrılabilir. Artifact immutable digest ve signature ile doğrulanır. GitOps agent'ları desired state'i pull ederek uygular ve offline kaldıklarında mevcut state'i korur. Merkezi fleet dashboard deployment coverage, failure ve rollback durumlarını görünür hale getirir.

Edge ortamlarında Zero Trust, kimlik doğrulama ve secrets management nasıl yapılandırılmalıdır?

Her cihaz, workload ve servis ayrı identity taşımalıdır. Network konumu güvenilir kabul edilmemelidir. mTLS, short-lived credential ve least privilege birlikte uygulanmalıdır. Secret'lar Git veya image içine gömülmemeli, merkezi manager veya güvenli local cache üzerinden verilmelidir. Cihaz ele geçirildiğinde certificate ve ilgili secret'ların hızlı biçimde revoke edilebilmesi gerekir.

Edge Computing sistemlerinde container güvenliği, zafiyet taraması ve sürekli izleme nasıl gerçekleştirilir?

Container image build sırasında vulnerability scan ve SBOM üretimi yapılmalıdır. Non-root, read-only filesystem ve minimum Linux capability gibi runtime ayarları policy ile zorunlu hale getirilebilir. İmzalı image admission aşamasında doğrulanmalıdır. Runtime security process, network ve privilege davranışını izlemelidir. Yeni CVE yayınlandığında SBOM ve asset inventory birlikte kullanılarak etkilenen edge cihazlar hızlı biçimde belirlenebilir.

Edge Computing ve DevSecOps entegrasyonu konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Edge Computing ve DevSecOps danışmanlığı yakınımda şeklinde araştırma yapan ekipler için yalnızca araç kurulumu sunan yaklaşım yerine mimari, güvenlik ve operasyon süreçlerini birlikte değerlendiren bir çalışma modeli daha değerlidir. Diyarbakır Yazılım Topluluğu'nun teknik çalışmaları ve topluluk yaklaşımı hakkında https://www.diyarbakiryazilim.com.tr/about üzerinden bilgi alınabilir. Gerçek proje örneklerini incelemek için https://www.diyarbakiryazilim.com.tr/projects adresi kullanılabilir. Edge CI/CD, container registry, Kubernetes, security automation ve yazılım teslimat süreçlerinin birlikte değerlendirilmesi daha sürdürülebilir bir altyapı kurulmasına yardımcı olur. İhtiyaç netleştirildiğinde mevcut edge mimarisinden production-ready DevSecOps modeline geçiş için aşamalı bir teknik yol haritası oluşturulabilir.