Shadow IT ile Mücadele: Altyapıda Gizli Çalışan Araçları Tespit ve Entegre Etme Rehberi
Modern bir yazılım organizasyonunda DevOps güvenliği genellikle CI/CD pipeline’larına konulan static analiz araçları veya prod ortamındaki WAF kurallarıyla sınırlı sanılır. Oysa asıl kanama, radarın altında gerçekleşir. Bir sabah Slack’ten gelen bir webhook bildiriminin AWS yerine rastgele bir Fly.io instance’ına gittiğini, ekibin logları incelemek için üçüncü parti, ücretsiz bir SaaS paneline IAM Access Key bastığını ya da geliştiricinin webhook test etmek için production pod’una ngrok kurduğunu fark edersiniz. Hoş geldiniz; Shadow IT dünyasındasınız. Bu makalede, kurumsal güvenlik standartlarını yerle bir etmeden, modern altyapı yönetimi dinamikleriyle bu kaçak yapıları nasıl avlayacağımızı ve platform mühendisliği sınırlarına nasıl çekeceğimizi konuşacağız.
Geliştirici Neden Shadow IT’ye Sığınır?
Kök nedene inmeden audit tool çalıştırmak, yalnızca semptomları bastırır. Bir kıdemli mühendisin ya da tech lead’in şirket politikalarını çiğneyip “kaçak” araç kurmasının tek bir temel sebebi vardır: Friction (Sürtünme).
Jira’da “S3 Bucket oluşturulması” için bilet açıp üç gün onay bekleyen bir geliştirici, deadline yaklaştığında işi çözmek için kişisel AWS hesabında bucket açar ve production koduna bu credential’ları gömer. VPN yapılandırması yüzünden yerel ortamında debug yapamayan adam, container’ın içine gizlice cloudflared sokar. Güvenlik ekiplerinin “hayır” dediği her senaryo, Shadow IT için verimli bir toprak yaratır. Çözüm, sadece engellemek değil; tespiti otomatize edip ardından o aracı “Paved Road” (onaylı ve otomasyonu yapılmış yol) standardına dönüştürmektir.
1. Rogue Tünellerin Tespiti: ngrok, cloudflared ve FRP
Geliştiricilerin ingress kısıtlamalarını aşmak için kullandığı en popüler yöntem reverse tunnel araçlarıdır. Uç noktalarda (developer makineleri veya staging pod’ları) bu araçları tespit etmek için osquery veya doğrudan eBPF tabanlı denetim mekanizmaları kurmalıyız.
Aşağıdaki osquery sorgusu, sistemde bilinen tünel istemcilerini ve bunların açık socket bağlantılarını anlık olarak yakalar:
SELECT p.pid, p.name, p.path, p.cmdline, pos.remote_address, pos.remote_port
FROM processes p
JOIN process_open_sockets pos ON p.pid = pos.pid
WHERE p.name IN ('ngrok', 'cloudflared', 'frpc', 'localtunnel')
OR p.cmdline LIKE '%tunnel%'
OR p.cmdline LIKE '%reverse%';Kubernetes cluster’ınızda bu tarz kaçak tünellerin container seviyesinde çalışmasını engellemek için runtime güvenliği (Falco) kurallarını devreye almanız gerekir. Falco kural setinize ekleyeceğiniz basit bir yaml bloğu, staging veya production pod’larında shell üzerinden rogue binary indirilip çalıştırıldığı an SIEM sisteminize alert düşürür:
- rule: Unauthorized Reverse Tunnel Tool Launched
desc: Detect rogue tunnel tools executed inside containers
condition: >
spawned_process and container and
(proc.name in (ngrok, cloudflared, frpc) or
proc.args contains "bore.pub" or
proc.args contains "telebit")
output: Rogue tunnel tool started (user=%user.name command=%proc.cmdline container_id=%container.id image=%container.image.repository)
priority: CRITICAL
tags: [container, network, shadow_it]2. Bulutta State Dışı Kaynak Avı: Drift ve Rogue Resource Tespiti
Terraform veya OpenTofu ile altyapı yönetiyorsanız, pipeline dışında AWS Management Console’dan veya gcloud CLI üzerinden elle açılan kaynaklar doğrudan Shadow IT sınıfına girer. Bu kaynaklar hem maliyet anomalisi yaratır hem de security group’ları genellikle 0.0.0.0/0 olarak bırakılır.
Bu durumu tespit etmenin en temiz yolu, Terraform state dosyası ile gerçek bulut durumunu düzenli olarak karşılaştıran drift-detection cronjob’larıdır. Ancak daha derin bir tarama için doğrudan CloudTrail logları üzerinden IaC role’ü dışındaki kimliklerin yarattığı kaynakları filtrelemelisiniz.
Aşağıdaki AWS CLI komutu, altyapı otomasyonu servis rolü (örneğin TerraformExecutionRole) haricinde bir kullanıcı veya rol tarafından son 24 saatte oluşturulmuş Security Group’ları doğrudan listeler:
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=CreateSecurityGroup \
--start-time "$(date -u -v-24H +%Y-%m-%dT%H:%M:%SZ)" \
--query 'Events[?Username!=`TerraformExecutionRole`].[EventTime, Username, CloudTrailEvent]' \
--output json | jq -r '.[] | {Time: .[0], User: .[1], Detail: (.[2] | fromjson)} | select(.Detail.userIdentity.sessionContext.sessionIssuer.userName != "TerraformExecutionRole")'Eğer bir developer AWS Console’a girip click-ops yöntemiyle bir EC2 veya RDS ayağa kaldırdıysa, CloudTrail ve CloudWatch Events üzerinde tetiklenecek bir Lambda fonksiyonu ile kaynağı etiketleyebilir (“non-compliant-shadow-it”), Slack kanalına bildirebilir veya otomatik olarak terminate edebilirsiniz.
3. Git Ekosisteminde Kaçak Webhook ve Entegrasyon Denetimi
Geliştiricilerin işlerini kolaylaştırmak amacıyla kişisel hesaplarını şirketin GitHub/GitLab organizasyonlarına bağlaması sık görülen bir sızıntı vektörüdür. Kod analizi yapan ücretsiz bir SaaS aracı, organizasyonunuza read/write yetkisiyle eklendiğinde tüm fikri mülkiyetiniz ve secret’larınız ilgili SaaS platformunun güvenliğine teslim edilmiş olur.
GitHub API kullanarak, organizasyon düzeyinde kurulmuş yetkisiz GitHub App’leri ve repository webhook’larını denetleyen bir scripti CI/CD süreçlerinizin başında düzenli çalıştırmalısınız:
# Organizasyondaki tüm repolarda bilinmeyen hedeflere giden webhookları listeleme
ORG="sirket-adiniz"
APPROVED_DOMAINS=("ci.sirket.internal" "slack.com" "argocd.sirket.internal")
gh repo list $ORG --limit 100 --json name -q '.[].name' | while read -r repo; do
hooks=$(gh api "repos/$ORG/$repo/hooks" --jq '.[].config.url')
for url in $hooks; do
domain=$(echo "$url" | awk -F[/:] '{print $4}')
if [[ ! " ${APPROVED_DOMAINS[@]} " =~ " ${domain} " ]]; then
echo "[ALERT] Repo: $repo üzerinde bilinmeyen webhook hedefi: $url"
fi
done
doneBu yaklaşımı GitLab tarafında Project Badges, Webhooks ve System Hooks API endpoint’lerini periyodik olarak scrape ederek uygulayabilirsiniz.
4. Egress Filtreleme ve DNS Log Analizi (CoreDNS)
Kubernetes cluster’ınızdaki container’ların nereye konuştuğunu bilmek zorundasınız. Çoğu Kubernetes kümesinde pod’lar varsayılan olarak tüm internete çıkış iznine (egress) sahiptir. İşte bu durum, Shadow SaaS kullanımını ve kaçak veri aktarımlarını tetikler.
Kubernetes içinde CoreDNS kullanıyorsanız, dnstap veya doğrudan log plugin’i ile dışarıya doğru yapılan DNS çözümlemelerini loglayıp bir SIEM (Elasticsearch, Loki vb.) üzerinde aggregate edebilirsiniz. Örnek bir Corefile konfigürasyonu:
.:53 {
errors
health
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
# Shadow IT tespiti için cluster dışına giden tüm istekleri logla
log . {
class denial error
dump
}
# Dış DNS isteklerini loglamak için özel format
rewrite name suffix .internal .cluster.local
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
reload
}Burada toplanan domain loglarında düzenli olarak notion.so, airtable.com, trello.com gibi araçlara pod içi credential’lar veya staging ortamından istek atılıp atılmadığı analiz edilmelidir. Eğer bir backend servisi bir günde aniden Pastebin veya Anonfiles API’larına sorgu atmaya başladıysa, ortada ya bir Shadow IT senaryosu ya da sızdırılmış bir secret ile veri kaçırma (exfiltration) vakası vardır.
Göz Yumma, Yasaklama: Entegre Et
Shadow IT’yi avlarken düşülen en büyük hata “Yasakçı Polis” rolünü benimsemektir. Geliştirici ekiple savaşamazsınız; geliştirici her zaman güvenlik duvarınızın etrafından dolaşacak daha yaratıcı bir yol bulur.
Kullanılan aracı yakaladığınızda uygulamanız gereken playbook şu adımlardan oluşmalıdır:
- İhtiyacı Anlayın: Bu servis neden kuruldu? Şirketin sunduğu Jenkins yetersiz olduğu için mi CircleCI’a gidildi? AWS SQS yerine Upstash Redis mi kullanılmış?
- Paved Road’a Alın: Aracın kurumsal sürümünü (SSO destekli, SCIM destekli, denetlenebilir) platforma entegre edin. Eğer güvenlik standartlarına uymuyorsa, kurum içi benzer bir self-service alternatifi sağlayın.
- Self-Service Altyapı Sunun: Backstage veya benzeri bir IDP (Internal Developer Platform) kurarak, geliştiricinin ihtiyaç duyduğu geçici ingress tünelini, dev database’ini veya S3 bucket’ını dakikalar içinde, standartlara uygun olarak kendi kendine deploy etmesini sağlayın.
DevOps’ta güvenlik, geliştiricinin hızını kesen bir bariyer değil; onların 200 km hızla giderken uçurumdan yuvarlanmasını engelleyen çelik bariyerler olmalıdır. Radarınızı açık tutun, telemetry verinizi dinleyin ve izin veremeyeceğiniz araçların yerine her zaman daha iyi bir mühendislik alternatifi koyun.