Üniversite etkinliklerinde yoklama nasıl doğrulanır: QR sahteciliğine karşı katmanlı tasarım

Bir kulüp etkinliğinde 180 kişilik salonda 240 yoklama kaydı çıktığında sorun yoklama sisteminde değil, yoklamanın tasarımındadır. Kâğıt listede imza taklit edilir, sabit QR kodunun ekran görüntüsü gruba düşer, kapıda kimin okuttuğunu kimse kontrol etmez. Katılım verisi bir kere şüpheli hale geldiğinde, o veriye dayanan her rapor da şüphelidir.

Bu yazı, kampüs etkinliklerinde yoklamanın hangi saldırılara açık olduğunu ve her saldırıyı hangi teknik katmanın kapattığını anlatıyor. Sonda mahremiyet maliyetine de bakıyoruz, çünkü güvenliği artırdığını sandığınız bazı önlemler aslında yalnızca hukuki risk üretiyor.

Kâğıt yoklama neden savunulamaz bir kayıttır?

Kâğıt liste, doğrulanabilirliği sıfır olan bir kayıttır. İmzanın kime ait olduğunu kimse kontrol etmez, listeye sonradan satır eklenebilir, kayıp bir sayfa tüm etkinliğin verisini yok eder. Dahası, kâğıdın dijitalleştirilmesi dönem sonuna bırakıldığında veri girişini yapan kişi okunmayan isimleri tahmin etmeye başlar.

Kâğıdın asıl sorunu sahtecilik değil, sonradan doğrulanamaması. Elektronik bir kayıtta “bu satır saat 19:14’te, salon girişindeki tabletten, şu oturum üzerinden üretildi” diyebilirsiniz. Kâğıtta söyleyebileceğiniz tek şey “listede yazıyor” olur. Dekanlık bir katılım sayısını sorguladığında bu cevap yetmez.

Sık yapılan bir ara çözüm, kâğıt listeyi Google Forms’a taşımaktır. Bu, veri girişi problemini çözer ama doğrulama problemini çözmez: form linki paylaşıldığı anda, etkinlikte olmayan herkes doldurabilir.

Basit QR kodu hangi noktada kırılıyor?

Sabit bir QR kodu, ekranda göründüğü ilk saniyede paylaşılabilir bir sırra dönüşür. QR’ın içindeki değer değişmiyorsa, o değeri bilen herkes kayıt oluşturabilir. Salondaki bir kişinin ekranı fotoğraflayıp gruba atması yeterli.

Pratikte gördüğümüz dört kırılma yolu şu:

1. Ekran görüntüsü yayılımı. Projeksiyonda duran QR fotoğraflanır, sınıf grubuna düşer, etkinliğe gelmeyen kişiler evden okutur.
2. Arkadaş adına okutma. Bir kişi, sırada beklerken üç arkadaşının telefonunu alıp aynı kodu üç kez okutur.
3. Çift kayıt. Aynı kişi hem QR ile hem yedek kodla kayıt olur, katılım sayısı şişer.
4. Etkinlik karışması. Aynı gün iki etkinlik varsa, bir etkinliğin kodu diğerinde kabul edilirse yoklama tamamen anlamsızlaşır.

Bu dördü farklı saldırılardır ve tek bir önlemle kapanmazlar. Katmanlı bir tasarım gerekir.

Katmanlar hangi saldırıyı kapatıyor?

Her katmanın kapattığı saldırıyı açıkça yazmak, gereksiz katman eklemenizi de engeller. Aşağıdaki tablo, kampüs koşullarında işe yarayan katmanları ve karşılıklarını gösteriyor.

Katman	Kapattığı saldırı	Uygulama maliyeti	Yan etki
Kısa ömürlü dönen QR (10 sn)	Ekran görüntüsü paylaşımı, kod yayılımı	Düşük, sunucuda token üretimi	Kapıda ekranın canlı kalması gerekir
Sunucu tarafı tek kullanımlık token	Aynı kodun ikinci kez kullanılması	Düşük, Redis veya benzeri anahtar deposu	Ağ kesintisinde okutma başarısız olur
Token içinde etkinlik kimliği doğrulaması	Etkinlik karışması, kod aktarımı	Çok düşük	Yok
Etkinlik zaman penceresi kontrolü	Etkinlikten saatler önce veya sonra kayıt	Çok düşük	Gecikmeli başlayan etkinlikler için tolerans gerekir
Kapıda tarayıcı yönü (görevli okutur)	Arkadaş adına okutma, uzaktan okutma	Orta, personel gerektirir	Kapıda kuyruk oluşabilir
Veritabanı düzeyinde benzersizlik kısıtı	Çift kayıt, eşzamanlı istek yarışı	Düşük, tek satırlık kısıt	Yok
Kullanıcı bazlı bekleme süresi	Aynı kişinin arka arkaya çok kayıt üretmesi	Düşük	Arka arkaya iki etkinliğe katılan öğrenciyi engelleyebilir
Konum ve mesafe kontrolü	Kampüs dışından okutma	Yüksek, hukuki yük dahil	KVKK yükümlülüğü doğurur

Tablodaki ilk altı satır, personel ve mahremiyet maliyeti düşük olduğu için varsayılan tasarım olmalı. Son satır bilinçli bir karardır ve gerekçesi yazılmalıdır.

Dönen token nasıl çalışmalı?

Doğru tasarım, QR’ın içindeki değeri sunucunun ürettiği, kısa ömürlü ve tek kullanımlık bir token yapmaktır. Ekran her birkaç saniyede bir yeni token gösterir, öğrenci okuttuğunda sunucu tokeni doğrular ve aynı anda siler. Silme işlemi atomik olmalı, yoksa iki eşzamanlı istek aynı tokeni tüketebilir.

Pratikte çalışan yapı şu:

1. Kapıdaki ekran, etkinliğin yöneticisi olarak kimliği doğrulanmış bir oturumla sunucudan token ister.
2. Sunucu rastgele bir token üretir, token -> event_id eşlemesini 10 saniyelik yaşam süresiyle bellek içi bir depoda tutar ve token ile kalan süreyi döner.
3. Ekran, tokeni QR’a çevirip gösterir ve süre dolmadan yenisini ister.
4. Öğrenci okuttuğunda istemci tokeni ve etkinlik kimliğini sunucuya gönderir.
5. Sunucu tokeni oku ve sil biçiminde tek işlemde tüketir. Token yoksa süresi dolmuş veya kullanılmıştır. Token başka etkinliğe aitse istek reddedilir.
6. Yoklama satırı yazılır. (etkinlik, kullanıcı) çifti üzerinde benzersizlik kısıtı varsa, ikinci kayıt denemesi veritabanı tarafından reddedilir.

Kritik nokta beşinci adımdaki atomik tüketimdir. Token’ı önce okuyup sonra silen bir kod, yüksek eşzamanlılıkta aynı tokenle iki kayıt üretir. Redis’te GETDEL, ilişkisel veritabanında koşullu DELETE ... RETURNING bu işi tek turda yapar.

Yaşam süresini seçerken şu dengeye bakın:

Token ömrü	Sahtecilik riski	Kullanıcı deneyimi
3 saniye	Çok düşük	Yavaş telefonlarda okutma başarısız olur
10 saniye	Düşük, paylaşım penceresi kapalı	Rahat, kuyruk akıcı
60 saniye	Orta, ekran görüntüsü paylaşımına yeter	Rahat
Süresiz	Yüksek, sabit QR ile aynı	Rahat

Telefonu olmayan öğrenci için yedek yol nasıl kurulur?

Yedek yol, QR yolunun güvenlik kurallarını birebir tekrar etmelidir. En temiz çözüm, ekranda dönen 6 haneli sayısal bir kod göstermek ve bu kodu sunucuda saklamak yerine türetmektir. Kod, etkinlik kimliği ve zaman penceresinden bir gizli anahtarla HMAC hesaplanarak üretilir. Doğrulama tarafı aynı hesabı yapar, saklanacak bir şey kalmaz.

kod = HMAC_SHA256(gizli_anahtar, "{etkinlik_id}:{pencere}")
      -> ilk 4 bayt -> mod 1_000_000 -> 6 haneli metin

pencere = floor(unix_zaman / 10)

Doğrulamada mevcut pencerenin yanında bir önceki pencereyi de kabul edin. Bu, kodun yazılırken dönmesinden ve saat kaymasından doğan hataları giderir. Kabul edilen pencere sayısını ikiden fazlaya çıkarmayın, kodun geçerli olduğu süre gereksiz yere uzar.

Yedek yolda sık yapılan hata, kolaylık olsun diye kodu sabitlemek ya da görevliye “ben elle işaretlerim” demektir. Bu, tüm katmanları anlamsızlaştıran tek bir zayıf halka üretir.

Kapıda tarayıcı yönü neden önemli?

Yoklamanın kimin cihazında başladığı, tek başına bir güvenlik katmanıdır. İki yön vardır ve tehdit profilleri farklıdır.

Yön	Nasıl işler	Güçlü tarafı	Zayıf tarafı
Öğrenci okutur	Kapıdaki ekran QR gösterir, öğrenci telefonuyla okutur	Personel yükü düşük, kuyruk hızlı	Bir kişi birden çok telefonla okutabilir
Görevli okutur	Öğrenci kendi dijital kimliğini gösterir, görevli tarar	Kimlik ile kişi eşleşmesi görsel olarak doğrulanır	Her kapıda görevli ve cihaz gerekir

Yüksek kontenjanlı, serbest girişli etkinliklerde öğrenci tarafı okutma yeterli. Sertifika verilen, burs veya not karşılığı katılım sayılan etkinliklerde görevli tarafı okutmaya geçin. Karar kriteri, katılımın öğrenciye sağladığı somut faydadır: fayda büyüdükçe sahtecilik güdüsü de büyür.

Ara bir çözüm, örnekleme yapmaktır. Herkes kendi okutur, görevli rastgele seçtiği kişilerden kimlik doğrulaması ister. Denetimin var olduğunu bilmek, denetimin kendisi kadar caydırıcıdır.

Zaman penceresi ve tolerans nasıl belirlenir?

Yoklama, yalnızca etkinliğin gerçekleştiği zaman aralığında ve makul bir tolerans içinde kabul edilmelidir. Pencere, etkinliğin başlangıcından belli bir süre önce açılır, bitişinden belli bir süre sonra kapanır.

kabul_araligi = [baslangic - tolerans, bitis + tolerans]

Tolerans için 15 ile 30 dakika arası pratikte iyi çalışıyor. Daha kısa tolerans, kapıda biriken kuyruk yüzünden gerçekten gelen öğrencileri dışarıda bırakır. Daha uzun tolerans, etkinlik bittikten sonra koridordan geçen herkesin kayıt üretmesine izin verir.

Toleransı sabit bir sayı olarak koda gömmek yerine yapılandırılabilir yapın. Bir konferansın kayıt masası etkinlikten bir saat önce açılır, bir film gösteriminin açılmaz.

Buna ek olarak kullanıcı bazlı kısa bir bekleme süresi işe yarar: aynı kişi son iki saat içinde bir etkinliğe kayıt olduysa ikinci kaydı reddedin. Bu, birinin telefonunu sırayla dolaştırarak kısa aralıkla çok sayıda kayıt üretmesini zorlaştırır. Yan etkiye dikkat: arka arkaya iki oturuma katılan öğrenci meşru biçimde engellenebilir, bu yüzden görevlinin gerekçeli manuel ekleme yetkisi olmalı.

Çift kayıt ve yarış durumu nasıl engellenir?

Çift kaydı uygulama kodunda “önce sorgula, yoksa ekle” biçiminde engellemeye çalışmak yanlıştır. İki istek aynı milisaniyede geldiğinde ikisi de “yok” cevabını alır ve iki satır yazılır. Doğrusu, kısıtı veritabanına koymaktır.

ALTER TABLE attendances
  ADD CONSTRAINT uq_event_user_att UNIQUE (event_id, user_id);

Uygulama tarafında bu kısıtın ürettiği hatayı yakalayıp kullanıcıya “zaten kayıt oldunuz” mesajı gösterin. Böylece doğruluk garantisi veritabanında, kullanıcı deneyimi uygulamada kalır.

Aynı mantık token tüketimi için de geçerli. Token’ın tek kullanımlık olmasını uygulama mantığına değil, deponun atomik işlemine bırakın.

Sonradan itiraz akışı nasıl tasarlanır?

Hiçbir yoklama sistemi hatasız değildir, bu yüzden itiraz akışı tasarımın parçası olmalıdır. Öğrenci “katıldım ama listede yokum” ya da “katılmadım ama listedeyim” diyebilir. İkisi de farklı kanıt gerektirir.

İşleyen bir akış şöyle:

1. Öğrenci, etkinlik sayfasından itiraz kaydı açar ve gerekçesini yazar.
2. İtiraz, etkinliği düzenleyen kulüp yöneticisine ve ilgili birime düşer.
3. Yönetici, kayıt günlüğüne bakar: yoklama satırının yöntemi, zaman damgası ve kaydı üreten oturum. Kayıt yoksa kapıdaki görevlinin notlarına bakılır.
4. Karar verilir. Ekleme yapılıyorsa yöntem alanı “manuel” olarak işaretlenir ve kararı veren kişi kaydedilir.
5. Silme yerine iptal kaydı tutulur. Böylece geçmişte üretilmiş bir rapor ile bugünkü sayı arasındaki fark açıklanabilir.

Dördüncü adımdaki “manuel” işareti önemli. Manuel kayıt oranı yükseliyorsa, ya kapıdaki akış bozuktur ya da denetim gevşemiştir. Bu oranı düzenli izleyin.

Konum verisi toplamanın maliyeti nedir?

Konum kontrolü, kapattığı saldırıya kıyasla en pahalı katmandır. Kampüs dışından okutmayı zorlaştırır, ancak karşılığında sürekli bir kişisel veri akışı başlatırsınız. KVKK açısından konum, kişiyi belirli veya belirlenebilir kılan bir veridir ve işlenmesi aydınlatma, hukuki sebep, saklama süresi, erişim yetkisi ve ihlal bildirimi yükümlülüklerini beraberinde getirir.

Karar vermeden önce şunları sorun:

• Kapatmaya çalıştığınız saldırı, dönen token ve görevli kontrolüyle zaten kapanıyor mu? Çoğu durumda cevap evettir.
• Konum verisi kaç gün saklanacak ve kim erişebilecek? Cevabı yazılı değilse toplamayın.
• Cihaz konumunun yanıltılabildiğini biliyor musunuz? Sahte konum uygulamaları yaygındır, yani ödediğiniz mahremiyet bedelinin karşılığı sandığınız kadar yüksek değildir.

Konum yerine, aynı amaca hizmet eden daha ucuz alternatifler var: kapıdaki ekranın canlı ve yerel olması, tokenin 10 saniyede dönmesi, görevli tarafı okutma. Bunlar kampüs dışından okutmayı zaten pratik olmaktan çıkarır.

Toplamaya karar verirseniz, ham koordinat yerine yalnızca “kampüs alanı içinde mi” sonucunu saklayın. Kararı istemcide değil sunucuda verin, ham veriyi kayıt altına almadan atın. Böylece elinizde kalan veri, kişinin nerede olduğu değil, kontrolün sonucudur.

Mahremiyet ve veri asgariliği için pratik kurallar

Yoklama sistemi, öğrenci hakkında zaman içinde ciddi bir hareket kaydı üretir. Kim, hangi etkinliğe, hangi saatte gitti sorusunun cevabı bir yerde birikiyor. Bunu tasarımın ilk gününde sınırlayın.

• Yalnızca kararı vermek için gereken alanları tutun: etkinlik, kullanıcı, yöntem, zaman damgası. Cihaz modeli, IP adresi, tarayıcı parmak izi gibi alanları güvenlik gerekçesi olmadan toplamayın.
• Kim hangi listeyi görebilir, rol bazlı tanımlayın. Kulüp yöneticisi kendi etkinliğinin listesini görür, başka kulübünkini görmez.
• Dışa aktarma işlemlerini kayıt altına alın. Excel’e alınan liste, sistemin dışına çıkan veridir.
• Saklama süresini yazılı hale getirin ve süre dolduğunda toplulaştırılmış sayıya indirin. Dönem raporu için katılımcı sayısı yeterlidir, isim listesi değil.

Ne işe yaradı

Bu tasarımın somut çıktısı şu: katılım sayısı sorgulandığında, sayının nasıl üretildiğini adım adım gösterebiliyorsunuz. Yoklama satırının yöntemi, zamanı ve manuel müdahale görüp görmediği kayıtta duruyor. Kâğıt listede yapılamayan şey bu.

Ölçmediğimiz şeyleri ölçtük gibi yazmıyoruz: bu yaklaşımın sahteciliği yüzde kaç azalttığına dair bir sayımız yok, çünkü karşılaştırma için gereken eski dönem verisi zaten güvenilir değildi. Elimizdeki gözlem şu: dönen token ve tek kullanımlık tüketim devreye girdikten sonra, “aynı kod birden çok kişide” türü şikayetler ortadan kalkıyor, çünkü teknik olarak mümkün olmuyor.

CardeaCore bu işi nasıl yapıyor

CardeaCore’un kampüs etkinlik modülünde yoklama, yukarıdaki katmanların çoğunu varsayılan olarak uyguluyor: kapıdaki ekran sunucudan 10 saniyelik ömre sahip tek kullanımlık bir token alıyor, öğrenci okuttuğunda token atomik biçimde tüketiliyor, token başka bir etkinliğe aitse istek reddediliyor, (etkinlik, kullanıcı) çifti üzerindeki benzersizlik kısıtı çift kaydı veritabanı düzeyinde engelliyor ve etkinlik zaman penceresi dışındaki okutmalar kabul edilmiyor. Telefonu okutamayan öğrenciler için aynı zaman penceresi mantığıyla üretilen 6 haneli dönen kod, QR ile aynı kuralları uyguluyor. Konum verisi toplanmıyor. Ayrıntı için Cardea Campus sayfasına bakabilirsiniz.