İç uygulamalar için SOC 2 erişim incelemeleri: üç aylık bir süreç

Erişim incelemelerinin gerçekten çözdüğü sorun

Bir erişim incelemesi, bir soruya cevap veren hızlı, yazılı bir kontroldür: her kişi hâlâ sahip olduğu erişime ihtiyaç duyuyor mu? Bu teknik bir derin dalış değil. İç uygulamaların yavaş yavaş “herkes her şeyi yapabilir” hâline gelmesini engelleyen pratik bir alışkanlıktır.

Erişim incelemelerinin önlediği ana sorun ayrıcalık artışıdır. Bu, insanların zamanla ekstra izinler toplaması ve bunları geri vermemesi demektir. Bir destek görevlisi yoğun bir ayda işlem yapabilmek için iade yetkisi alır. İki çeyrek sonra ekip değiştirmiştir ama iade yetkisi hâlâ durur çünkü kimse kaldırmayı hatırlamamıştır.

Erişim incelemeleri üç günlük problemi çözer: rol değişiklikleri sonrası kalan eski erişimler, “geçici” yönetici erişiminin kalıcı hâle gelmesi ve birinin kim ne yapabilir diye sorduğunda kimsenin kendinden emin olamaması.

Amaç kötü niyetlileri yakalamak değildir. Amaç, iyi niyetin mevcut gerçeklikle hâlâ eşleşip eşleşmediğini doğrulamaktır: mevcut iş, mevcut ekip, mevcut risk.

Beklentiyi baştan koyun: süreci hafif ve tekrarlayan tutun. Üç aylık bir inceleme rutin bakım gibi hissettirmeli, haftalar süren tek seferlik bir temizlik gibi değil. Küçük, tutarlı düzeltmelerin bir denetim zorlayana kadar kimsenin yapmadığı büyük bir “erişim sıfırlamasından” daha iyi olduğunu unutmayın.

İç uygulama erişimlerinin genelde nerede yanlış gittiği

İç uygulamalar genelde basit başlar. Birkaç kişinin işi hızlıca yapması gerektiği için erişim çabuk verilir ve nadiren yeniden gözden geçirilir. Aylar içinde uygulama özellik kazanır, daha fazla ekip dokunur ve izinler sessizce birikir.

En büyük suçlular müşteriyle doğrudan temas etmeyen, “güvenli” gibi görünen günlük araçlardır: operasyon yönetim panelleri, destek araçları (ticket, iadeler, hesap sorgulamaları), BI panoları, CRM sistemleri ve bordro ya da işe alım hattı gibi İK araçları.

Bu araçlar büyüdükçe erişim genellikle en kolay yoldan genişler: bir iş arkadaşının izinlerini kopyalamak, hızlı bir istisna eklemek veya birinin işi açması için admin rolü vermek. Aylar sonra kimse neden bu izinlerin verildiğini hatırlamaz ama izinler hâlâ durur.

Bazı risk alanları sürekli olarak ortaya çıkar çünkü etkileri anında hissedilir:

• Veri dışa aktarımları (CSV indirme, toplu dışa aktarma)
• Ödemeler ve iadeler (Stripe işlemleri, kredi, chargebackler)
• Kullanıcı yönetimi (kullanıcı oluşturma, şifre sıfırlama, rol atama)
• Yapılandırma değişiklikleri (feature flagler, fiyat kuralları, entegrasyonlar)
• Geniş kayıt erişimi (tüm hesaplarda hassas alanlar)

Sık görülen bir boşluk: ekipler uygulama izinlerini gözden geçirir ama altyapı erişimini unuturlar. Uygulama rolleri birinin araç içinde ne yapabileceğini kontrol eder. Altyapı erişimi ise veritabanı, bulut konsolu, loglar ve dağıtım hatlarını kapsar. Uygulama rolü “sadece oku” olsa bile, alttaki sistemler takip edilmezse güçlü erişim elde edilebilir.

Tek sayfalık, hafif bir üç aylık inceleme

Üç aylık bir erişim incelemesi yalnızca kolayca tamamlanabiliyorsa işe yarar. Amaç basit: her iç uygulama için kimlerin erişime ihtiyacı olduğunu doğrulamak ve ihtiyaç olmayanları ayrıcalık artışına dönüşmeden önce kaldırmak.

Düzenli bir kadans seçin (üç aylık) ve iyi karar verebilecek en küçük grubu belirleyin. Çoğu ekipte bu, bir uygulama sahibi (uygulamanın ne yaptığını bilen), her departmanın yöneticisi (insanları ve rolleri bilen) ve değişiklikleri uygulayabilecek biri (IT veya platform yöneticisi) olur.

Bir kesme tarihi belirleyin ve incelemeyi o anın bir “anlık görüntüsü” olarak kabul edin; örneğin: “Erişim listesi 1 Nisan tarihi itibarıyla.” Erişim her gün değişir. Bir anlık görüntü incelemeyi adil kılar ve sonsuz tekrar kontrolü engeller.

Her kullanıcı için yalnızca net bir karar gerekir: erişim olduğu gibi devam etsin, erişim kaldırılsın (veya düşürülsün), ya da bir neden ve bitiş tarihi ile istisna kaydedilsin.

Kanıt uzun bir rapor olmak zorunda değil. Yapması gereken net, tutarlı ve tekrarlanabilir olmasıdır: anlık görüntü tarihi, kimlerin incelediği, ne değiştiği ve varsa istisnaların nedenleri.

Tek sayfa şablonu (tekrar kullanılabilir)

Tek bir tablo veya elektronik tablo yeterlidir. Uygulamayı, kullanıcıyı, rol veya izin seviyesini, son giriş tarihini (isteğe bağlı), kararı (koru/kaldır/istisna), istisna nedeni ve bitiş tarihini, inceleyen kişiyi, inceleme tarihini ve değişikliğin uygulandığı tarihi takip edin.

Eğer dahili araçlarınızı AppMaster gibi bir platformda kuruyorsanız, bu kanıtı aynı yönetim uygulamasında tutabilirsiniz: bir ekran anlık görüntü için, bir ekran kararlar için ve bir ekran istisna hatırlatmaları için. Böylece inceleme tanımladığı sisteme yakın olur ve tekrarı kolaylaşır.

İncelemeyi kolaylaştıran basit izin tasarımı

Eğer erişim incelemeleri karmakarışık geliyorsa, genellikle izinler dağınıktır. Amaç mükemmel politika dili değil. Amaç, “Bu kişi hâlâ bunu yapabilmeli mi?” sorusuna hızlı cevap verecek bir rol yapısıdır.

Rolleri küçük ve okunabilir tutun. Çoğu iç uygulama 5–20 rol ile rahat çalışır. Yüzlerce özel istisna olduğunda her üç aylık inceleme tartışmaya döner, kontrol yerine.

Pratik bir yaklaşım, iş bazlı roller ve en az ayrıcalık varsayılandandır. İnsanlara günlük işler için gereken verilmelidir; ekstra olan her şey süre sınırlı bir eklenti olsun, sona ersin veya yeniden onaylansın.

İncelemeyi kolaylaştıran birkaç rol tasarım kuralı:

• Kişi-özgü rollerden ziyade iş rolleri tercih edin (Support Agent, Ops Manager gibi)
• “Görüntüleyebilir” ile “değiştirebilir” izinlerini ayırın
• “Dışa aktarabilir” yetkisini ayrı bir izin olarak ele alın
• Güçlü eylemleri (silme, iade, fatura değiştirme, bordro düzenleme) nadir tutun
• Her rolün ne için olduğunu bir düz cümleyle dokümante edin

Acil durumlar için tek bir “break-glass” admin rolü olması yardımcıdır; ekstra kontrollerle: onay, zaman sınırı ve ayrıntılı kayıt.

Örnek: bir destek portalında “Support Viewer” ticketları okuyabilir, “Support Editor” güncelleyip cevaplayabilir, “Support Exporter” raporları indirebilir. Üç aylık incelemede ekip değiştiren birinin hâlâ Exporter olup olmadığını hızla görebilir ve günlük işi engellemeden bu izni kaldırabilirsiniz.

Erişim ve incelemeleri izlemek için temel bir veri modeli

Erişim incelemeleri, üç soruyu hızlı cevaplarsanız kolaylaşır: kim erişime sahip, neden ona sahip ve ne zaman bitmeli.

Elektronik tabloyla başlayabilirsiniz ama birkaç uygulama ve ekipten fazla olduğunda küçük bir veritabanı fayda sağlar. Zaten AppMaster ile dahili araçlar geliştiriyorsanız, bu Data Designer (PostgreSQL) içinde doğal olarak uyar.

Başlangıç için basit, pratik bir şema:

-- Core
Users(id, email, full_name, department, manager_id, status, created_at)
Apps(id, name, owner_user_id, status, created_at)
Roles(id, app_id, name, description, created_at)
Permissions(id, app_id, key, description)

-- Many-to-many, with audit-friendly fields
UserRoleAssignments(
  id, user_id, role_id,
  granted_by_user_id,
  reason,
  ticket_ref,
  created_at,
  expires_at
)

-- Optional: role to permission mapping (if you want explicit RBAC)
RolePermissions(id, role_id, permission_id)

-- Review history
AccessReviewRecords(
  id, app_id,
  reviewer_user_id,
  review_date,
  outcome,
  notes
)

-- Exception tracking: temporary elevation
AccessExceptions(
  id, user_id, app_id,
  permission_or_role,
  approved_by_user_id,
  reason,
  ticket_ref,
  created_at,
  expires_at
)

Gerçekte bunu çalıştıran birkaç kural var. Her atamanın bir sahibi (onaylayan), düz bir nedeni (düz anlatım) ve bir ticket referansı olmalı (isteği izleyebilmek için). Geçici erişimler, nöbet rotasyonları ve olay desteği için expires_at kullanın. Bir bitiş tarihi seçmek zor geliyorsa, bu genellikle rolün çok geniş olduğunun işaretidir.

İnceleme sonuçlarını basit tutun ki insanlar gerçekten kaydetsin: olduğu gibi koru, kaldır, düşür, yeni bir bitişle yenile ya da istisna olarak belgele.

İnceleme kayıt tablosu en önemlisidir. İncelemenin gerçekleştiğini, kim yaptığı, ne değiştiğini ve nedenini kanıtlar.

Adım adım: üç aylık erişim incelemesi nasıl yürütülür

Üç aylık inceleme, rutin idari görev gibi hissettirdiğinde en iyi çalışır; denetim olayı gibi değil. Amaç basit: bir sorumlunun erişime bakması, karar vermesi ve ne değiştiğini gösterebilmeniz.

1. Her iç uygulama için bir erişim anlık görüntüsü alın. Aktif kullanıcıların, rollerin veya izin gruplarının, önemli ayrıcalıkların, son girişlerin ve erişimi ilk kimin onayladığının (varsa) nokta-zamanlı bir listesini dışa aktarın. Uygulama destekliyorsa servis hesapları ve API anahtarlarını da dahil edin.

2. Her anlık görüntüyü tek isimli bir uygulama sahibine gönderin. Sahipliği net tutun: bir kişi onaylar, diğerleri yorum yapabilir. Eğer açık bir sahibi yoksa başlamadan önce atayın. Bir son tarih ekleyin ve kural koyun: yanıt yoksa erişim en güvenli varsayılan değere düşürülür.

3. Fazladan dikkat gerektiren izinleri vurgulayın. Sahiplerden her satırı eşit şekilde okumalarını istemeyin. Para taşıyan, veri dışa çıkaran, kayıtları silen, izinleri değiştiren veya müşteri verisine erişenleri işaretleyin. Ayrıca geçen çeyrekte giriş yapmamış kullanıcıları da işaretleyin.

4. Değişiklikleri hızlıca uygulayın ve ilerlerken kaydedin. Kullanılmayan hesapları kaldırın, rolleri düşürün ve “geçici” erişimleri bitiş tarihli hale getirin. İnceleme değişiklikler sistemde uygulanana kadar tamamlanmış sayılmaz.

5. Kısa bir yazılı özetle kapatın ve kanıtları saklayın. Bir sayfa yeter: neyi incelediniz, kim onayladı, ne değişti ve ne açık kaldı.

Daha sonra göstermek için kolayca sunulabilecek kanıtlar:

• Dışa aktarılmış anlık görüntü (tarihlenmiş)
• Her uygulama sahibinin onay notları
• Değişiklik günlüğü (eklemeler, kaldırmalar, düşürmeler)
• Kısa sonuç özeti
• İstisnalar ve bitiş tarihleri

Eğer dahili araçlarınızı AppMaster üzerinde kurduysanız, erişim sahiplerini ve onay notlarını iş akışının bir parçası yaparak kanıtın iş yapılırken oluşturulmasını sağlayabilirsiniz.

Ayrıcalık artışını erken yakalamak için önce neye bakmalı

Zamanınız kısıtlıysa, erişimin sessizce genişlediği yerlere odaklanın. Bunlar denetçilerin de sorduğu maddelerdir çünkü kontrollerinizin gerçekte çalışıp çalışmadığını gösterir.

Hızlı, yüksek sinyal veren kontrollerle başlayın:

• Gerçeklikle uyuşmayan hesaplar (eski çalışanlar, bitmiş yükleniciler) hâlâ giriş veya API tokenlarına sahip
• Kim ne yaptı ayrılamayan paylaşılan kimlik bilgileri
• Geçici olması gereken ama bitiş tarihi veya inceleme notu olmayan yükseltilmiş erişimler
• Rol değiştiren kişilerin eski işlerinden kalan erişimler (destekten satışa geçen ama hâlâ iade veya veri dışa aktarma yetkisi olan)
• Erişim isteklerini onaylayacak ve kullanıcı listesini inceleyecek belirgin sahibi olmayan uygulamalar

Sonra garip görünen her şeye hızlıca “neden” kontrolü yapın. Birkaç dakikada bir ticket, istek veya yönetici onayı isteyin. Birkaç dakikada neden bulunamıyorsa, düşürün veya kaldırın.

Örnek: bir pazarlama analisti iki hafta opsa yardım etmiş ve iç panoya admin yetkisi verilmiş olsun. Üç ay sonra hâlâ admin ve faturaya erişimi var. Bir üç aylık inceleme bunu mevcut iş rolünü izinlerle karşılaştırarak yakalamalıdır.

İncelemeyi etkisiz yapan yaygın hatalar

Bu incelemelerin amacı basit: birinin erişimi kontrol ettiğini, nedenini anladığını ve artık gerek olmayanı kaldırdığını kanıtlamaktır. Başarısız olmanın en hızlı yolu bunu sadece bir kutuyu işaretlemek olarak görmek.

Süreci sessizce bozan hatalar

• Herkesin satırları düzenleyebildiği, onayların net olmadığı ve onayın sadece "tamam gibi" olduğu paylaşılan bir elektronik tabloda tüm incelemeyi tutmak
• Bir kişinin hâlâ işine ihtiyaç olup olmadığını doğrulamadan veya kapsamı (okuma vs yazma, prod vs staging) kontrol etmeden erişimi onaylamak
• Sadece adminleri incelemek, fakat "Finance: payouts", "Support: refunds" veya "Ops: data export" gibi güçlü non-admin rolleri görmezden gelmek
• Toplantıda erişimi kaldırıp neyin, ne zaman kaldırıldığını kaydetmemek, böylece aynı hesapların gelecek çeyrekte yeniden ortaya çıkması
• İstisnalara sonsuza kadar izin vermek çünkü bitiş tarihi yok ve kimse yeniden gerekçe sormuyor

Yaygın bir örnek: bir destek liderine yoğun bir ay için geçici "Refunds" erişimi verilir. Üç ay sonra satışa geçti ama izin hâlâ orada çünkü kaldırılmadı ve izlenmedi.

İncelemeyi dürüst tutan düzeltmeler

• İsimli bir inceleyici ve tarihli bir onay zorunlu kılın, araç basit olsa bile
• Her yüksek etkili izin için kısa bir neden kaydedin ve bu nedeni iş ihtiyacıyla ilişkilendirin
• Sadece admin listesine değil yüksek etkili rollere ve iş akışlarına bakın
• Kaldırmaları kendi çıktı olarak takip edin (kim, ne, ne zaman) ve gerçekten kaldırıldığını teyit edin
• İstisnalara varsayılan bitiş tarihi koyun ve yenileme için taze onay isteyin

Her seferinde tekrar kullanabileceğiniz üç aylık kontrol listesi

İyi bir üç aylık inceleme kasıtlı olarak sıkıcıdır. Her seferde aynı adımları istiyorsunuz ve kim onayladığı konusunda hiçbir kafa karışıklığı olmamalı.

• Bir erişim anlık görüntüsü alın ve etiketleyin. Her uygulama için kullanıcı ve roller/izinlerin güncel listesini dışa aktarın, bir “tarihi itibarıyla” kaydedin (örneğin: SupportPortal_access_2026-01-01). Dışa aktaramıyorsanız ekran görüntüleri veya rapor yakalayın ve aynı şekilde saklayın.
• Her uygulamanın tek bir isimli sahibi olduğundan emin olun. Her iç uygulama için sahibi not edin ve onlar her kullanıcıyı koru, kaldır ya da rol değiştir olarak işaretlesin.
• Yüksek riskli izinleri ayrı inceleyin. Adminleri ve dışa aktarma/indirme izinlerini kısa bir listeye alın. Ayrıcalık artışı genellikle orada saklanır.
• Geçici erişimleri kasıtlı olarak sonlandırın. Her “bu proje için” erişimin bir bitiş tarihi olmalı. Bitiş tarihi yoksa kalıcı gibi davranın ve yeniden gerekçe isteyin ya da kaldırın.
• Kaldırmaları tamamlayın ve çalıştığını doğrulayın. “Ticket oluşturuldu” demekle yetinmeyin. Erişimin gerçekten gittiğini doğrulayın (anlık görüntüyü yeniden alın veya rol ekranlarını kontrol edin) ve doğrulama tarihini not edin.

Her uygulama için basit bir inceleme kaydı saklayın: inceleyici adı, tarih, sonuç (değişiklik yok / değişiklik yapıldı) ve varsa istisnalar hakkında kısa bir not.

Gerçekçi bir örnek: küçük bir şirkette bir çeyrek

45 kişilik bir şirkette iki iç uygulama var: bir Destek aracı (ticketler, iadeler, müşteri notları) ve bir Ops yönetim paneli (siparişler, stok, ödeme raporları). Uygulamalar no-code bir platformda AppMaster gibi hızlıca inşa edildi ve ekipler “bir ekran daha” isteyince büyüdü.

Çeyrek başında erişim kağıt üzerinde iyiydi. Ops, Destek ve Finans ayrı rollere sahipti. Ancak geçen çeyrekte yoğun bir lansman oldu ve bazı “geçici” değişiklikler geri alınmadı.

Açık bir ayrıcalık artışı örneği: bir destek lideri hafta sonu çoğaltılmış siparişleri düzeltmek için admin erişimi istiyor. Tam “Ops Admin” rolü verildi. Üç ay sonra rol hâlâ var. İnceleme sırasında yönetici liderin yalnızca iki eyleme ihtiyacı olduğunu itiraf etti: sipariş geçmişini görüntülemek ve makbuz yeniden gönderimini tetiklemek.

İnceleme toplantısı 35 dakika sürdü. En yüksek ayrıcalikli roller ve son zamanlarda kullanılmamış erişimlerle başlayarak kullanıcı kullanıcı ilerlediler:

• Koru: Ops yöneticileri tam adminde kaldı, çünkü günlük işlerine uyuyordu.
• Kaldır: bir Finans yüklenicisinin Destek aracına erişimi kaldırıldı.
• Düşür: Destek lideri “Ops Admin”den sınırlı bir “Order Support” rolüne düşürüldü.
• Geçici istisna: bir Finans analistine çeyrek sonu mutabakatı için 14 günlük yükseltilmiş erişim verildi; sahibi ve bitiş tarihi atandı.

Ayrıca test için kullanılan paylaşılan admin hesabı temizlendi. Herkes ödünç almak yerine isimli hesaplarla ve doğru rollerde çalıştırıldı.

Bir çeyrekte sağlananlar:

• 3 tam admin rolü kaldırıldı
• 4 kullanıcı en az ayrıcalıklı rollere düşürüldü
• 2 eski hesap devre dışı bırakıldı (biri eski çalışan, biri yüklenici)
• 1 geçici istisna sahibine bitiş tarihi atandı

Hiçbir şey kırılmadı; Support yine gereken iki eylemi yapabildi. Kazanç, “olur da” erişimlerini normalleşmeden önce azaltmaktı.

Sonraki adımlar: süreci tekrarlanabilir hale getirin

Küçük bir başlangıç noktası seçin ve sıkıcı tutun. Amaç mükemmel sistem değil. Amaç her çeyrekte kahramanlıklara gerek kalmadan işler haldeki bir ritimdir.

İlk üç iç uygulamanızla başlayın: müşteri verisine, paraya veya yönetici eylemlerine dokunanlar. Her uygulama için tek bir sahibi atayın ki “Kim erişmeli ve neden?” sorusunu cevaplayabilsin. Ardından insanların gerçekten nasıl çalıştığını yansıtan birkaç rol yazın (Viewer, Agent, Manager, Admin gibi).

İncelemeyi takvime şimdi ekleyin. Basit bir desen: çeyreğin ilk iş gününde tekrarlayan bir hatırlatıcı ve onaylayıcılar için iki haftalık pencere; böylece onaylayıcılar acele etmez ve işten ayrılanlar beklemez.

İnceleme kaydının nerede tutulacağına ve kimin değiştirebileceğine karar verin. Ne seçerseniz seçin, tutarlı ve kontrollü tutun ki kanıt gerektiğinde tek bir yer gösterilebilsin.

Zamanla ayakta kalan bir kurulum:

• Her iç uygulama için bir sahibi ve yedek sahibi atayın
• Tek bir erişim inceleme günlüğü tutun; düzenleme haklarını sahipler ve güvenlik ile sınırlayın
• Her koruma/kaldırma/istisna kararı için bir cümlelik gerekçe zorunlu kılın
• Takip eylemlerini tarihleriyle takip edin
• Pencerenin sonunda kısa bir onay alın (sahip + yönetici)

Eğer zaten AppMaster (appmaster.io) üzerinde dahili araçlar geliştiriyorsanız, bu süreci doğrudan çalıştırdığınız uygulamalara gömebilirsiniz: rol tabanlı erişim, yükseltilmiş roller için onaylar ve kim neyi neden değiştirdiğini yakalayan denetlenebilir kayıtlar.

Aynı kişiler aynı küçük adımları her çeyrek yaptıkça, ayrıcalık artışı bariz hale gelir ve düzeltmesi kolaylaşır.