DevOps Token Güvenliği ve MCP Riski

Token Kimliktir, Veri Sözleşmesi Değildir

DevOps otomasyonlarında tokenlar çoğu zaman iki amaçla kullanılır: kimlik doğrulamak ve sistemden bilgi çıkarmak. İkinci kullanım tehlikelidir. Token içindeki claim, format, uzunluk veya belirli alanlar uygulama mantığı için veri sözleşmesi gibi kullanılmaya başlandığında güvenlik kırılganlaşır.

Token bir API contract değildir. Token formatı değişebilir, claim seti farklılaşabilir, sağlayıcı yeni alan ekleyebilir veya bazı alanları kaldırabilir. Backend veya pipeline bu iç yapıya bağımlıysa kimlik sistemi teknik borca dönüşür.

DevOps'ta Token Riski Nerede Büyür?

DevOps sistemlerinde token genellikle yüksek yetki taşır:

Repo okuma/yazma
Pipeline tetikleme
Artifact indirme
Secret store erişimi
Cloud deploy
Issue veya PR yönetimi
Security alert triage

Bu tokenlar log, environment variable, local cache, MCP server config veya AI coding assistant context'i içine sızdığında saldırgan doğrudan yazılım tedarik zincirine yaklaşır.

MCP ve AI Araçlarıyla Yeni Yüzey

MCP server'ları, AI agent'ların DevOps araçlarıyla konuşmasını kolaylaştırır. Bu güçlüdür; fakat token yönetimi zayıfsa AI agent, geliştirici adına repo okuyabilir, issue kapatabilir, pipeline tetikleyebilir veya güvenlik uyarılarını değiştirebilir.

Buradaki risk yalnızca "token çalındı" değildir. AI agent'ın hangi aksiyonu neden yaptığı, hangi tokenla yaptığı ve bu tokenın hangi scope'lara sahip olduğu net değilse audit zayıflar. Agent hatalı karar verdiğinde veya prompt injection ile yönlendirildiğinde DevOps ortamı etkilenebilir.

Güvenli Token Tasarımı

Token formatına uygulama mantığı bağlamayın.
Scope'ları en küçük yetkiyle verin.
Uzun ömürlü PAT yerine kısa ömürlü federation kullanın.
Token kullanımını job, repo, environment ve actor bazında loglayın.
AI/MCP araçlarına verilen tokenları ayrı risk sınıfında yönetin.
Security alert ve policy değiştirme yetkilerini agent'lardan uzak tutun.
Token rotation ve revocation olaylarını test edin.

Eresus Yaklaşımı

Eresus Security, DevOps ve MCP güvenlik testlerinde token yaşam döngüsünü, scope tasarımını, agent yetkilerini ve audit izlerini birlikte değerlendirir. AI destekli DevOps hız getirir; fakat kimlik sınırları net değilse hız, üretime giden saldırı yolunu da kısaltır.

Saha Kontrol Notları

Bu başlık pratikte yalnızca teorik risk olarak ele alınmamalıdır. AI sistemlerinde zafiyetin etkisi, modelin bulunduğu ortam ve bağlı olduğu veri kaynaklarıyla birlikte değişir.

İnceleme sırasında şu kanıtlar toplanmalıdır:

Model veya agent hangi ortamda çalışıyor?
Hangi kullanıcı veya servis hesabı kullanılıyor?
Hassas veri kaynakları ayrı etiketlenmiş mi?
Model dosyası veya artefact kaynağı doğrulanmış mı?
Yükleme anında kod çalıştırma riski var mı?
Retrieval sonuçları kullanıcı yetkisine göre filtreleniyor mu?
Tool çağrıları ayrı loglanıyor mu?
Kritik aksiyonlarda onay mekanizması var mı?
Test ortamı production verisinden ayrılmış mı?
Olay halinde hangi loglardan geri dönüş yapılacak?

Uygulama Kontrol Listesi

Güvenilmeyen model dosyaları izole ortamda açılmalı.
Model registry erişimi minimum yetkiyle çalışmalı.
Hash, imza veya provenance bilgisi tutulmalı.
Agent tool izinleri görev bazlı ayrılmalı.
Memory ve retrieval kaynakları ayrı güven sınırı olarak ele alınmalı.
Prompt testleri runtime aksiyon testleriyle desteklenmeli.
Her bulgu iş etkisiyle birlikte raporlanmalı.

Karar Noktası

Bu risk müşteri verisine, üretim API’sine, geliştirici ortamına veya model yükleme hattına dokunuyorsa bekletilmemelidir. Eresus Security bu tip incelemelerde dosya, runtime, tool ve veri sınırını birlikte test ederek gerçek saldırı yolunu kanıtlar.

Operasyonel İnceleme Checklisti

Model veya agent kaynağı doğrulandı mı?
Tool izinleri minimum yetkiyle mi tanımlandı?
Retrieval sonucu kullanıcı yetkisine göre filtreleniyor mu?
Memory kalıcı talimat riskine karşı incelendi mi?
Model artefact hash veya imza ile takip ediliyor mu?
Yükleme işlemi sandbox içinde test edildi mi?
Prompt testi runtime aksiyon testiyle desteklendi mi?
MCP veya plugin server listesi çıkarıldı mı?
Agent production API çağırıyorsa onay var mı?
Veri sızıntısı senaryosu kontrollü denendi mi?
Kapsam net yazıldı mı?
Etkilenen varlık sahibi belli mi?
Test ortamı production etkisinden ayrıldı mı?
Kullanıcı rolleri doğru temsil ediliyor mu?
Hassas veri sınıfı tanımlandı mı?
Yetki sınırı teknik olarak doğrulandı mı?
Log kaynağı ve saklama süresi belli mi?
Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
İş etkisi teknik etkiden ayrı açıklandı mı?
Düzeltme sahibi belirlendi mi?
Retest kriteri yazıldı mı?
Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
Monitoring veya alert tarafında görünürlük var mı?
Olay müdahale adımı gerekiyorsa planlandı mı?
Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?