kertenkerem_
· DevOps · 5 dk okuma

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 çoğunlukla CI/CD pipeline’larına konan static analiz araçlarıyla ya da prod ortamındaki WAF kurallarıyla sınırlı sanılır. Oysa asıl kanama radarın altında olur. Bir sabah Slack’ten gelen bir webhook bildiriminin AWS yerine rastgele bir Fly.io instance’ına gittiğini fark edersiniz. Ya da ekibin logları incelemek için üçüncü parti, ücretsiz bir SaaS paneline IAM Access Key bastığını, geliştiricinin webhook test etmek için production pod’una ngrok kurduğunu. Bu, Shadow IT demektir. Bu yazıda kurumsal güvenlik standartlarını yerle bir etmeden bu kaçak yapıları nasıl avlayacağımızı ve platform mühendisliğinin 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. Kıdemli bir 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şınca 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 biri, 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 yalnızca engellemek değil, tespiti otomatize edip o aracı sonra “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 en sık başvurduğu yöntem reverse tunnel araçlarıdır. Uç noktalarda (developer makineleri veya staging pod’ları) bu araçları yakalamak için osquery ya da 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 tür 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 sayılır. Bu kaynaklar maliyet anomalisi yaratır, security group’ları da genellikle 0.0.0.0/0 olarak bırakılır.

Bunu tespit etmenin en temiz yolu, Terraform state dosyasıyla gerçek bulut durumunu düzenli karşılaştıran drift-detection cronjob’larıdır. Daha derin bir tarama için ise CloudTrail loglarından IaC role’ü dışındaki kimliklerin yarattığı kaynakları filtrelemelisiniz.

Aşağıdaki AWS CLI komutu, altyapı otomasyonu servis rolü (örneğin TerraformExecutionRole) dışındaki bir kullanıcı veya rolün son 24 saatte oluşturduğu Security Group’ları 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")'

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 fonksiyonuyla kaynağı etiketleyebilir (“non-compliant-shadow-it”), Slack kanalına bildirebilir ya da otomatik olarak terminate edebilirsiniz.

3. Git ekosisteminde kaçak webhook ve entegrasyon denetimi

Geliştiricilerin işlerini kolaylaştırmak için 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 o SaaS platformunun güvenliğine teslim edilmiş olur.

GitHub API ile 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
done

Aynı 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ın varsayılan olarak tüm internete çıkış izni (egress) vardır. Shadow SaaS kullanımını ve kaçak veri aktarımını tetikleyen de bu durumdur.

Kubernetes içinde CoreDNS kullanıyorsanız, dnstap ya da doğrudan log plugin’iyle dışarıya yapılan DNS çözümlemelerini loglayıp bir SIEM üzerinde (Elasticsearch, Loki vb.) 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’larla ya da staging ortamından istek atılıp atılmadığına bakılmalı. 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. Güvenlik duvarınızın etrafından dolaşacak daha yaratıcı bir yolu her zaman bulur.

Kullanılan aracı yakaladığınızda uygulayacağınız playbook şu adımlardan oluşmalı:

  • İ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. 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 ya da S3 bucket’ını dakikalar içinde, standartlara uygun biçimde kendi kendine deploy etmesini sağlayın.

DevOps’ta güvenlik, geliştiricinin hızını kesen bir bariyer olmamalı. 200 km hızla giderken uçurumdan yuvarlanmalarını engelleyen çelik bariyerler olmalı. 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.