Shadow IT (Gölge BT) Nedir? Riskleri ve Tespiti

Shadow IT (Gölge BT), bir kurumda BT biriminin bilgisi ve onayı dışında kullanılan uygulama, cihaz ve bulut hizmetlerinin tamamıdır. Kişisel WhatsApp üzerinden yürüyen iş yazışması, şirket dosyasının kişisel bir bulut hesabına atılması, bir ekibin kendi kartıyla aldığı proje takip aracı: üçü de gölge BT’dir. Ortak özellikleri yasak olmaları değil, kimsenin listesinde bulunmamalarıdır.

Eski bir binanın elektrik tesisatını düşünün. Panoda her hattın bir sigortası ve bir etiketi vardır, projede her kablonun nereye gittiği yazılıdır. Sonra bir dairede priz yetmez. Ev sahibi tesisatçı çağırıp yeni hat çektirmek yerine bir kabloyu tavandan komşu odaya uzatır. Kablo çalışır, kimse rahatsız olmaz, faturası bile ödenir. Yalnız o hattın panoda sigortası yoktur, projede izi yoktur, yük hesabında yeri yoktur. Bina yıllarca böyle yaşar. Sorun çıktığı gün ise iki şey aynı anda ortaya çıkar: koruma devrede değildir ve kimse o kablonun nereden geçtiğini bilmemektedir.

Bu yazı boyunca panoyu, projeyi ve o plan dışı kabloyu birlikte takip edeceğiz. Konu BT Danışmanlık hizmetimizin risk tespiti koluna girer, çünkü gölge BT bir disiplin sorunu olmadan önce bir görünürlük sorunudur. Amacımız çalışanları suçlayan bir liste çıkarmak değil; kurumunuzda hangi hatların panodan geçmediğini bulmanızı sağlayacak bir yöntem bırakmak. Doğrudan o yöntemle başlamak isterseniz gölge BT nasıl bulunur bölümüne geçebilirsiniz.

Shadow IT (Gölge BT) Nedir?

Gölge BT, teknik bir arıza türü değil bir kayıt boşluğudur. Bir araç, kötü olduğu için gölge BT sayılmaz; kurumun varlık kaydında bulunmadığı için sayılır. Bu ayrım ince görünür ama her şeyi belirler: aynı uygulama bir kurumda gölge BT iken, envantere girip sorumlusu yazıldığı anda gölge olmaktan çıkar. Araç değişmez, kayıt değişir.

İngiltere’nin ulusal siber güvenlik merkezi NCSC, gölge BT rehberinde terimi “kurum içinde iş amacıyla kullanılan, bilinmeyen varlıklar” diye tanımlıyor ve aynı olguyu grey IT adıyla da andığını söylüyor. Tanımın ağırlık merkezine dikkat edin: cümlede “yasak” ya da “kötüye kullanım” geçmiyor, geçen kelime bilinmeyen.

Tanımın İşe Yarayan Hâli: Sayaçta Görünmeyen Yük

Sahada işe yarayan tanım tek soruya iner: bu araç bugün ortadan kalksa, kaybolduğunu kim fark eder ve nereye bakarak fark eder? Cevap “kullanan kişi fark eder, başka kimse” ise elinizde gölge BT vardır. Cevap “envanterde görünür, sorumlusu bellidir, kesintisi bir yere düşer” ise araç ne kadar küçük olursa olsun gölgede değildir.

Bu soru, konuşmayı ahlaktan çıkarıp envantere taşıdığı için değerlidir. “Çalışanlarımız kural dışı araç kullanıyor mu?” sorusunun cevabı savunmacıdır ve genellikle eksik alınır. “Bu iş şu anda hangi araçla yapılıyor?” sorusunun cevabı ise bir listedir ve liste tartışılabilir.

Elektrik tarafındaki karşılığı da tam olarak budur. Bir binada kaç hat olduğunu panodaki sigortalar söyler; gerçekte kaç hat olduğunu ise ancak duvarları tarayarak öğrenirsiniz. Aradaki fark, binanın gölge tesisatıdır.

Gölge BT ile Yasak Yazılım Aynı Şey Değildir

Kurumlarda en sık karışan iki kavram bunlardır ve karışması müdahaleyi baştan yanlış kurar. Yasak yazılım bir kural ihlalidir, gölge BT bir görünürlük eksiğidir. Lisanssız kurulan bir program ikisi birdendir; ama ekibin işini görmek için kullandığı ücretsiz bir not uygulaması yalnızca ikincisidir, çünkü ortada çiğnenen bir kural yoktur.

Ayrımın pratik sonucu şu: gölge BT’ye disiplin süreciyle yaklaşan kurum, çalışanı savunmaya geçirir ve elindeki en iyi keşif kaynağını kaybeder. Hangi aracın neden kullanıldığını en iyi bilen kişi onu kullanandır. O kişi soruyu bir soruşturma olarak duyduğu anda cevap vermeyi bırakır.

Burada bir kopma noktasını erken söylemek gerekiyor, çünkü elektrik benzetmesi tam da bu noktada yalan söylemeye başlar. Kaçak çekilen bir hat teknik olarak her zaman yanlıştır: kesiti hesaplanmamıştır, koruması yoktur, standarda aykırıdır. Gölge BT’de ise kullanılan araç çoğu zaman kurumun sunduğundan daha iyidir. Sorun aracın kalitesi değildir; sorun, kurumun onu görmüyor olmasıdır. Benzetmeyi taşıyan şey kablonun kötülüğü değil, panoda kaydının bulunmamasıdır.

Gölge BT Neden Doğar? Yasak Delme Değil, Kestirme

Gölge BT, kurala karşı çıkma isteğinden değil işi bitirme isteğinden doğar. NCSC’nin rehberi de aynı yeri işaret ediyor ve sebepleri sıralarken kötü niyeti hiç saymıyor: yeterli depolama alanının bulunmaması, veriyi üçüncü taraflarla paylaşamamak, ihtiyaç duyulan hizmete erişememek ve onaylı araçların işi görmemesi.

Dördünün ortak paydası tek cümleye iner: resmî kanal, işin gerektirdiği hızda cevap vermiyordur. Priz yetmediği için kablo uzatılır.

Resmî Kanalın Süresi, Plan Dışı Hattın Sebebidir

Bir aracın onay süreci iki hafta sürüyorsa ve iş üç gün içinde teslim edilecekse, çalışanın önünde iki seçenek vardır: işi geciktirmek ya da kendi çözümünü kurmak. Kurumların çoğu birinci seçeneği ödüllendirmez. Teslim tarihine yetiştiren kişi takdir alır, süreci beklediği için geciken kişi açıklama yapar. Bu tabloda gölge BT bir sapma değil, kurumun kendi teşvik yapısının beklenen sonucudur.

Bunu görmenin en hızlı yolu, süreci tersinden ölçmektir. Kurumunuzda yeni bir yazılım talebinin karara bağlanması ortalama ne kadar sürüyor? Bu sayıyı bilmiyorsanız, gölge BT’nin sebebini de bilmiyorsunuz demektir.

Onaylı Araç Var Ama İşi Görmüyorsa

İkinci sebep daha sinsidir, çünkü kurum bu durumda ihtiyacı karşıladığını sanır. Onaylı bir dosya paylaşım aracı vardır, ama dışarıdan gelen tedarikçi ona erişemez. Onaylı bir mesajlaşma uygulaması vardır, ama sahadaki ekip telefonunda onu kullanamaz. Kurum listede bir çözüm görür; çalışan sahada bir engel görür.

Bu ikisi arasındaki boşluk, gölge BT’nin en verimli üreme alanıdır. Ve envanterde hiç görünmez, çünkü kurum “bizde zaten şu araç var” cevabıyla soruyu kapatır.

Peki bu araçlar yıllarca nasıl görünmeden kalabiliyor? Cevap, gölge BT’nin hiçbir alarm üretmemesinde yatıyor. Bozulan bir sunucu kendini haber verir, dolan bir disk uyarı basar. Çalışan bir gölge araç ise tam tersini yapar: işi görür, kimseyi rahatsız etmez, destek talebi doğurmaz. Kurumun onu fark edeceği tek an, bir şeyin ters gittiği andır.

Gölge BT’nin Riskleri: Çalışan Bir Sistem Neden Sorun Olur?

Buraya kadar gölge BT’nin iyi niyetten doğduğunu ve çoğu zaman işi gördüğünü söyledik. Çalışıyor olması riski ortadan kaldırmaz, yalnız erteler. Plan dışı kablo da çalışır; sorun, üstünden geçen yükün hiçbir hesaba girmemesidir.

Riskler dört başlıkta toplanır ve dördünün de ortak sebebi aynıdır: kurumun koruma mekanizmaları, varlığını bilmediği bir sisteme uygulanamaz.

Verinin Nerede Durduğunu Bilmiyorsanız Koruyamazsınız

Gölge BT’nin en pahalı sonucu veri tarafındadır, çünkü burada hata geri alınamaz. Kurumun kişisel veri içeren bir dosyası, kurumun sözleşmesi olmayan bir hizmette, kurumun bilmediği bir ülkedeki sunucuda durabilir. Bu tabloda ihlal bildirimi yapmak bir yana, ihlalin olup olmadığını tespit etmek bile mümkün değildir.

KVKK açısından mesele nettir ve çalışanın iyi niyetiyle ilgili değildir: veri sorumlusu sıfatı kurumda kalır. Yani kurum, varlığını bilmediği bir sistemde işlenen veriden de sorumludur. Teknik tedbirlerin nasıl kurulacağını KVKK teknik uyum yazımızda ayrıca ele alıyoruz; buradaki mesele daha dar, o tedbirlerin hangi sistemlere uygulanacağının bilinmesi.

Güvenlik Kontrolleri Devreye Girmiyor

Kurumun güvenlik yatırımları belirli yollara kurulur. Kimlik doğrulama dizinden geçer, dosya trafiği güvenlik duvarından akar, oturumlar loglanır. Gölge BT bu yolların hiçbirinden geçmediği için, kuruma pahalıya mal olan kontrollerin tamamı o araç için yok hükmündedir.

Somut karşılığı şudur: kurumun parola politikası oradaki hesap için geçerli değildir, çok faktörlü doğrulama zorunlu değildir, bir kimlik ele geçirildiğinde bunu gösterecek log kaydı hiçbir yerde tutulmaz.

Kaybın büyüklüğünü görmek için tek bir soru yeterli: geçen ay hangi kullanıcı hangi dosyayı indirdi? Kurumsal bir sistemde bu sorunun cevabı bir kayıt sorgusudur. Gölge bir araçta cevabı yoktur, çünkü kayıt kurumun elinde değil aracın sahibindedir ve kurumun o firmayla bir sözleşmesi de yoktur. Bir ihlal şüphesinde ilk kaybedilen şey veri değil, cevap verebilme yeteneğidir. Loglamanın kurumsal tarafını 5651 log yönetimi yazısında anlatıyoruz. Gölge BT’nin buradaki özel zorluğu, kaydın eksik olması değil, hangi kaydın eksik olduğunun bilinmemesidir.

Görünmeyen Gider: Aynı İş İçin Üç Kez Ödemek

Üçüncü riskin diğerlerinden bir farkı var: bu, bir yerde iz bırakır. Finansal tarafta gölge BT görünmez kalmaz, çünkü ödeme her hâlükârda bir kayda düşer. Aynı işi yapan üç ayrı abonelik, üç ayrı ekip tarafından, üç ayrı kartla alınır. Hiçbiri kurumsal indirimden faydalanmaz, hiçbiri sözleşme pazarlığından geçmez ve toplamı tek bir kalem olarak hiçbir bütçede görünmez.

Buradaki asıl kayıp para değildir. Kurum aynı ihtiyaç için üç kez ödeme yapıyorsa, o ihtiyacın var olduğunu üç yıldır bilmiyor demektir.

Kişi Ayrılınca Hesap da Gidiyor

Dördüncü risk, gölge BT’yi kardeş konusuna bağlar. Gölge bir aracın hesabı genellikle kişiseldir: kurumsal olmayan bir e-posta adresine kayıtlıdır, parolası kimseyle paylaşılmamıştır, faturası kişinin kendi kartındadır. O kişi kurumdan ayrıldığında araç durmaz, ama kurumun ona erişimi durur.

Bu, klasik bir tek nokta arızasıdır: yerine geçecek ikinci bir yol yoktur ve eksikliği ancak kişi gittiğinde anlaşılır. Farkı şu ki, buradaki tek nokta envanterde hiç görünmez. Yedeklilik tartışması bile yapılamaz, çünkü tartışılacak varlığın kaydı yoktur.

Somut hâli çıkış gününde ortaya çıkar. Kurum ayrılan çalışanın dizin hesabını kapatır, e-postasını yönlendirir, cihazını teslim alır. Bunların hiçbiri gölge araca dokunmaz: oradaki hesap kurumsal dizine bağlı olmadığı için kapanmaz, parolası kimsede olmadığı için açılmaz, kurtarma adresi kişinin kendi e-postası olduğu için sıfırlanamaz. Ödeme kişisel bir karttan çekiliyorsa iki sonuçtan biri gelir: ya kurum kullanmadığı bir hizmete aylarca ödeme yapar, ya da ödeme durur ve veri sessizce silinir. Çıkış kontrol listesi ancak bildiğiniz sistemleri kapsayabilir.

Gölge BT’nin Aileleri: Shadow AI, Shadow Admin ve Shadow Data

Risklerin dördü de aynı kökten çıkıyordu: kurumun görmediği bir yerde iş yapılıyor. Bu kök tek bir araç türüne bağlı kalmadı. Son yıllarda aynı boşluk yeni alanlara yayıldı ve her biri kendi adıyla anılır oldu. Aşağıdakiler ayrı sorunlar değil, gölge BT’nin aynı mekanizmayla büyümüş kollarıdır.

Shadow AI: Ailenin En Hızlı Büyüyen Kolu

Shadow AI, kurumun onaylamadığı yapay zekâ araçlarının işte kullanılmasıdır ve gölge BT’nin bugün en hızlı yayılan biçimidir. Yayılma hızının sebebi teknik değil pratiktir: bu araçların çoğu tarayıcıdan açılır, kurulum gerektirmez, ücretsiz bir sürümü vardır ve tek kişilik bir kararla kullanılmaya başlanır. Yani BT’nin fark edebileceği hiçbir iz bırakmadan girer.

Riskin şekli de klasik gölge BT’den biraz farklıdır. Buradaki mesele çoğunlukla bir hesabın ele geçirilmesi değil, veriyi kendi elinizle dışarı vermenizdir: bir sözleşme metni, bir müşteri listesi ya da bir kaynak kod parçası, özetlensin diye kurum dışına çıkarılır. Çıkan veri geri alınamaz.

Bu kol kendi başına ayrı bir yazıyı hak ediyor ve buradaki bölüm onun yerine geçmez. Şimdilik kurulması gereken bağ şudur: Shadow AI yeni bir sorun sınıfı değil, envanteri tutulmayan araç sorununun yeni ve hızlı bir örneğidir. Çözümü de yeni bir çözüm değildir.

Vibe Coding: Artık Araç Aramaya da Gerek Kalmadı

Shadow AI’ın en yeni hâli, hazır bir araç kullanmak değil kendi aracını ürettirmektir. Kod yazmayı hiç bilmeyen bir çalışan, ihtiyacını gündelik dille anlatarak bir yapay zekâ aracına program yazdırabiliyor; sahada bu pratiğe vibe coding deniyor. Sonuç çoğu zaman gerçekten çalışıyor ve mesele tam da bu yüzden doğuyor.

Bu, gölge BT’nin doğasını değiştiren bir kırılma. Klasik gölge BT’de kurumun bilmediği bir araç vardı, ama o araç var olan bir üründü: arkasında bir firma, bir sözleşme, bir sürüm geçmişi, hatta bir güvenlik sicili bulunuyordu. Vibe coding’de bunların hiçbiri yok. Ortada dün akşam doğmuş, tek kişinin ürettiği, hiç kimsenin gözden geçirmediği bir kod var ve o kod kurumun verisine bağlanmak istiyor.

Reddin arkasında dört ayrı gerekçe vardı ve dördü de farklı bir ekseni tutuyor:

1. Uyum devralınmaz. Program, verileri kurumun KVKK’ya uygun platformundan alıyordu. Platformun uygun olması, onun verisini işleyen ikinci bir yazılımı uygun yapmaz; kullanıma açılması istenen program o gözle hiç yazılmamıştı.
2. Geliştirilebilir bir ürün değildi. Amatör ellerde vibe coding ile üretilmiş kod, kurumun ihtiyacını karşılayacak bir varlık olarak envantere alınmaz. Bugün işi çözse bile geliştirme süreci bir yerde mutlaka kilitlenir. Bugünün asıl sorunu proje çıkarmak değil, onu sürdürmektir.
3. İçinde ne olduğunu bilmiyorduk. Kodun içinde tuş kaydedici gibi zararlı bir davranış olabilirdi. Bu kötü niyetten de doğabilir, bir yanlışlıktan da; ayırt edecek bir inceleme yapılmadığı sürece ikisi aynı riski taşır. Büyük kurumlarda bu tür bir yazılımın topluca dağıtılmamasının başlıca sebebi budur.
4. Aynı işi yapan bir kanal zaten vardı. Holdingin bütün yazılım işlerini yürüten ayrı bir şirketi vardı ve o şirket ISO 27001, KVKK ve 5651 dahil tüm yükümlülüklere göre çalışıyordu. O sürecin vibe coding’den yavaş olmasının sebebi beceriksizlik değil, sürecin kendisidir: gelecekte de gelişebilecek bir ürün çıkarmak, sertifikasyon, güvenlik sıkılaştırması, test, sürüm notu, ekip görüşmesi. Bir ürünü hızlı çıkarmak tek ölçüt olsaydı o ekip çoktan uzaya çıkardı; mesele maratonu hızlı bitirip sakatlanmak değil, sağlıklı bitirmektir.

Dördüncü gerekçe aynı zamanda bu bölümün asıl dersini taşıyor: reddi işe yarar kılan şey reddin kendisi değil, gösterilecek bir kanalın var olmasıydı. O kanal olmasaydı program yine yazılırdı, yalnız bu kez kimseye sorulmadan.

Shadow Admin: Grupta Görünmeyen Yetki

Shadow Admin, ayrıcalıklı bir gruba üye olmadığı hâlde pratikte yönetici yetkisi taşıyan hesaptır. Yetki, grup üyeliğiyle değil doğrudan nesne üzerindeki izinlerle verilmiştir; bu yüzden “yöneticiler kimler?” diye sorulduğunda listede görünmez.

Mekanizması şudur: bir kullanıcıya bir klasör, bir bilgisayar nesnesi ya da bir dizin bölümü üzerinde izinleri değiştirme hakkı verilir. O hak verildiği anda kişi, kendisine istediği erişimi yazabilecek duruma gelir. Yani yetkinin kendisi devredilmemiştir, yetkiyi değiştirme yetkisi devredilmiştir ve ikisi pratikte aynı kapıya çıkar.

Bu, gölge BT ailesinin denetimi en zor üyesidir, çünkü keşfi bir yazılım listesinden değil izin taramasından geçer. Yetki modelinin doğru kurulmasını Active Directory kullanıcı, grup ve OU yönetimi yazısında, ayrıcalıklı hesapların sıkılaştırılmasını ise Active Directory güvenlik sıkılaştırması yazısında ele alıyoruz.

Shadow Data ve Shadow API

Shadow Data, kurumun envanterinde durmayan veri kopyalarıdır: test için alınmış bir veritabanı yedeği, birinin masaüstündeki dışa aktarılmış müşteri listesi, kapatılmış bir projeden kalan paylaşım klasörü. Bunların ortak özelliği, üretim sistemi kadar hassas veri taşıyıp üretim sistemi kadar korunmamalarıdır. Sonuç şu cümlede özetlenir: saldırı yüzeyi envanterden büyüktür.

Shadow API, belgelenmemiş ve yönetilmeyen uç noktalardır. Bir entegrasyon için açılmış, işi bitince kapatılmamış, dokümantasyona hiç girmemiş bir arayüz kurumun dış duvarında açık bir kapı olarak kalır. Kapının varlığını bilmeyen bir ekip, o kapıyı kilitleyip kilitlemediğini de bilemez.

İkisinin doğuş anı da aynıdır ve bu, önlemin nereye konacağını söyler: geçici olduğu düşünülen bir iş. Test için alınan yedek birkaç güne silinecektir, entegrasyon için açılan uç nokta proje bitince kapatılacaktır. İş biter, kararı veren kişi başka bir işe geçer ve geçici olan kalıcı olur. Bu yüzden en etkili önlem teknik değil usuldür: bir kopya ya da uç nokta oluşturulurken ne zaman silineceğinin de aynı anda yazılması. Tarihi olmayan geçici kayıt, kalıcı kayıttır.

Aynı Kelime, Başka Anlam: Gölgelenen Kural ve Volume Shadow Copy

Şimdiye kadar “gölge” kelimesini tek bir anlamda kullandık: onaysız ve görünmeyen. Terimin BT’de iki anlamı daha var ve ikisinin de bu yazıyla ilgisi yok. Karıştırılmaları sık, sonucu da pahalı: bir yönetici, tamamen meşru bir mekanizmayı güvenlik açığı sanabilir ya da gerçek bir yapılandırma hatasını isim benzerliği yüzünden gölge BT sorunu diye raporlayabilir.

Ayrımı taşıyan cümle şu: birinci anlamda gölgede olan varlığın kendisidir, ikinci anlamda ise varlık ortadadır ama önüne başka bir şey geçmiştir.

Gölgelenen Kural (Shadowed Rule): Erişilemeyen Satır

Güvenlik duvarında gölgelenen kural, üstünde duran daha genel bir kural aynı trafiği zaten yakaladığı için hiçbir zaman eşleşemeyen kuraldır. Kural listede durur, yazılmıştır, doğru görünür; ama sıralama yüzünden sıra ona hiç gelmez.

Terimin belgesizlikle ilgisi yoktur. Açıklaması özenle yazılmış bir kural da gölgelenmiş olabilir, hiç açıklaması olmayan bir kural da gayet iyi çalışıyor olabilir. Belirleyici olan tek şey sıralamadır. Aynı mekanizmanın grup ilkelerindeki karşılığını Active Directory GPO yönetimi yazısında, dizin tarafındaki karşılığını ise Active Directory DNS yapılandırması yazısında bulabilirsiniz: üçünde de daha spesifik olan, daha genel olanı geçersiz kılar.

Yıllar içinde birikmiş kural yığınının gerçek bir kurumda nasıl temizlendiğini firewall güvenlik sıkılaştırma vakamızda anlatıyoruz. Oradaki asıl zorluk kuralları bulmak değildi; kuralı yazan kişi kurumdan ayrıldığı için “bunu silersek ne bozulur?” sorusunun cevabının kalmamasıydı.

Volume Shadow Copy: Gölge Ama Sorun Değil

Windows tarafındaki Volume Shadow Copy (VSS), bir diskin belirli bir andaki tutarlı kopyasını çıkaran mekanizmadır. Buradaki “shadow” kelimesi olumsuz bir şey anlatmaz; kasıtlı ve meşru bir kopya anlatır. Yedekleme yazılımlarının açık dosyaları yedekleyebilmesi bu mekanizma sayesinde mümkün olur.

Adındaki gölge de tam olarak nasıl çalıştığından geliyor. Bir yedekleme başladığında disk durmaz, kullanıcılar yazmaya devam eder; VSS bu sırada değişen blokların eski hâlini ayrı bir alana kopyalar ve yedekleme yazılımına yalnızca o ana ait tutarlı bir görüntü sunar. Yani asıl diskin yanında, o anı temsil eden ikinci bir okuma yüzeyi belirir. Kullanıcıların bir dosyaya sağ tıklayıp Previous Versions sekmesinden eski sürüme dönebilmesi de aynı mekanizmanın ürünüdür.

Ayrımı bir cümlede tutmak isterseniz: gölge BT kurumun bilmediği bir şeydir, Volume Shadow Copy ise kurumun kurduğu bir şeydir. Dosya sunucusu tarafındaki kullanımını Windows Server rolleri yazısında ele aldık.

Job Shadowing: Aynı Kelime, Başka Alan

Sonuncusu BT’ye bile ait değildir. Job shadowing, bir çalışanın işi öğrenmek için bir başkasının yanında gün geçirmesidir; insan kaynaklarının işbaşı eğitim yöntemidir. Terimin bu yazıyla tek ortak noktası kelimenin kendisidir.

Buna değinmemizin sebebi pratiktir: Türkçe aramada “shadow” kelimesi bu üç dünyayı birden getirir. Bir raporda ya da toplantıda terim geçtiğinde, hangi anlamda kullanıldığını baştan netleştirmek yarım saatlik yanlış anlaşmayı önler.

Komşu Aileler: Rogue Cihazlar ve Configuration Drift

Terimin üç anlamını ayırdık. Geriye, gölge BT ile aynı boşluktan doğan ama farklı adla anılan iki kavram ailesi kalıyor. Bunlar yalancı dost değildir; gerçekten akrabadır, yalnız ölçtükleri şey farklıdır.

Rogue: Ağa Bağlanmış Yetkisiz Cihaz

Rogue kelimesi, ağa fiilen bağlanmış yetkisiz bir cihaz veya servisi anlatır. Gölge BT bir pratiğin onaysızlığını ölçerken, rogue somut bir kutunun ağdaki varlığını ölçer. Sahada en sık üç biçimiyle karşılaşılır:

• Rogue DHCP sunucusu: ağda yetkisiz IP dağıtan bir cihaz. Genellikle kasıt yoktur; birinin evden getirip prize taktığı bir modem, kendi adres havuzunu dağıtmaya başlar ve o segmentteki cihazlar yanlış ağ geçidini öğrenir. Protokolün nasıl çalıştığı ve neden bu kadar kolay bozulduğu DHCP nedir yazısında duruyor.
• Rogue erişim noktası: kurumun kablosuz altyapısına dahil olmayan, birinin kendi ihtiyacı için taktığı bir kablosuz cihaz. Kurumsal kablosuz ağın nasıl tasarlandığını kablosuz ağ tasarımı yazısında anlatıyoruz.
• Rogue cihaz: envanterde hiç bulunmayan uç cihaz. Ağa bağlı bir yazıcı, bir kamera ya da unutulmuş bir test makinesi olabilir.

Sahada en sık karşılaşılan biçimi ise bir cihaz değil bir kolaylıktır ve kurumun kendi personelinden bile gelmez. Kurumda iş yapan bir yüklenici, sözgelimi kamera montajı yapan ekip, ihtiyacı olan ikinci hattı çekmek yerine mevcut bir prize yönetilmeyen bir switch takar ve kimseye haber vermez. Sahada bu cihazlara aptal switch denir ve ad yerinde: yönetim arayüzü olmadığı için ağda ne görünür, ne loglanır, ne de uzaktan kapatılabilir. Kurumun şemasında o noktada hâlâ tek bir cihaz vardır, gerçekte ise arkasında kaç cihaz olduğunu kimse bilmez. Aradan bir yıl geçip o portta bir sorun çıktığında, arıza aranan yer ile arızanın olduğu yer artık aynı yer değildir.

Bu akıştaki sıra, makalenin tezini bir kez daha veriyor. Cihazı bulmak işin başlangıcıdır, kaldırmak ayrı bir plandır ve arada geçen sürede tek koruma kaydın kendisidir. Kayıt tutulmazsa cihaz bir sonraki ziyarete kadar yeniden görünmez olur, üstelik bu kez onu bulan kişi de aynı kişi olmayabilir.

Üçünün ortak yanı, gölge BT ile aynı sebepten doğmalarıdır: birinin ihtiyacı vardı ve resmî yol uzundu.

Configuration Drift: Kayda Geçmeyen Değişiklik

Configuration drift, bir sistemin belgelenmiş hâlinden, elle yapılan ve hiçbir yere kaydedilmeyen değişikliklerle sapmasıdır. Burada onaysız bir araç yoktur; kurumun kendi sistemi, kurumun kendi personeli tarafından, kurumun kendi kaydına işlenmeden değiştirilmiştir.

En bilinen örneği adresleme tarafındadır: bir yönetici, DHCP havuzunun içinden bir adresi bir cihaza elle statik olarak verir. O gün işe yarar. Kayıt sisteminin o adresin kullanıldığından haberi olmadığı için havuz aynı adresi bir başkasına dağıtır ve çakışma çıkar. Doğrusu ya adresi havuz dışına almak ya da rezervasyon tanımlamaktır; ikisinin de nasıl yapıldığı Windows Server DHCP kurulumu yazısında adım adım duruyor.

Drift ile gölge BT arasındaki bağ şudur: ikisi de kaydın gerçekten geri kalmasıdır. Birinde kayıtta olmayan bir araç vardır, diğerinde kayıtta olmayan bir ayar. Panoda görünmeyen kablo ile projede görünmeyen kablo aynı sorunun iki hâlidir.

Kurumunuzda Gölge BT Nasıl Bulunur?

Terimleri ayırdık, şimdi asıl işe geliyoruz: kendi kurumunuzda bu listeyi nasıl çıkaracaksınız? Yöntem, tahmin yürütmek ya da anket yapmak değil, eldeki kayıtları karşılaştırmaktır. Gölge BT tanımı gereği hiçbir yerde yazmaz, ama neredeyse her zaman bir yerde iz bırakır.

Aşağıdaki dört kaynak birbirinin yerine geçmez. Her biri farklı bir gölge türünü yakalar ve pratikte hiçbiri tek başına yeterli olmaz.

Envanterden Başlayın, Tahminden Değil

Bir kurumda neyin kayıt dışı olduğunu bilmek için önce neyin kayıtlı olduğunu bilmek gerekir. Bu yüzden gölge BT avı bir güvenlik projesi olarak değil, bir envanter işi olarak başlar. Envanteriniz yoksa bulduğunuz her araç size sürpriz gibi görünür ve hangisinin gerçekten yeni olduğunu ayırt edemezsiniz.

Açık kaynak tarafında bu işi nasıl kurduğumuzu GLPI ile envanter yönetimi yazısında anlatıyoruz; cihazlardan otomatik toplama yapan ajan tarafı ise GLPI Agent envanter dağıtımı yazısında. Envanterin gölge BT açısından değeri, kurulu yazılım listesini merkezî olarak toplaması ve iki tarama arasındaki farkı görünür kılmasıdır. Asıl bilgi listede değil, iki listenin arasındadır.

Ağ Tarafı: Kim Nereye Bağlanıyor?

Tarayıcıdan çalışan hizmetler cihaza hiçbir şey kurmaz, dolayısıyla envanter aracı onları göremez. Bu araçların bıraktığı tek iz ağdadır. Güvenlik duvarının çıkış kayıtları ve iç DNS sunucusunun sorgu kayıtları, kurum ağından hangi bulut hizmetlerine gidildiğini gösterir. Alan adı çözümlemesinin nasıl işlediğini DNS nedir yazısında ele aldık.

Microsoft’un bu işi ürün tarafında nasıl tanımladığına bakmak, yöntemin kendisini anlamak açısından öğreticidir: Cloud Discovery dokümantasyonunda anlatılan mekanizma, güvenlik duvarı ve proxy günlüklerinin analiz edilerek kullanılan bulut uygulamalarının çıkarılmasıdır. Yani ürünün yaptığı iş, sizin elinizdeki kayıtları okumaktır. Bu, ilk turda ürün almadan da yapılabilecek bir iş olduğunu gösterir.

Ağ tarafının kör noktası da açıktır ve giderek büyümektedir: evden ya da kişisel bağlantıdan kullanılan hiçbir araç bu kayıtlara düşmez.

Fatura Tarafı: Muhasebe Bilir, BT Bilmez

Onaysız bir araç envantere kayıt bırakmaz, ama ödemesi muhasebeye kayıt bırakır. Bu yüzden gölge BT’nin en dolu listesi sık sık BT biriminde değil muhasebede durur. Abonelik ödemeleri, tekrar eden küçük tutarlı kartlı harcamalar ve masraf formlarına yazılmış yazılım kalemleri, hangi ekibin hangi aracı kullandığını doğrudan gösterir.

Bu kaynağın değeri, iki listeyi ilk kez yan yana koymasıdır: ödemesi yapılan araçlar ile envanterde görünen araçlar. Aradaki fark, kurumun parasını ödediği ama varlığından haberdar olmadığı araçların listesidir. Uygulaması da ucuzdur, çünkü kayıt zaten tutulmaktadır.

İnsan Tarafı: Sormak da Bir Keşif Yöntemidir

Son kaynak en çok atlanandır: kullanan kişiye sormak. Üç teknik kaynağın hiçbiri size neden sorusunun cevabını vermez, oysa çözüm o cevabın içindedir.

Sorunun nasıl sorulduğu belirleyicidir. “Onaysız araç kullanıyor musunuz?” sorusu savunma üretir ve boş liste getirir. “Bu işi yaparken hangi araçlar işinizi kolaylaştırıyor, elinizdekilerden hangisi işinizi görmüyor?” sorusu ise hem listeyi hem gerekçesini birlikte getirir. İlkinde çalışan sanık, ikincisinde kaynaktır.

Kime sorulduğu da cevabın zenginliğini belirler. En dolu liste genellikle yöneticilerden değil işi fiilen yapanlardan gelir ve içlerinde en verimli kaynak yeni işe başlayanlardır: ekibin yıllar içinde alışkanlığa dönüştürdüğü araçları ilk kez görürler ve onları hâlâ tuhaf bulacak kadar yenidirler. Bir ekibin yeni gelen birine anlattığı “biz şunu şuradan yapıyoruz” cümleleri, envanterin yazılı olmayan hâlidir. Devir sırasında not alınırsa, keşfin en pahalı kısmı kendiliğinden yapılmış olur.

Gölge BT Nasıl Yönetilir? Yasaklamak Neden Çalışmıyor?

Listeyi çıkardınız. Şimdi asıl karar geliyor ve buradaki ilk refleks genellikle yanlış olanıdır: bulunan araçları topluca engellemek. Bunun neden çalışmadığını yazının başındaki mantık zaten söylüyordu. Gölge BT bir ihtiyacın belirtisidir. Belirtiyi silmek ihtiyacı ortadan kaldırmaz, yalnız onu daha da görünmez bir yola iter.

Plan dışı kabloyu duvardan söküp gitmek, priz sorununu çözmez. Ertesi hafta kablo geri gelir, bu kez daha zor bulunacak bir yerden geçirilerek.

Üç Sonuçtan Biri: Onayla, Değiştir, Kapat

Bulunan her araç için verilecek karar üçe iner. Kararı aracın popülerliği değil, taşıdığı verinin hassasiyeti ve yerine konabilecek alternatifin varlığı belirler.

1. Onayla ve envantere al. Araç işi görüyorsa ve riski kabul edilebilirse, yapılacak tek şey onu gölgeden çıkarmaktır: sorumlusunu yaz, kurumsal hesaba taşı, envantere kaydet. Bu adım araca dokunmaz, yalnız kaydını kurar.
2. Onaylı bir alternatifle değiştir. Aynı işi yapan ve kurumun kontrolünde olan bir araç varsa geçiş planlanır. Kritik olan, geçişin ihtiyacı gerçekten karşıladığının kullanıcıyla doğrulanmasıdır; karşılamıyorsa araç geri gelir.
3. Kapat ve verisini kurtar. Risk kabul edilemezse araç kapatılır. Buradaki kritik adım kapatmak değil, kapatmadan önce içindeki veriyi kurumsal sisteme almaktır. Bu yapılmazsa veri kaybolur ve bir daha hiçbir gölge aracın varlığı size bildirilmez.

Üçüncü maddenin son cümlesi, sürecin tamamının başarısını belirler. Kurum, bildirilen ilk gölge aracı cezalandırırsa ikinci bildirim hiç gelmez.

Bu arada “hayır” demek sürecin başarısızlığı değil, parçasıdır. Ayrım ince ama belirleyicidir: bu yazının işe yaramaz dediği şey toptan yasaktır, yani hiç bakmadan hepsini engellemek. Tek tek değerlendirip gerekçesiyle reddetmek bunun tam tersidir, çünkü orada talep görülmüş, tartılmış ve cevaplanmıştır. Çalışanın öğrendiği şey de farklıdır: birincisinde sormanın anlamsız olduğunu öğrenir, ikincisinde sorulacak bir yer olduğunu.

Bu cevabın payı da artıyor. Vibe coding bir aracın üretim maliyetini neredeyse sıfıra indirdi, dolayısıyla onaya gelen talep sayısı da o taleplerin hiç incelenmemiş olma ihtimali de büyüyor. Ama bu, yasağı kendi başına bir çözüm haline getirmez; yalnızca üçüncü seçeneğin eskisinden daha sık doğru cevap olduğu anlamına gelir. Yukarıdaki saha notunda reddi işe yarar kılan şey de yasağın kendisi değildi: aynı işi usulünce yapacak bir kanalın var olmasıydı.

Talep Süreci, Plan Dışı Hattı Kesen Tek Şeydir

Kalıcı çözüm teknik değil süreçseldir. Gölge BT’nin sebebi resmî kanalın yavaşlığıysa, çözüm de o kanalın hızlandırılmasıdır. NCSC’nin rehberinin tedbir listesinde teknik kontrollerin yanında kullanıcı ihtiyacını karşılayan basit bir talep süreci kurmanın sayılmasının sebebi budur.

Pratikte işe yarayan üç ölçü şudur: talebin nereye yapılacağı belli olmalı, kararın ne kadar sürede verileceği yazılı olmalı ve reddedilen talebe alternatif önerilmelidir. Reddi gerekçesiz bırakan bir süreç, çalışanı bir dahaki sefere hiç sormamaya eğitir.

Teknik kontroller bu sürecin yerine geçmez, onu tamamlar. Ağa bağlanan cihazın kimliğinin doğrulanması bunların başında gelir; 802.1X ile ağ kimlik doğrulamasının nasıl kurulduğunu ayrı bir yazıda, 13 lokasyonda nasıl uygulandığını ise ağ erişim kontrolü vakamızda anlatıyoruz.

Bu Aslında ISO 27001’de Zaten Var

Buraya kadar anlatılan işler size bir standardın maddeleri gibi geldiyse haklısınız. ISO 27001’in Ek A kontrolleri arasında A.5.10 bilgi ve ilgili varlıkların kabul edilebilir kullanımını, A.5.23 bulut hizmetleri kullanımında bilgi güvenliğini, A.8.19 ise işletim sistemlerine yazılım kurulumunu düzenler. Üçü birlikte okunduğunda ortaya çıkan şey tam olarak bu yazının konusudur: hangi aracın kullanılabileceği, bulut hizmetinin nasıl seçileceği ve bir makineye kimin yazılım kurabileceği.

Belgeyi almak zorunda olmayabilirsiniz. Ama listeyi bir çalışma planı olarak okumak zaman kazandırır, çünkü gölge BT’yi kendi başınıza çözmeye kalktığınızda varacağınız yer zaten bu maddelerdir. Standardın envanter ve sorumluluk tarafını, kardeş yazımız olan tek nokta arızası makalesinde ayrıca ele alıyoruz.

Sonuç

Gölge BT, kurumun kötü yönetildiğinin işareti değildir. Çoğu zaman tam tersinin işaretidir: insanlar işlerini yapmaya çalışmaktadır ve önlerindeki yol yeterince hızlı değildir. Sorun, seçilen aracın kötü olması değil, kurumun onu görmüyor olmasıdır.

Bu yüzden gölge BT’ye karşı en zayıf hamle yasak, en güçlü hamle kayıt olur. Envanterde görünen bir araç, aynı araç olmaya devam eder ama artık sorumlusu vardır, yedeği tartışılabilir, kapatıldığında verisi kurtarılabilir. Panoya bağlanan bir hat da aynı kablodur; farkı, sigortasının olmasıdır.

Başlamak için büyük bir proje gerekmez. Elinizdeki üç kaydı yan yana koyun: envanterdeki yazılım listesi, güvenlik duvarının çıkış kayıtları ve muhasebedeki abonelik ödemeleri. Üçünün kesişmediği yerler kurumunuzun gölge BT listesidir ve o liste neredeyse her zaman tahmin edilenden uzundur.

Sonra listedeki her kalem için tek bir soru sorun: bu araç neden var? Cevabı bulduğunuzda elinizde yalnızca kapatılacak bir uygulama değil, karşılanmamış bir ihtiyacın tarifi de olur. Gölge BT’yi kalıcı olarak azaltan şey o tarifi okumaktır; engelleme listesi değil.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.