Toplu E-İmza Kuyruğu Güvenli Nasıl Yönetilir?

Toplu e-imza kuyruğu nasıl güvenli tutulur?

Her imza işini belge özeti, sürüm, imzalayan ve tekil işlem anahtarıyla sabitleyin; yetkiyi tüketim anında doğrulayın, tekrarları tekilleştirin ve yalnız doğrulanmış çıktıyı başarı sayın.

Yoğunluk arttığında amaç kuyruğu yalnız hızlandırmak değildir. Aynı belgenin iki kez imzalanmasını, değişmiş bir PDF'nin eski onayla ilerlemesini, geçici servis hatasının kalıcı başarı gibi görünmesini ve imza kanıtının iş kaydından kopmasını önleyen bir durum makinesi gerekir.

İmza işi kuyruğa hangi kimlikle alınmalı?

İş kimliği yalnız dosya adına değil; belge kimliği, değişmez sürüm, kriptografik özet, imzalayan kimliği, imza politikası ve amaçlanan işlem türüne dayanmalıdır.

BTK'nın 5070 sayılı Kanun çerçevesini açıklayan güncel sayfası, güvenli elektronik imzanın imzalanmış veride sonradan değişiklik tespitine imkân verdiğini belirtir. BTK'nın teknik SSS içeriği de imzalanacak verinin imza sahibince imza öncesinde görülebilmesi ve imza oluşturma verisinin araç dışına çıkarılmaması sınırlarını açıklar. Kuyruk tasarımının sonucu nettir: kullanıcı bir sürümü onayladıktan sonra PDF yeniden üretilirse aynı iş devam etmemeli, yeni özetle yeni onay açılmalıdır. [1] [2]

Kuyrukta hangi durumlar birbirinden ayrılmalı?

“Bekliyor, başarılı, hatalı” üçlüsü yetersizdir; kabul, ön kontrol, insan onayı, imza, doğrulama, arşiv ve inceleme durumları ayrı olmalıdır.

1. Kabul edildi: Kaynak belge, sürüm, özet ve idempotency anahtarı atomik olarak kaydedilir.
2. Ön kontrol: Belge erişimi, format, sahiplik, imzalayan rolü, sertifika seçimi ve politika uygunluğu denetlenir.
3. Onay bekliyor: İmza sahibi, imzalanacak belgenin doğru sürümünü görür ve belirli işlem için onay verir.
4. İmzalanıyor: Worker kısa süreli bir iş kilidiyle görevi alır; kilit süresi dolsa bile idempotency kaydı ikinci yan etkiyi önler.
5. Doğrulanıyor: Oluşan imza, imzalanan belge ve sertifika bağlamında teknik olarak doğrulanır.
6. Arşivlendi: İmzalı çıktı, doğrulama sonucu, zaman damgası kanıtı ve işlem izi aynı kayıt bağında saklanır.
7. İnceleme gerekli: Belirsiz doğrulama, kalıcı hata veya çelişki otomatik başarıya çevrilmeden yetkili kişiye atanır.

OWASP işlem yetkilendirme rehberi, anlamlı işlem verisinin sunucuda korunmasını, adımların sırayla yürütülmesini ve her işlem için benzersiz yetkilendirme bağını önerir. Bu, kuyruk tüketicisinin tarayıcıdan gelen bir “onaylandı” alanına güvenmemesi; belge özeti, yetki ve durum geçişini sunucu kaydından yeniden doğrulaması anlamına gelir. [5]

Yeniden deneme çift imza üretmeden nasıl yapılır?

Yalnız geçici hataları sınırlı ve gecikmeli yeniden deneyin; her denemeyi aynı idempotency anahtarına bağlayın ve harici imza sonucunu atomik olarak kaydedin.

OWASP Business Logic Security rehberi, harici ve durum değiştiren çağrılar için idempotency anahtarının sonuçla birlikte işlemsel olarak saklanmasını önerir. Worker imza servisine isteği gönderdikten sonra ağ bağlantısı kesilirse “cevap gelmedi, işlem olmadı” varsayımı tehlikelidir. Önce aynı iş anahtarıyla kayıtlı sonuç veya sağlayıcı işlem kimliği sorgulanmalı; ancak işlemin oluşmadığı kanıtlanırsa yeniden gönderilmelidir. [4]

Hataları sınıflandırın: kısa süreli bağlantı kesintisi ve hizmetin açıkça bildirdiği geçici yoğunluk yeniden denenebilir; yetkisiz kullanıcı, değişmiş belge özeti, geçersiz sertifika seçimi veya doğrulama başarısızlığı otomatik tekrar edilmemelidir. Gecikmeli tekrarlar artan bekleme ve rastgele sapma kullanabilir; ancak deneme sayısı ile toplam süre kuruluşun hizmet hedefi ve risk değerlendirmesine göre belirlenmeli, kaynaksız evrensel sayı ilan edilmemelidir.

İş ne zaman gerçekten başarılı sayılır?

İmzalı dosyanın oluşması tek başına başarı değildir; imza değeri, belge bağı, imza sertifikası, doğrulama politikası ve gerekiyorsa zaman damgası sonucu birlikte kaydedilmelidir.

ETSI EN 319 102-1 V1.4.1, AdES oluşturma ve doğrulama süreçlerinin girdilerini ve sonuçlarını tanımlar; doğrulama sonucunda başarılı, başarısız ve belirsiz durumların aynı şey olmadığını gösterir. VizyonTech iş akışında worker yalnız dosya yazıldığı için işi kapatmamalı; kullanılan doğrulama kuralını ve sonucu saklamalı, başarısız veya belirsiz sonucu inceleme kuyruğuna taşımalıdır. [3]

RFC 3161, zaman damgasını bir verinin belirli bir zamandan önce var olduğuna dair kanıt sağlayan istek-cevap protokolü olarak tanımlar. Bu nedenle zaman damgası gerekiyorsa yalnız “istendi” kaydı tutulmamalı; message imprint, cevap durumu, dönen token ve doğrulama sonucu aynı imza işiyle bağlanmalıdır. Eşleşmeyen nonce veya belge özeti, gecikmiş cevap ya da reddedilmiş istek başarı sayılmamalıdır. [6]

Uzun dönem doğrulama ihtiyacı format, politika ve saklama süresine bağlıdır. Her imzaya aynı arşiv profilini varsaymak yerine kuruluş prosedürü ve geçerli teknik kriterler sürümlü bir politika olarak uygulanmalıdır.

Yoğunluk sistemi ve imza sahibini nasıl korumalı?

Kabul hızı imzalama kapasitesini aştığında sınırsız iş biriktirmeyin; müşteri/kuruluş bazlı kota, öncelik, backpressure ve görünür yaşlanma metrikleri uygulayın.

• Adil kapasite: Tek müşterinin büyük paketi diğer kuruluşların işlerini süresiz bekletmemeli; tenant ve öncelik sınırları açık olmalıdır.
• Backpressure: Kuyruk belirlenen operasyonel eşiğe geldiğinde yeni paket kabulü yavaşlatılmalı veya planlı zamana alınmalıdır.
• İş süresi görünürlüğü: Ortalama tek başına yeterli değildir; en eski bekleyen iş, durum başına yaş, tekrar sayısı ve inceleme kuyruğu ayrı izlenmelidir.
• Kısa kilit, kalıcı kayıt: Worker kilidi geçici; iş kimliği, deneme geçmişi ve sonuç kalıcı olmalıdır.
• Güvenli gözlem: Loglarda belge içeriği, erişim verisi, PIN, özel anahtar veya gereksiz kişisel veri bulunmamalıdır.
• Kontrollü iptal: Henüz imzalanmamış iş iptal edilebilir; imza oluştuysa çıktı silinmeden durum ve dağıtım kararı yetkili incelemeye alınır.

Canlıya almadan önce hangi senaryolar test edilmeli?

Yalnız başarılı akışı değil, worker çökmesi, zaman aşımı, çift teslim, belge değişikliği, yetki kaybı ve belirsiz doğrulama senaryolarını kanıtlı olarak çalıştırın.

• Aynı idempotency anahtarı eşzamanlı iki istekle geldiğinde tek imza çıktısı oluşuyor mu?
• İmza çağrısı tamamlanıp cevap kaybolduğunda tekrar, kayıtlı sonucu buluyor mu?
• Onaydan sonra belge değişirse özet kontrolü işi durduruyor ve yeni onay istiyor mu?
• İmzalayanın rolü veya sertifika durumu bekleme sırasında değişirse tüketici bunu yeniden değerlendiriyor mu?
• Doğrulama sonucu belirsiz olduğunda sistem başarılı teslim bildirimi göndermiyor mu?
• Hata kuyruğundaki iş, neden ve önceki denemeler korunarak yetkili kişi tarafından yeniden başlatılabiliyor mu?
• Arşiv kaydı imzalı çıktı, doğrulama sonucu, zaman damgası ve işlem izini aynı sürüm altında gösterebiliyor mu?

VizyonTech bu akışı nasıl ele alır?

VizyonTech, rapor üretiminden insan onayına, e-imza kuyruğundan doğrulama ve arşive kadar adımları kuruluşun rol, belge sürümü ve istisna kurallarıyla birlikte yapılandırır.

Toplu imza tasarımında önce gerçek belge türlerini, imzalayan rollerini, sertifika ve zaman damgası politikasını, hizmet kesintisi senaryolarını ve teslim kanallarını çıkarırız. Ardından tekil iş kimliği, izinli durum geçişleri, tekrar davranışı, inceleme kuyruğu ve görünür operasyon ölçülerini pilot bir belge akışında doğrularız.

İmzalanmış bir raporun daha sonra nasıl düzeltileceğini e-imzalı rapor revizyonu rehberinde, son kullanıcının güncel çıktıyı nasıl kontrol edeceğini ise rapor doğrulama sayfası rehberinde ele alıyoruz. Kuruluşunuzun belge hacmi ve hata senaryolarıyla güvenli pilot planlamak için VizyonTech ile iletişime geçebilirsiniz.