İçeriğe geç

Denetim yol haritası

Banka entegrasyonu güvenli mi? Salt-okunur erişim nasıl çalışır?

Banka entegrasyonunun güvenliğini entegrasyonun kendisi değil, talep edilen yetkinin kapsamı belirler. Doğru kurulumda internet şubesi parolanız paylaşılmaz: banka, hesap hareketi paylaşımı için ayrı bir entegrasyon kullanıcısı tanımlar ve bu kullanıcı yalnızca okuma yapar. Para transferi yetkisi talep eden ya da internet şubesi parolanızı isteyen bir kurulum, ölçüsüz risk taşır ve onaylanmamalıdır.

Bu sayfa bir yazılıma banka erişimi vermeden önce izlenecek yolu adım adım anlatır: hangi soru kime sorulur, cevabın hangi biçimi kabul edilir, nerede takılırsınız. Aşağıdaki denetim listesi on soruyla değerlendirdiğiniz yazılımın erişim modelini puanlar ve tedarikçinize gönderebileceğiniz yazılı soru listesini çıkarır. Liste tamamen tarayıcınızda çalışır; işaretlediğiniz cevaplar hiçbir sunucuya gönderilmez.

7

adım

Kurulum öncesi ve kurulum sonrası işler birlikte.

1 saat 45 dakika

sizin işiniz

Yedi adımın süre rozetlerinin toplamı (105 dakika).

10

soruluk denetim

Azami risk puanı 23; tek eleyici cevap toplamı ezer.

0

dışarıya istek

Denetim listesi tarayıcıda çalışır, cevaplar sunucuya gitmez.

Süreler bu sayfanın tahminidir, ölçülmüş bir istatistik değildir. Bankanın ve tedarikçinin cevap verme süresi bu toplamın dışındadır.

01

Erişim yetkisi denetim listesi

Kısa cevap: değerlendirdiğiniz yazılımın erişim modelini on soruyla ölçün; iki soruda çıkan tek bir “evet” tek başına eleyicidir.

Soruları tedarikçinin size söylediklerine göre değil, bildiğinize göre işaretleyin. Emin olmadığınız her soruda “Bilmiyorum” seçeneği doğru cevaptır: bilinmeyen bir madde, bilinen bir riskten daha az tehlikeli değildir ve listenin altındaki yazılı soru listesine girer. Değerlendirme tarayıcınızda hesaplanır; işaretlediğiniz cevaplar sunucuya gönderilmez ve saklanmaz.

  1. 01

    Yazılım, internet şubesi kullanıcı adınızı ve parolanızı istiyor mu?

    Eleyici Sorun yok

    Doğru kurulum, bankanın bu iş için ayrıca ürettiği entegrasyon kullanıcı bilgisiyle yapılır.

  2. 02

    Bankadan istenen kullanıcıda para transferi (havale, EFT, ödeme) yetkisi var mı?

    Eleyici Sorun yok

    Okuma yetkisiyle sınırlı kullanıcı, sızıntı hâlinde bile para çıkışına yol açmaz.

  3. 03

    Entegrasyon için bankada ayrı bir kullanıcı tanımlanıyor mu (günlük kullandığınız kullanıcı değil)?

    Yüksek Sorun yok

    Ayrı kullanıcı, banka tarafında hem dar yetki hem ayrıştırılabilir kayıt sağlar.

  4. 04

    Banka kimlik bilgileri şifreli saklanıyor ve kaydedildikten sonra arayüzde bir daha görüntülenemiyor mu?

    Eleyici Açık kaldı

    Kaydedildikten sonra ekranda tekrar gösterilebilen bir kimlik bilgisi, o ekranı gören her kullanıcının ve ekran görüntüsü içeren her destek talebinin eriştiği bir sırdır. Şifreli saklamak ile bir daha göstermemek ayrı iki güvencedir; ikisi birden sorulmalıdır.

  5. 05

    Yazılım içinde kullanıcı bazlı yetki verilebiliyor mu?

    Yüksek Sorun yok

    İzinler ayrı ayrı verilebiliyorsa, dışa aktarma ve evrak üretme gibi riskli işlemler dar bir gruba bırakılabilir.

  6. 06

    Her veri çekme denemesi (tarih, sonuç, hata) kayıt altına alınıp size gösteriliyor mu?

    Orta Riskli

    Kaydı görünmeyen bir erişim denetlenemez: verinin ne zaman ve kaç kez çekildiğini yalnızca tedarikçi bilir.

  7. 07

    Birden fazla şirket aynı sistemde yönetiliyorsa, yetkisi olmayan kullanıcının başka şirketin verisini görmesi engelleniyor mu?

    Yüksek Açık kaldı

    Çok şirketli sistemlerde en sık görülen açık, şirket filtresinin yalnızca arayüzde uygulanmasıdır. Filtre veri katmanında değilse, arayüzü atlayan her yol başka şirketin verisine açılır.

  8. 08

    Verinin nerede saklandığı ve kimlerin erişebildiği yazılı olarak belirtiliyor mu?

    Yüksek Riskli

    Hesap hareketleri kişi ve şirket bilgisi taşır. Verinin hangi altyapıda ve hangi ülkede tutulduğu sözleşmeye yazılması gereken bir bilgidir; sözlü beyan denetimde kanıt sayılmaz.

  9. 09

    Erişimi tedarikçiye bağımlı olmadan kendi başınıza iptal edebiliyor musunuz?

    Eleyici Sorun yok

    İki adım da (banka tarafı ve yazılım tarafı) sizin yetkinizdeyse, ilişkinin sonunda erişim tek taraflı olarak kapanır.

  10. 10

    Sözleşmede verinizin üçüncü taraflara satılmayacağı ve hizmet bitince ne olacağı yazıyor mu?

    Yüksek Açık kaldı

    Sözleşmede yazmayan taahhüt taahhüt değildir. Üçüncü taraflarla paylaşmama, hizmet sonunda silme veya iade ve saklama süresi ayrı ayrı yazılmalıdır.

Değerlendirme

Orta risk

Risk puanı

6 / 23

Model çalışabilir, ama açık kalan noktalar var. Aşağıdaki soruları yazılı olarak sorun ve cevapları sözleşme ekine koyun.

Riskli cevap
2
Açık kalan madde
3
Sorun görünmeyen
5

Puanlama bu sayfanın kendi ölçeğidir, bir standarda dayanmaz. Amacı sıralamak değil, konuşulmamış maddeyi görünür kılmaktır.

Tedarikçiye gönderilecek soru listesi

İşaretlenen her riskli ve açık madde için hazır yazılmış soru. Olduğu gibi e-postaya yapıştırılabilir; gelen cevapları sözleşme ekine koymak, sözlü güvenceyi yazılı taahhüde çevirmenin en kısa yoludur.

  1. 1. Banka kimlik bilgilerimiz nasıl saklanıyor? Şifre çözme anahtarı nerede duruyor, hangi anda çözülüyor ve bilgi kaydedildikten sonra arayüzde veya destek ekranlarında tekrar görüntülenebiliyor mu?
  2. 2. Hesaplarımıza yapılan her sorgunun kaydını ekranda görebiliyor muyum? Kayıtlar ne kadar süre saklanıyor?
  3. 3. Şirketler arası veri ayrımı hangi katmanda uygulanıyor? Aktif şirket bağlamı kurulamazsa sistem ne döndürüyor: her şey mi, hiçbir şey mi?
  4. 4. Verimiz hangi ülkede ve hangi altyapıda saklanıyor? Barındırma, yedekleme ve destek için kullandığınız alt yüklenicilerin listesi nedir?
  5. 5. Sözleşmede verimizin üçüncü taraflarla paylaşılmayacağı yazıyor mu? Hizmet sona erdiğinde veri ne kadar sürede siliniyor ve öncesinde dışa aktarabiliyor muyuz?

Bu liste bir hukuki belge değildir ve sözleşme incelemesinin yerine geçmez. Kritik sözleşmeler için hukuk danışmanınıza başvurun.

02

Yedi adımlık denetim yolu

Kısa cevap: sıra maliyet sırasıdır — önce tek e-postayla cevaplanan ve olumsuz çıkarsa süreci bitiren sorular, sonra teknik inceleme, en sonda kurulum sonrası kalıcı işler.

Adımların ilk ikisi doğru kurgulanmamışsa kalan beşinin bir anlamı kalmaz: yanlış yetkiyle açılmış bir banka kullanıcısını, yazılım tarafındaki hiçbir önlem güvenli hâle getirmez. Süre rozetleri sizin harcayacağınız zamanı gösterir; bankanın ve tedarikçinin cevap verme süresi bunun dışındadır ve çoğu zaman daha uzundur.

  1. Yetki kapsamını yazılı olarak sorun

    10 dk

    Tedarikçiye tek bir soru sorun: bankadan hangi yetkiler talep ediliyor?

    Cevabın “hesap hareketi ve bakiye okuma” ile sınırlı olması gerekir. Sözlü cevap yeterli değildir; bankanın başvuru formunda hangi kutunun işaretleneceğini isteyin. İşaretlenmiş bir form, satış görüşmesindeki cümleden daha bağlayıcıdır ve bankada da bir karşılığı vardır.

    Burada takılırsan

    Cevap “bankanın standart entegrasyon kullanıcısı” gibi genel bir ifadeyse kabul etmeyin. Formun doldurulmuş bir örneğini isteyin: yetki kapsamı formun üstünde yazar. Tedarikçi formu göstermekten kaçınıyorsa bu, sürecin kendisiyle ilgili ilk uyarıdır.

    MerkeziHesap bu soruya nasıl cevap veriyor?

    MerkeziHesap’ın banka sürücüsü sözleşmesinde bankaya giden beş metot tanımlıdır ve hepsi okuma yönündedir: kimlik doğrulama, hesap listesi, hesap hareketleri, bakiye ve dekont indirme. Sözleşmedeki kalan iki metot bankayı hiç aramaz: biri sürücünün kendi adını, diğeri bankanın geriye dönük veri politikasını döndürür. Para gönderen, talimat veren veya hesap açan bir metot sözleşmede yoktur; bir sürücü yazmak isteseniz bile çağıracak bir uç bulamazsınız.

  2. Banka tarafında hangi kullanıcının açılacağını netleştirin

    20 dk + bankanın cevabı

    Entegrasyon için bankada ayrı bir kullanıcı açılmalı; kendi internet şubesi kullanıcınız verilmemeli.

    Banka temsilcinizi arayın ve hesap hareketi paylaşımı için ayrı bir entegrasyon kullanıcısı tanımlanmasını isteyin. Ayrı kullanıcının üç faydası vardır: yetkisi banka tarafında dar tutulabilir, banka kayıtlarında sorgunun yazılımdan geldiği ayırt edilebilir ve kapatıldığında kendi erişiminiz etkilenmez.

    Burada takılırsan

    Banka “mevcut kullanıcıyı kullanın” derse ısrar edin ve talebi yazılı iletin. Bazı bankalarda bu tanımlama şubeden, bazılarında kurumsal internet şubesinden yapılır; hangi kanaldan yapıldığını baştan sorun, form iki kez dolaşmasın.

    MerkeziHesap bu soruya nasıl cevap veriyor?

    MerkeziHesap kurulumu bankanın kendi başvuru formuyla yürür: form şirket bilgilerinizden doldurulur, siz imzalayıp bankaya verirsiniz, banka entegrasyon kullanıcı bilgisini size iletir. Kimlik bilgisini üreten taraf bankadır; MerkeziHesap kendi adına bir kullanıcı açmaz.

  3. Kimlik bilgisinin nasıl saklandığını sorun

    15 dk

    İki ayrı soru vardır: şifreli mi saklanıyor, ve kaydedildikten sonra ekranda tekrar görünüyor mu?

    Şifreli saklama ile “bir daha görüntülenememe” aynı şey değildir. Şifreli saklanan bir kimlik bilgisi, arayüzde tekrar gösteriliyorsa o arayüzü gören herkesin ve ekran görüntüsü alan her destek talebinin erişebildiği bir sırdır. Üçüncü soruyu da ekleyin: hata kayıtlarına (log) düşüyor mu?

    Burada takılırsan

    Cevap “şifreli tutuyoruz” ile sınırlıysa şunu sorun: şifre çözme anahtarı nerede duruyor ve hangi anda çözülüyor? Doğru cevap “yalnızca bankaya bağlanılan anda, bellekte” biçiminde olur. Anahtarın veritabanının yanında durması, şifrelemenin faydasını büyük ölçüde götürür.

    MerkeziHesap bu soruya nasıl cevap veriyor?

    Banka kimlik bilgileri veritabanına uygulama anahtarıyla şifrelenmiş olarak yazılır ve modelde gizli alan olarak işaretlidir: nesne diziye çevrildiğinde, arayüze veri taşınırken ve API cevabı üretilirken alanın kendisi çıktıya hiç girmez. Senkron katmanının log kapısı, adında parola, token, secret, sertifika, müşteri numarası gibi bir parça geçen her anahtarın değerini iç içe dizilerde de arayarak *** ile değiştirir.

  4. Yazılımın kendi giriş yöntemini inceleyin

    10 dk

    Banka verinizi tutan ekrana giriş nasıl yapılıyor? Kalıcı parola, çalınabilecek kalıcı bir sırdır.

    Banka hareketlerinizi gösteren ekranın kapısı, o hareketler kadar korunmalıdır. Kalıcı parola kullanan bir sistemde parola not defterine yazılır, ekipçe paylaşılır, başka sitelerde tekrar kullanılır ve bir gün başka bir sitenin sızıntısında ortaya çıkar. Tek kullanımlık kod bu zincirin tamamını keser.

    Burada takılırsan

    Sistem parolayla çalışıyorsa en azından iki adımlı doğrulama ve oturum süresi sınırı olup olmadığını sorun. “Şifreyi biz de göremiyoruz” cevabı parolanın hash’lendiğini gösterir ve doğru bir cevaptır; “destek ekibimiz gerekirse şifrenizi görebilir” cevabı ise tek başına eleyici bir işarettir.

    MerkeziHesap bu soruya nasıl cevap veriyor?

    MerkeziHesap’ta kalıcı parola yoktur. Giriş, e-posta adresine gönderilen tek kullanımlık kodla yapılır: kod veritabanında düz metin değil hash olarak durur, kısa sürede geçersizleşir, yanlış deneme sayısı sınırlıdır ve sınır aşılınca kod yakılır. Giriş için üretilen kod e-posta değiştirmek için, e-posta değiştirmek için üretilen kod giriş için kullanılamaz.

  5. Kendi ekibinizin yetkisini kurun

    20 dk

    Riskin büyük kısmı tedarikçide değil, sizin tarafınızda: hesap hareketlerini şirkette kim görecek?

    Banka hareketleri maaş, tedarikçi fiyatı ve müşteri listesi taşır. Kurulumdan sonraki ilk iş, kimin neyi göreceğini ve kimin evrak üretip veri dışa aktarabileceğini tanımlamaktır. Ayrılan çalışanın erişimini kapatma adımını da şimdi yazın; ayrılış gününde hatırlanmayacak bir adım, ayrılış gününden sonra da açık kalır.

    Burada takılırsan

    Yazılım yalnızca “yönetici / kullanıcı” ikilisi sunuyorsa, dışa aktarma ve evrak üretme gibi izinleri ayrı ayrı veremezsiniz. Bu durumda kullanıcı sayısını mümkün olduğunca dar tutmak kalan tek önlemdir.

    MerkeziHesap bu soruya nasıl cevap veriyor?

    Yetki şirket bazında kurulur: üç rol ve on iki ayrı izin vardır, izinler kullanıcı bazında tek tek değiştirilebilir. SINIR: izinler ekran ve işlem düzeyindedir; “bu kullanıcı yalnızca şu banka hesabını görsün” biçiminde hesap bazlı bir kısıt bugün yoktur. Bunu bilerek yazıyoruz, çünkü olmayan bir yetkiyi varmış gibi anlatmak denetimin kendisini işe yaramaz hale getirir.

  6. İzlenebilirliği test edin

    15 dk

    Kaydı görünmeyen erişim denetlenemez. Kaydın var olması yetmez; sizin de görebilmeniz gerekir.

    Kurulumdan sonra bir manuel senkron başlatın ve ekranda şunu arayın: denemenin tarihi ve saati, sonucu, çekilen hareket sayısı, hata varsa mesajı. Bu satırları göremiyorsanız, hesaplarınıza kaç kez ve ne zaman bağlanıldığını yalnızca tedarikçi biliyor demektir.

    Burada takılırsan

    Kayıtlar yalnızca tedarikçinin kendi sistemlerinde tutuluyorsa, sözleşmeye “talep hâlinde erişim kayıtlarının yazılı olarak verilmesi” maddesi ekletin. Denetim sırasında bu maddenin varlığı, sözlü güvenceden farklı bir ağırlık taşır.

    MerkeziHesap bu soruya nasıl cevap veriyor?

    Her senkron denemesi bir günlük satırı üretir: tetikleyicisi (zamanlanmış, elle başlatılan, ilk kurulum), başlangıç ve bitiş zamanı, işlenen hesap sayısı, oluşturulan hareket sayısı, güncellenen bakiye sayısı ve hata mesajı. Üretilen her banka evrakı da kimin ürettiği ve ne zaman ürettiğiyle birlikte kaydedilir.

  7. Çıkış planını şimdi yazın

    15 dk

    Çıkış yolu olmayan erişim, süresiz erişimdir. İptalin nasıl yapılacağı kurulum günü yazılır.

    Üç satırlık bir not yeterlidir: bankadaki entegrasyon kullanıcısı hangi kanaldan kapatılır, yazılım tarafında bağlantı nasıl durdurulur, sözleşme bitiminde veri ne kadar sürede silinir veya dışa aktarılır. Bu notu kurulum günü yazmak on beş dakika sürer; ihtiyaç anında yazmaya çalışmak günler alır.

    Burada takılırsan

    Tedarikçinin ekranından “bağlantıyı durdur” demek, banka tarafındaki kullanıcının kapatılması demek değildir. İki adımı ayrı ayrı yazın ve ikisinin de sizin yetkinizde olduğundan emin olun.

    MerkeziHesap bu soruya nasıl cevap veriyor?

    Bağlantı istendiği anda duraklatılabilir; duraklatılmış bir bağlantıyı zamanlanmış tur denemez. Banka tarafındaki entegrasyon kullanıcısını kapatma yetkisi her zaman şirkette kalır — kullanıcıyı banka size verdiği için, kapatma talebini de yalnızca siz verebilirsiniz.

İkinci adımda işinizi kısaltan sayfalar

Banka tarafındaki kullanıcı, hesap hareketleri paylaşımı yetki belgesiyle açılır. Belgenin hangi alanının ne anlama geldiğini ve hangi bankanın hangi kanaldan başvuru aldığını ayrı sayfalarda anlattık.

Paylaşım talimatı aracı Hangi bankalar entegrasyon veriyor? Banka entegrasyonu nasıl kurulur?
03

Salt-okunur erişim ne demek?

Kısa cevap: bağlantı veriyi okur, para hareketi başlatamaz — çünkü çağrılabilecek bir uç yoktur.

Salt-okunur erişimde sınır iki kez kurulur. Birincisi banka tarafındadır: entegrasyon için tanımlanan kullanıcının yetkisi hesap hareketi ve bakiye sorgusuyla sınırlıdır, o kullanıcı bankanın sisteminde bir transfer başlatamaz. İkincisi yazılım tarafındadır: MerkeziHesap’ın banka sürücüsü sözleşmesinde para gönderen bir metot tanımlı değildir; bankaya giden beş metodun hepsi okuma yönündedir. İki sınır birbirinin yedeğidir — biri yanlış kurulsa bile diğeri ayakta kalır.

Okuma çağrılarının geçtiği kapı ve yetki sınırına çarpan para hareketi çağrıları Solda yazılımın senkron işi, sağda bankanın entegrasyon servisi vardır. İkisinin arasında bir yetki sınırı çizilmiştir. Sınırın üst bölümünde okuma kapısı açıktır: hesap listesi, hesap hareketleri, bakiye ve dekont sorguları buradan geçip bankaya ulaşır. Sınırın alt bölümü kapalıdır: havale ve EFT talimatı, kredi veya limit başvurusu ve hesap açma çağrıları sınıra çarpar ve bankaya hiç ulaşmaz. Bu çağrılar için sürücü sözleşmesinde tanımlı bir metot da yoktur. YETKİ SINIRI OKUMA KAPISI Yazılımın senkron işi zamanlanmış görev elindeki tek şey entegrasyon kullanıcısı Bankanın servisi entegrasyon kanalı hesap, hareket ve bakiye verisi hesap listesi hesap hareketleri bakiye dekont havale veya EFT talimatı kredi ya da limit başvurusu hesap açma sürücü sözleşmesinde bu metotlar hiç tanımlı değil
Okuma kapısından geçen dört çağrı, sürücü sözleşmesindeki veri çeken metotların karşılığıdır; kapının kendisi beşinci metottur (kimlik doğrulama). Duvara çarpan üç çağrı için sözleşmede metot yoktur; bankadan bu yetkiler talep edilmediği için karşı tarafta da bir uç açılmaz.
Banka sürücüsü sözleşmesinde tanımlı işlemler ve tanımlı olmayan işlemler
İşlem Sözleşmede var mı? Ne işe yarar?
Kimlik doğrulama Var — okuma Bankaya bağlanır; token kullanan bankalarda token alınır, kullanmayanlarda bağlanabilirlik doğrulanır.
Hesap listesi Var — okuma Entegrasyonun yetkili olduğu hesapları döndürür. Yetkisiz hesap bu listede zaten görünmez.
Hesap hareketleri Var — okuma Verilen tarih aralığındaki hareketleri okur. Aralık bankaya göre bölünür; çoğu banka 31 günden uzun aralığı reddeder.
Bakiye Var — okuma Hesabın güncel bakiyesini okur.
Dekont indirme Var — okuma Bir hareketin dekont belgesini indirir.
Geriye dönük veri politikası Var — okuma Bankanın ne kadar geriye izin verdiğini söyler; banka çağrısı değildir.
Para transferi (havale, EFT, ödeme) Yok Sözleşmede böyle bir metot yok. Bankadan bu yetki de talep edilmez.
Kredi veya limit başvurusu Yok Sözleşmede böyle bir metot yok.
Hesap açma veya kapatma Yok Sözleşmede böyle bir metot yok.
Müşteri bilgisi güncelleme Yok Sözleşmede böyle bir metot yok; banka tarafındaki hiçbir kayıt değiştirilmez.

Tablodaki “yok” satırları bir söz değil, kodun durumudur: bu işlemler için sürücü sözleşmesinde metot bulunmadığından, çağırmak isteyen bir kod yazılsa bile çağıracağı bir uç yoktur.

04

Kimlik bilgisi nasıl saklanır?

Kısa cevap: şifreli olarak saklanır, arayüze ve API cevabına hiç girmez, hata kayıtlarında maskelenir ve yalnızca bankaya bağlanılan anda bellekte çözülür.

Bankanın verdiği entegrasyon kullanıcı bilgisi kurulum sırasında bir kez girilir ve veritabanına uygulama anahtarıyla şifrelenmiş olarak yazılır. Alan modelde gizli olarak işaretlidir: kayıt diziye çevrildiğinde, arayüze veri taşınırken ve API cevabı üretilirken alanın kendisi çıktıya hiç girmez. Bu, “ekranda yıldızla gösteriyoruz” demekten farklıdır — yıldızlı gösterim değerin gönderildiği, sadece görünmediği anlamına gelir; burada değer gönderilmez.

Banka kimlik bilgisinin kurulumdan bankaya kadar izlediği yol ve kesilen üç çıkış Üst sırada dört kutu soldan sağa şu yolu gösterir: kurulum formunda banka kullanıcı bilgisi girilir, uygulama anahtarıyla şifrelenir, veritabanında şifreli metin olarak durur ve yalnızca senkron anında bellekte çözülür. Veritabanı kutusundan aşağı inen dağıtım hattında üç çıkış vardır ve üçü de kesilmiştir: arayüz ve ekranlara alan hiç gönderilmez, API cevabında gizli alan olduğu için çıktıya girmez, hata kayıtlarında değer üç yıldızla maskelenir. Kurulum formu banka kullanıcı bilgisi girilir Şifreleme uygulama anahtarıyla Veritabanı şifreli metin olarak durur Senkron anı yalnızca bellekte çözülür değer buradan sonra bir daha okunamaz Arayüz ve ekranlar alan hiç gönderilmez API cevabı gizli alan, çıktıya girmez Hata kaydı (log) değer *** ile maskelenir
Kesilen üç çıkış aynı riski kapatır: kimlik bilgisinin sistemden dışarı sızabileceği üç doğal yol arayüz, API cevabı ve hata kayıtlarıdır. Üçü de ayrı ayrı kapatılmadıkça şifreli saklamanın tek başına faydası sınırlı kalır.

Şifreli saklama

Kimlik bilgileri veritabanına uygulama anahtarıyla şifrelenmiş olarak yazılır. Veritabanı kopyasını eline geçiren biri, anahtar olmadan bu alanı okuyamaz.

Çıktıya hiç girmez

Alan modelde gizli olarak işaretlidir. Kayıt diziye çevrildiğinde, arayüze veri taşınırken ve API cevabı üretilirken alan çıktıya eklenmez; yıldızlanmış hâli bile gönderilmez.

Log’da maskelenir

Senkron katmanının tek log kapısı vardır. Adında parola, token, secret, sertifika, müşteri numarası gibi 19 hassas parçadan biri geçen her anahtarın değeri, iç içe dizilerde de aranarak *** ile değiştirilir.

Bu sayfa şifreleme algoritmasının adını ve anahtar uzunluğunu vermez: bu değerler uygulamanın çalışma zamanı yapılandırmasına bağlıdır ve sayfaya yazılan bir sayı yapılandırma değiştiğinde sessizce yanlışa döner. Denetimde sorulması gereken soru algoritmanın adı değil, anahtarın nerede durduğu ve değerin hangi anda çözüldüğüdür.

05

Parolasız giriş neden daha güvenli?

Kısa cevap: kalıcı parola olmayınca çalınabilecek kalıcı bir sır da olmaz.

Kalıcı parolanın asıl sorunu tahmin edilebilir olması değil, tekrar tekrar kullanılmasıdır. Aynı parola not defterine yazılır, ekipçe paylaşılır, başka sitelerde yeniden kullanılır ve bir gün başka bir sitenin sızıntısında ortaya çıkar. Banka hareketlerinizi gösteren ekranın kapısı, o hareketler kadar korunmalıdır. Tek kullanımlık kod bu zinciri baştan keser: ortada saklanacak, paylaşılacak veya sızacak sürekli bir sır yoktur.

Kalıcı parola ile tek kullanımlık e-posta kodunun karşılaştırması
Konu Kalıcı parola Tek kullanımlık e-posta kodu
Sırrın ömrü Değiştirilene kadar geçerli; aylarca, bazen yıllarca. Kod 10 dakika sonra geçersizleşir.
Tekrar kullanım Aynı parola başka sitelerde de kullanılır; bir sızıntı hepsini açar. Kod bir kez kullanılır, ikinci kez çalışmaz.
Paylaşılabilirlik Ekip içinde paylaşılır ve kimin girdiği belirsizleşir. Kod kişinin e-posta kutusuna düşer; paylaşmak için e-postayı paylaşmak gerekir.
Deneme sınırı Ürüne göre değişir. Bir kod için en fazla 5 yanlış deneme; sınır aşılınca kod yakılır.
Saklanma biçimi Doğru uygulamada hash’lenir, yanlış uygulamada düz metin kalır. Kod düz metin saklanmaz; doğrulama hash karşılaştırmasıyla yapılır.
Amaç ayrımı Tek parola her işe yarar. Giriş için üretilen kod e-posta değiştirmede, e-posta değiştirme kodu girişte kullanılamaz.

Parolasız giriş her riski kapatmaz: e-posta kutusunun kendisi ele geçirilirse kod da ele geçirilir. Bu yüzden şirket e-postalarında iki adımlı doğrulama, parolasız girişin tamamlayıcısıdır — alternatifi değil.

06

Şirket içinde kim neyi görebilir?

Kısa cevap: görünürlüğü tedarikçi değil şirket yöneticisi belirler; 3 rol ve 12 ayrı izin vardır, izinler kullanıcı bazında tek tek değiştirilebilir.

Banka hareketleri maaş bilgisi, tedarikçi fiyatı ve müşteri listesi taşır; şirket içindeki görünürlük bu yüzden dışarıdan gelen riskten daha az önemli değildir. Aşağıdaki tablo rollerin varsayılan izin setidir. Bir kullanıcıya izin tek tek verildiğinde rolün varsayılanı devre dışı kalır ve yalnızca verilen izinler geçerli olur.

Rollerin varsayılan izin setleri
İzin Şirket sahibi Yönetici Çalışan
Banka hesaplarını görüntüleme
Banka hesaplarını yönetme —
Hesap hareketlerini görüntüleme
Hesap hareketlerini dışa aktarma —
Raporları görüntüleme
Evrakları görüntüleme
Evrak üretme —
Banka entegrasyonlarını görüntüleme
Banka entegrasyonlarını yönetme —
Ekibi görüntüleme
Ekibi yönetme (davet ve yetki) — —
Şirket bilgilerini yönetme — —
Varsayılan izin sayısı 12 10 6

Grup şirketlerinde ayrım nerede yapılır?

Şirketler arası ayrım arayüzde değil veri katmanında uygulanır: kiracı verisine erişen her sorgu aktif şirkete daraltılır ve bir kaydın şirket kimliği istek gövdesinden alınamaz, sonradan da değiştirilemez. Ayrım fail-closed çalışır — aktif şirket bağlamı kurulamazsa sorgu her şeyi değil hiçbir şeyi döndürür. Bir hata anında doğru sonuç boş ekrandır, başka şirketin verisi değil.

Bugün yapamadığımız şey

İzinler ekran ve işlem düzeyindedir: “bu kullanıcı yalnızca şu banka hesabını görsün” biçiminde hesap bazlı bir kısıt bugün yoktur. Hesap hareketlerini görme izni verilen kullanıcı, o şirketin entegrasyona bağlı hesaplarının tamamını görür. Bunu bilerek yazıyoruz: olmayan bir yetkiyi varmış gibi anlatmak, denetimin kendisini işe yaramaz hâle getirir.

07

İzlenebilirlik ve kendiliğinden duran erişim

Kısa cevap: her senkron denemesi ayrı bir günlük satırı üretir ve kimlik hatası alan bir bağlantı kendiliğinden durur — kimsenin müdahalesi gerekmez.

Bir erişimin güvenli sayılması için iki şey gerekir: ne zaman kullanıldığının kaydı ve yanlış giden durumda kendiliğinden durması. Kayıt olmadan denetim yapılamaz; kendiliğinden durma olmadan ise bozulmuş bir bağlantı, banka tarafındaki kullanıcıyı kilitleyene kadar denemeye devam eder.

Her senkron denemesinde kaydedilenler

  • Tetikleyicisi: zamanlanmış tur, elle başlatılan senkron ya da ilk kurulum
  • Başlangıç ve bitiş zamanı
  • Sonucu: başarılı, kısmi, başarısız ya da hâlâ çalışıyor
  • İşlenen hesap sayısı
  • Oluşturulan hareket sayısı
  • Güncellenen bakiye sayısı
  • Varsa hata mesajı

Evrak üretiminde kaydedilenler

Banka başvuru evrakları şirket bilgilerinden üretilir ve üretilen her belge, kimin ürettiği ve ne zaman ürettiğiyle birlikte kaydedilir. Evrak üretme ayrı bir izindir: görüntüleme izni olan bir kullanıcı, evrak üretme izni verilmediği sürece yeni belge üretemez.

Bu ayrım denetimde işe yarar: bir belgenin ne zaman ve kim tarafından üretildiği sorulduğunda cevap hafızada değil kayıtta durur.

Banka bağlantısının durum makinesi ve erişimin durduğu geçişler Bağlantının dört durumu vardır. Aktif durumda zamanlanmış tur çalışır. Geçici veya kimlik dışı bir hata bağlantıyı hata durumuna alır; tur denemeye devam eder ve sonraki tur başarılı olursa bağlantı aktife döner. Kimlik hatası alındığında bağlantı ilk denemede doğrudan kimlik hatası durumuna geçer ve zamanlanmış tur bir daha denemez. Kimlik dışı hatalarda sayaç işler ve arka arkaya onuncu hatada bağlantı yine kimlik hatası durumuna kilitlenir. Kullanıcı bağlantıyı istediği anda duraklatabilir ve duraklatılmış bağlantıda da tur denemez. aktif tur çalışır hata tur denemeye devam eder kimlik hatası tur artık denemez duraklatıldı tur denemez hata alındı sonraki tur başarılı arka arkaya 10. hata kimlik hatası: ilk denemede kullanıcı durdurur ya da sürdürür buradan çıkış elle yapılır: yeni kimlik bilgisi girilmeden bağlantı kendiliğinden açılmaz
Geçici ağ kesintileri (DNS hatası, zaman aşımı, bankanın geçici servis hatası) bağlantıyı hata durumuna alır ama ardışık hata sayacını artırmaz. Böylece uzun bir kesinti, çalışan bir bağlantıyı kimlik hatası durumuna kilitlemez; kesinti bitince tur kaldığı yerden devam eder.
08

Sayısal örnek: erişim ne kadar sürede durur?

Kısa cevap: banka kimlik bilgisi geçersizleştiğinde erişim en geç bir tur içinde, yani 15 dakikada durur; kimlik hatası vermeyen bozulmalarda ise 2 saat 30 dakika içinde kilitlenir.

Örnek şirket üç bankayla çalışıyor, üç bağlantının üçü de en sık aralıkta (15 dakika) kurulu ve otomatik turlar 07:00–22:00 arasında dönüyor. Bu değerler uydurma değil, ürünün gerçek sınırlarıdır: 15 dakika seçilebilecek en sık aralıktır ve gece turu hiç dönmez.

  1. 01Günlük senkron penceresi 07:00 – 22:00 15 saat = 900 dakika
  2. 02Bağlantı başına günlük tur 900 ÷ 15 60 tur
  3. 03Üç bağlantı için günlük kayıt 60 × 3 180 günlük satırı
  4. 04Yıllık kayıt 180 × 365 65.700 satır
  5. 05Kimlik hatasında duruş ilk başarısız tur en geç 15 dakika
  6. 06Kimlik dışı hatada kilitlenme 10 × 15 dakika 150 dakika = 2 saat 30 dakika

Senaryo A

Banka kullanıcısı kapatıldı veya şifresi değişti

Banka kimlik hatası döner. Bağlantı ilk başarısız turda kimlik hatası durumuna alınır, zamanlanmış tur bir daha denemez. Erişim en geç 15 dakika içinde durur ve yeni kimlik bilgisi girilmeden kendiliğinden açılmaz.

Senaryo B

Bankanın servisi bozuk cevap dönüyor

Hata kimlik hatası olarak sınıflanmadığı için sayaç işler. Her turda bir artar; arka arkaya 10. hatada bağlantı kimlik hatası durumuna kilitlenir. Pencere içinde bu 150 dakika, yani 2 saat 30 dakika eder.

Senaryo C

Ağ kesintisi ya da zaman aşımı

Geçici hata olarak sınıflanır: bağlantı hata durumuna geçer ama sayaç artmaz. Kesinti ne kadar sürerse sürsün bağlantı kilitlenmez, kesinti bitince tur kaldığı yerden devam eder.

Örnekteki tur sayıları en sık aralık ve kesintisiz bir gün varsayımıyla hesaplandı; gerçek sayı seçilen aralığa, bağlantı sayısına ve o gün yaşanan kesintilere göre değişir. Hesabın amacı kesin bir rakam vermek değil, “erişim ne kadar sürede kendiliğinden durur” sorusunun ölçülebilir bir cevabı olduğunu göstermektir.

09

Neyi yapmıyoruz?

Bir güvenlik sayfasının en kolay yanlışı, ürünün ne yaptığını uzun uzun anlatıp ne yapmadığını hiç söylememesidir. Aşağıdaki maddeler ürünün kapsam sınırıdır ve sözleşme görüşmesinde de aynı biçimde geçerlidir.

Para göndermiyoruz

Banka sürücüsü sözleşmesinde transfer, ödeme veya talimat metodu tanımlı değildir. Entegrasyon kurulurken bankadan para transferi yetkisi de talep edilmez.

Kredi, limit veya ürün başvurusu yapmıyoruz

Sistem bankada bir ürün açmaz, limit talep etmez, sözleşme imzalamaz. Yaptığı tek şey mevcut hesapların hareketlerini ve bakiyelerini okumaktır.

Verinizi üçüncü taraflara satmıyoruz

Hesap hareketleriniz reklam, skorlama veya pazar araştırması amacıyla kullanılmaz ve üçüncü taraflara satılmaz.

Muhasebeleştirme yapmıyoruz

MerkeziHesap fatura kesmez, cari hesap işletmez, muhasebe fişi üretmez. Banka tarafını doğru ve eksiksiz hâle getirir; kayıt işini muhasebe programınız yapmaya devam eder.

Üçüncü taraf izleme betiği çalıştırmıyoruz

Bu sitedeki sayfalarda reklam ağı, ısı haritası satıcısı veya dış analitik betiği yoktur. Bu sayfadaki denetim listesi de dahil olmak üzere araçlar tarayıcınızda çalışır; işaretlediğiniz cevaplar sunucuya gönderilmez.

Bu sayfa ayrıca herhangi bir sertifika, bağımsız denetim ya da uyumluluk iddiasında bulunmaz. Anlatılan her davranışın çalışan koddaki bir karşılığı vardır; doğrulanamayan bir rozet koymak, tam da bu sayfanın uyardığı satıcı dilidir.

10

Açık bankacılıkla aynı şey mi?

Kısa cevap: hayır. İkisi farklı yollardır; bu sayfadaki entegrasyon bankanın kurumsal kanalından, imzalı bir yetki belgesiyle kurulur.

Türkiye’de “hesap bilgisi hizmeti”, 6493 sayılı Ödeme ve Menkul Kıymet Mutabakat Sistemleri, Ödeme Hizmetleri ve Elektronik Para Kuruluşları Hakkında Kanun’da 2019 yılında yapılan değişiklikle ödeme hizmetleri arasına alınmıştır ve bu hizmeti sunmak yetkilendirmeye tabidir. Bu yol, bankaların veri paylaşım servisleri üzerinden yürüyen ayrı bir düzenleme alanıdır.

MerkeziHesap bu yolu kullanmaz ve böyle bir yetki iddiasında bulunmaz. Kurumsal banka entegrasyonu, bankanın kendi kurumsal müşterilerine sunduğu entegrasyon kanalıdır: başvuru şirketin imzaladığı hesap hareketleri paylaşımı yetki belgesiyle yapılır, entegrasyon kullanıcı bilgisini banka üretip şirkete iletir. Paylaşımın dayanağı şirketin kendi yazılı talimatıdır — bankaların yayımladığı talimat örneklerinde bu nedenle 5411 sayılı Bankacılık Kanunu’nun 73. maddesine ve 6698 sayılı Kişisel Verilerin Korunması Kanunu’na atıf yapılır.

Kurumsal banka entegrasyonu ile hesap bilgisi hizmetinin karşılaştırması
Konu Kurumsal banka entegrasyonu (bu sayfa) Hesap bilgisi hizmeti (açık bankacılık)
Kimin talebiyle başlar Şirketin bankaya verdiği imzalı yetki belgesiyle. Müşterinin bankanın kendi kanalında verdiği onayla.
Kimlik bilgisini kim üretir Banka, entegrasyon için ayrı kullanıcı bilgisi üretir. Kimlik bilgisi paylaşılmaz; onay bankanın kanalından verilir.
Yetkilendirme gerekir mi Hizmeti alan şirket ile banka arasındaki sözleşmeye dayanır. Hizmeti sunmak yetkilendirmeye tabidir.
Kapsam Bankanın entegrasyon kanalının verdiği hesap, hareket, bakiye ve dekont verisi. Düzenlemenin ve bankanın servisinin kapsadığı hesap bilgileri.
MerkeziHesap bu yolu kullanıyor mu Evet. Hayır.

Tablo iki yolu ayırmak için yazıldı; hangisinin sizin için uygun olduğu hukuki bir değerlendirme gerektirir ve bu sayfa hukuki tavsiye vermez. Kanun adları ve numaraları kaynaklar bölümünde listelidir.

11

Sık sorulan sorular

Güvenliği belirleyen şey entegrasyonun kendisi değil, talep edilen yetkinin kapsamıdır. Yalnızca hesap hareketi ve bakiye okuyan, bankanın bu iş için ayrıca ürettiği bir kullanıcıyla kurulan ve kimlik bilgisini şifreli saklayan bir entegrasyonda para çıkışı riski yoktur. İnternet şubesi parolanızı isteyen ya da para transferi yetkisi talep eden bir kurulum ise ölçüsüz risk taşır.

Evet. Bankalar hesap hareketi paylaşımı için internet şubesi parolasından ayrı bir entegrasyon kullanıcısı tanımlar; başvuru imzalı bir yetki belgesiyle yapılır ve kullanıcı bilgisini banka üretip size iletir. İnternet şubesi parolanızı vermeniz gereken bir kurulum, doğru kurulum değildir.

Salt-okunur banka erişimi, bağlantının yalnızca veri okuyabildiği, para hareketi başlatamadığı erişim biçimidir. Yazılım hesap listesini, hesap hareketlerini, bakiyeyi ve dekontu okur; havale, EFT, ödeme talimatı veya hesap açma gibi bir işlem yapamaz.

Risk, verilen yetkinin kapsamıyla doğru orantılıdır. Okuma yetkisiyle sınırlı bir entegrasyon kullanıcısı vermek ile internet şubesi parolasını paylaşmak aynı şey değildir. Kararı vermeden önce sorulacak asgari sorular şunlardır: hangi yetkiler talep ediliyor, kimlik bilgisi nasıl saklanıyor, kim neyi görebiliyor, erişim nasıl iptal ediliyor.

MerkeziHesap’ta banka kimlik bilgileri veritabanına uygulama anahtarıyla şifrelenmiş olarak yazılır, modelde gizli alan olarak işaretlidir ve arayüze ya da API cevabına hiç girmez. Yalnızca bankaya bağlanılan anda bellekte çözülür; hata kayıtlarında parola, token ve müşteri numarası gibi alanların değeri maskelenir.

Hayır. Entegrasyon salt-okunur kurulur ve banka sürücüsü sözleşmesinde para gönderen bir metot tanımlı değildir. Bankadan da para transferi yetkisi talep edilmez.

Kalıcı parola, çalınabilecek ve başka sitelerde tekrar kullanılabilecek sürekli bir sırdır. Tek kullanımlık kod ise kısa sürede geçersizleşir, bir kez kullanılır ve yanlış deneme sınırı aşılınca yakılır; sızdırılabilecek kalıcı bir sır ortada kalmaz.

Görünürlüğü şirket yöneticisi belirler. MerkeziHesap’ta üç rol ve on iki ayrı izin vardır; izinler kullanıcı bazında tek tek verilebilir. İzinler ekran ve işlem düzeyindedir: “yalnızca şu banka hesabını görsün” biçiminde hesap bazlı kısıt bugün yoktur.

Hayır. Kiracı ayrımı arayüzde değil veri katmanında uygulanır ve fail-closed çalışır: aktif şirket bağlamı kurulamadığında sorgu her şeyi değil hiçbir şeyi döndürür. Kullanıcı yalnızca üyesi olduğu şirketin verisini görür.

Kimlik hatası alan bağlantı ilk denemede kimlik hatası durumuna alınır ve zamanlanmış tur bir daha denemez; erişim kendiliğinden durur. Kimlik hatası olmayan başarısızlıklarda sayaç işler ve arka arkaya onuncu hatada bağlantı yine kilitlenir. Geçici ağ kesintileri bu sayacı artırmaz.

Evet. Her senkron denemesi ayrı bir günlük satırı üretir: tetikleyicisi, başlangıç ve bitiş zamanı, işlenen hesap sayısı, oluşturulan hareket sayısı ve varsa hata mesajı. Üretilen her banka evrakı da kimin ne zaman ürettiğiyle birlikte kaydedilir.

Hayır. MerkeziHesap, bankaların kurumsal müşterilerine sunduğu kendi entegrasyon kanalını kullanır: başvuru imzalı yetki belgesiyle yapılır, kimlik bilgisini banka üretir. Bu, 6493 sayılı Kanun kapsamında yetkilendirmeye tabi olan hesap bilgisi hizmetinden farklı bir yoldur ve MerkeziHesap böyle bir yetki iddiasında bulunmaz.

Hayır. Hesap hareketleriniz reklam, skorlama veya pazar araştırması amacıyla kullanılmaz ve üçüncü taraflara satılmaz. Bu sitedeki sayfalarda üçüncü taraf analitik veya reklam betiği de çalışmaz.

Bu sayfa herhangi bir sertifika, bağımsız denetim veya uyumluluk iddiasında bulunmaz. Anlatılan her davranış ürünün çalışan kodundaki karşılığıdır; doğrulanamayan bir rozeti sayfaya koymak, tam da bu sayfanın uyardığı satıcı dilidir.

12

Kaynaklar

  • 5411 sayılı Bankacılık Kanunu (2005), 73. madde — “Sırların saklanması”

    Banka ve müşteri sırrı niteliğindeki bilgilerin paylaşılmasının sınırlı olduğu kural. Bankaların yayımladığı hesap hareketleri paylaşımı yetki belgelerinde, paylaşımın dayanağı olarak bu madde gösterilir. Sayfada kanunun yorumu yapılmaz, belgelerdeki atıf aktarılır.

    Erişim: 29 Ağustos 2026

  • 6698 sayılı Kişisel Verilerin Korunması Kanunu (2016)

    Hesap hareketlerinin kişisel veri içerdiği durumlarda geçerli olan çerçeve. Banka talimat örneklerindeki muvafakat paragrafları bu kanuna atıf yapar. Bu sayfa uyumluluk iddiası taşımaz; tedarikçiye sorulacak sorular listesinde verinin nerede saklandığı ve alt yüklenici listesi bu nedenle yer alır.

    Erişim: 29 Ağustos 2026

  • Anadolubank A.Ş. hesap hareketleri paylaşımı talimat örneği (Luca üzerinden yayımlanmış)

    Yetki belgesinin, 6698 sayılı Kanun ile 5411 sayılı Bankacılık Kanunu’nun 73/4 maddesine atıflı muvafakat paragrafı içerdiği; hesap listesi ve “tüm hesaplarım” seçeneği; şube imza-kaşe alanı. Belgenin varlığı, paylaşımın müşterinin yazılı talimatına dayandığının kanıtıdır.

    Erişim: 29 Ağustos 2026

  • 6493 sayılı Ödeme ve Menkul Kıymet Mutabakat Sistemleri, Ödeme Hizmetleri ve Elektronik Para Kuruluşları Hakkında Kanun (2013)

    Kanunda 2019 yılında yapılan değişiklikle “ödeme emri başlatma hizmeti” ve “hesap bilgisi hizmeti” ödeme hizmetleri arasına alındı; bu hizmetleri sunmak yetkilendirmeye tabidir. Sayfada yalnızca BAĞLAM olarak anılır: MerkeziHesap bu yolu kullanmaz ve böyle bir yetki iddiasında bulunmaz.

    Erişim: 29 Ağustos 2026

  • MerkeziHesap kaynak kodu — banka sürücüsü sözleşmesi ve senkron katmanı

    Sayfadaki ürün iddialarının dayanağı: sürücü arayüzündeki metot listesi, kimlik bilgisinin şifreli ve gizli alan olarak tanımlanması, günlük maskeleme listesi, entegrasyon durum makinesi ve ardışık hata eşiği, senkron günlüğü alanları, izin ve rol kataloğu, kiracı kapsamının fail-closed davranışı.

    Doğrulama: 29 Ağustos 2026

Sayfadaki ürün sayıları (izin ve rol matrisi, ardışık hata eşiği, en sık senkron aralığı, senkron penceresi, kodun geçerlilik süresi ve yanlış deneme sınırı) elle yazılmadı; çalışan koddan okunur ve kod değiştiğinde sayfa kendiliğinden düzelir. Kanun ve belge atıfları son olarak tarihinde doğrulandı. Bu sayfa hukuki tavsiye içermez.

İlgili sayfalar

Erişim modelini onayladıktan sonraki sorular ayrı sayfalarda: hareketlerin ne kadar süre saklanacağı, hangi bankanın hangi kanaldan entegrasyon verdiği ve yetki belgesinin nasıl doldurulduğu.

Hesap hareketleri ne kadar saklanır? Hangi bankalar entegrasyon veriyor? Paylaşım talimatı aracı Banka entegrasyonu

Terimler: salt-okunur banka erişimi, uygulama anahtarı, ardışık hata eşiği, kiracı izolasyonu.