SAP’ta Banka Bilgisi Değişiklikleri: Standart Yetki Kontrolleri Neyi Kaçırabilir?

Bir tedarikçinin banka hesabını değiştirmek rutin bir ana veri işlemi gibi görünebilir. Ancak yanlış hesaba yönlendirilen bir ödeme, teknik bir yetkilendirme hatasını doğrudan mali kayba dönüştürebilir. SAP ortamlarında bu riski değerlendirirken yalnızca standart işlem koduna kimin eriştiğine bakmak yeterli değildir.

SecurityBridge’den Joris van de Vis’in 20 Ağustos 2026 tarihli değerlendirmesi, aynı iş sonucuna ulaşan farklı teknik yolların standart kontrollerin dışında kalabileceğine dikkat çekiyor. Yazı, banka bilgilerinin değiştirilmesine ilişkin sekiz farklı yolu konu alan bir webinara dayanıyor; ancak bu sekiz yöntemin tamamını adım adım açıklamıyor. Dolayısıyla mesele bir yöntem listesi çıkarmak değil, kontrol tasarımındaki varsayımı sorgulamak: Standart işlem güvenliyse, veri değişikliğinin tamamı da güvenli midir?

Yetki ve görevler ayrılığı gerekli, fakat tek başına yeterli değil

Rol tabanlı erişim, görevler ayrılığı ve onay mekanizmaları temel kontrollerdir. Sorun bu kontrollerin varlığı değil, hangi yolları kapsadıklarının eksik bilinmesidir.

Kaynak, banka verisine erişebilen alternatif yollar arasında daha az bilinen işlemleri, taşıma mekanizmalarını, özel geliştirmeleri, arayüzleri, API’leri ve arka plan süreçlerini sayıyor. Bunların birçoğu meşru operasyonlar için vardır. Risk, bu yolların standart süreçle aynı yetkilendirme, kayıt ve onay güvencelerini sağlayıp sağlamadığının denetlenmemesinden doğar.

Örneğin bir arayüz üzerinden gelen değişiklik, kullanıcı ekranında zorunlu olan onayla ilişkilendirilmiyorsa ek bir kontrol sorusu oluşur. Bu, belirli bir SAP kurulumuna ilişkin doğrulanmış bulgu değil; kurumların kendi sistemlerinde test etmesi gereken bir kontrol senaryosudur.

Veri değişikliği kimin sorumluluğunda?

Yazının ikinci önemli noktası, BT ile iş birimleri arasındaki sorumluluk boşluğu. BT, korunması gereken veriyi finansın tanımladığını; finans ise teknik erişim yollarını BT’nin bütünüyle izlediğini varsayabilir. Böylece her iki taraf da kontrolün diğer ekipte olduğunu düşünür.

Banka bilgisi değişikliği için en az üç sorumluluk açıkça ayrılmalı:

• İş onayı: Değişiklik talebinin gerçekliğini ve ticari gerekçesini kim doğruluyor?
• Teknik uygulama: Değişiklik hangi kullanıcı, servis hesabı veya program üzerinden yapılıyor?
• Bağımsız izleme: Gerçekleşen değişiklikle onay kaydının eşleştiğini kim kontrol ediyor?

Bu ayrım, tek kişinin bütün süreci onaylamasını önlemek kadar, bir servis hesabının işlemini sahipsiz bırakmamak için de önemlidir.

İşlem kaydından veri değişikliğine doğru genişleyen izleme

Yalnızca “hangi işlem çalıştırıldı?” sorusu yerine “hangi kritik alan, hangi yoldan, hangi gerekçeyle değişti?” sorusu sorulmalı. Aşağıdaki kontrol matrisi, kaynakta işaret edilen boşluklara yönelik editoryal bir öneridir; SAP’ta her alan için hazır ve otomatik bulunduğu varsayılmamalıdır.

Kontrol alanı	Sorulacak soru	İncelenecek kanıt
Değişiklik yetkisi	İnsan ve teknik hesapların erişimi gerekli mi?	Rol, servis hesabı ve arayüz yetkileri
Onay ilişkisi	Değişiklik geçerli bir talebe dayanıyor mu?	Talep ve bağımsız onay kaydı
Veri izi	Eski ve yeni değer ile zaman bilgisi görülebiliyor mu?	Uygun değişiklik belgeleri ve uygulama kayıtları
Teknik yol	Standart ekran dışındaki kanallar kapsanıyor mu?	Özel kod, entegrasyon ve arka plan işlerinin envanteri
Ödeme etkisi	Değişiklik sonraki ödeme sürecini etkiledi mi?	Ana veri değişikliği ile ödeme kayıtlarının ilişkisi

Her bir kayıt kaynağının gerçekten etkin olduğu ve gerekli ayrıntıyı ürettiği test edilmelidir. Log saklandığını bilmek, belirli bir değişikliğin kayda geçtiğini kanıtlamaz.

Finans ve SOC’un birlikte değerlendirebileceği sinyaller

Tek bir alarm kuralı bütün suistimal riskini çözmez. Bunun yerine kurumun iş akışına göre örüntüler değerlendirilmelidir. Ödeme öncesinde yapılan beklenmedik banka bilgisi değişikliği, olağan dışı bir teknik hesap kullanımı veya kısa aralıkla yapılan değişiklik ve geri alma hareketleri inceleme adayı olabilir.

Bunlar suistimalin kesin göstergeleri değildir. Meşru bir düzeltme de benzer izler bırakabilir. Alarmın doğrulanması için iş gerekçesi, talep sahibi ve onay zinciri birlikte incelenmeli; hassas banka verileri gereksiz yere geniş bir izleme kitlesine açılmamalıdır.

İlk çalışma: bir kritik alanı uçtan uca test edin

Bütün SAP ortamını aynı anda yeniden tasarlamak yerine, banka hesabı gibi tek bir yüksek etkili veri alanıyla başlanabilir. Finans, SAP yetki ekibi, geliştirme, entegrasyon ve SOC temsilcileri aynı süreç üzerinde çalışmalıdır.

Önce veriyi değiştirebilen meşru kanallar listelenmeli. Ardından yetkili bir test ortamında her kanalın hangi onayı gerektirdiği ve hangi kayıtları ürettiği doğrulanmalı. Eksik görünürlük veya onay bağı için sorumlu ve düzeltme tarihi atanmalı. Son olarak düzeltme sonrasında aynı senaryo yeniden kontrol edilmelidir.

Kaynak, benzer risklerin ödeme koşulları, kredi limitleri, maaş ve bordro verileri, fiyatlandırma ve malzeme değerleme alanlarında da bulunduğunu belirtiyor. Banka bilgisiyle elde edilen kontrol modeli, bu alanlara iş etkisine göre genişletilebilir.

Sürecin yanında sonucu da denetleyin

Standart SAP kontrollerini terk etmek değil, kapsamlarını kanıtlamak gerekiyor. Güçlü bir rol tasarımı; özel kod, entegrasyonlar, teknik hesaplar ve veri değişikliği izleriyle tamamlandığında gerçek iş sonucunu korumaya yaklaşır. Banka bilgisi güvenliğinde ölçüt, yalnızca izinli işlemin çalışması değil, gerçekleşen değişikliğin yetkili, gerekçeli ve izlenebilir olmasıdır.

Kaynak

• SecurityBridge: Breaking the Rules — Why Standard SAP Controls Are Not Enough