Yapay Zekâyla Yapılan Uygulamalar İçin Güvenlik Kontrol Listesi: Yayından Önce Neye Bakılmalı

İnsanlar yapay zekâyla oluşturduğunuz bir uygulamayı kullanmadan önce yedi şeyi kontrol edin: her sayfa ve API kullanıcının kim olduğunu ve neye izni olduğunu denetler; gizli anahtarlar tarayıcıda ya da sohbette değil sunucuda durur; tüm girdiler sunucuda doğrulanır; her kullanıcı yalnızca kendi kayıtlarına ulaşabilir; giriş ve maliyet doğuran uç noktalar hız sınırlıdır; bağımlılıklar günceldir; ve bir şey ters giderse verilerinizi geri yükleyebilirsiniz. Aşağıdaki liste bunların her birini, kod okumadan çalıştırabileceğiniz somut testlere çevirir.

Yapay zekâ uygulama oluşturucuları işlevleri çalıştırmakta iyidir. Kendiliğinden dikkatli değildirler, çünkü “dikkatli olmak” nadiren istemde yer alır. Aşağıdaki sorunların çoğu kimsenin istemediği şeylerden doğar, bu yüzden çözüm çoğunlukla sormaktır.

Bu kontrol listesi nasıl kullanılır

Sırayla ilerleyin ve her madde için iki şey yapın: yapay zekâdan bunun ele alındığından emin olmasını isteyin, ve kendiniz test edin. Yapay zekâ bir yetki kontrolü yazabilir; işe yaradığını yalnızca bir test söyler. Maddeler şöyle işaretlenmiştir:

• Zorunlu — uygulamayı başka kimse kullanmadan önce yapın.
• Olmalı — gerçek kullanıcılarınız ya da gerçek verileriniz olmadan önce yapın.
• Sonra — uygulama büyüdükçe yapmaya değer.

Yalnızca bir saatiniz varsa, her Zorunlu maddeyi yapın.

1. Kimlik doğrulama: bu kim?

Kimlik doğrulama, birinin kim olduğunu doğrulamak demektir — genellikle giriş. Temeller için kimlik doğrulama nedir ve seçenekler için uygulamanıza giriş nasıl eklenir yazılarına bakın.

• Zorunlu: Özel veri gösteren her sayfa giriş ister. Test: çıkış yapın, özel bir sayfanın URL'sini doğrudan tarayıcıya yapıştırın.
• Zorunlu: Bu sayfaların arkasındaki her API uç noktası da giriş ister — yalnızca sayfa değil. Test: çıkış yapın, tarayıcının ağ sekmesini açın ve giriş yapmışken uygulamanın gönderdiği bir isteği tekrar deneyin.
• Zorunlu: Parolalar düz metin olarak değil, yavaş bir parola özetleme algoritmasıyla özetlenerek saklanır. OWASP'ın parola saklama rehberi önce Argon2id'yi, alternatif olarak scrypt, bcrypt ya da PBKDF2'yi önerir. Sorun: “Parolalar nasıl saklanıyor?”
• Olmalı: Parola sıfırlama bağlantılarının süresi dolar ve yalnızca bir kez çalışır.
• Olmalı: Oturum çerezleri Secure, HttpOnly ve SameSite olarak işaretlenir ve çıkış yapmak oturumu sunucuda sonlandırır.
• Sonra: İki faktörlü kimlik doğrulama sunun ya da buna sahip bir sağlayıcıyla girişe izin verin.

Kullanıcı verisi döndüren her API rotasını ve sayfayı kontrol edin. Her biri, giriş yapmamış kullanıcıların isteklerini yalnızca sayfa kodunda değil, sunucuda reddetmelidir. Kontrol ettiğiniz rotaların listesini çıkarın.

2. Yetkilendirme: ne yapmalarına izin var?

Yetkilendirme, girişten sonraki adımdır: bu belirli kullanıcının neyi görebileceğine ve değiştirebileceğine karar vermek. Yapay zekâyla yapılan uygulamalarda ciddi açıklar en çok burada olur, çünkü uygulama doğru görünür — her kullanıcının panosu yalnızca kendi verisini gösterir — ama sunucu doğrudan istendiğinde herkesin verisini verir.

• Zorunlu: Her okuma, güncelleme ve silme işlemi, kaydın geçerli kullanıcıya (ya da ekibine) ait olduğunu sunucuda denetler.
• Zorunlu: Test edin: iki hesap oluşturun, A ve B. A olarak, A'nın kayıtlarından birini açın ve URL'deki ya da ağ isteğindeki kimliği not alın. B olarak giriş yapın ve aynı kimliği isteyin. B bir hata almalı, A'nın verisini değil.
• Zorunlu: Yönetici sayfaları ve yönetici API uç noktaları kullanıcının rolünü sunucuda denetler. Yönetici bağlantısını gizlemek koruma değildir.
• Zorunlu: Kullanıcılar isteği değiştirerek kendi rollerini, fiyatlarını, bakiyelerini ya da sahiplik alanlarını değiştiremez. Test: ağ sekmesinde bir profil güncellemesinin neler gönderdiğine bakın. role ya da isAdmin gibi alanlar varsa, bunların istemciden yok sayılması için yapay zekâdan isteyin.
• Olmalı: URL'lerdeki kimlikler tahmin edilmesi zor olmalı (1, 2, 3 yerine rastgele kimlikler). Bu yetki kontrollerinin yerini tutmaz, ama biri eksik olduğunda zararı sınırlar.

Kayıt okuyan ya da değiştiren her uç nokta için, sunucuda, giriş yapmış kullanıcının kaydın sahibi olduğunu ya da erişime izni olduğunu denetleyin. Değilse 404 döndürün. Sonra iki hesapla bunu nasıl test edeceğimi gösterin.

3. Veritabanında satır düzeyinde erişim

“Satır düzeyinde erişim”, bir tablonun her satırının (bir rezervasyon, bir fatura) yalnızca ait olduğu kullanıcılara görünmesi demektir. Bunu uygulamanın iki yaygın yolu vardır:

İkisi de iyi yapılabilir. Önemli olanlar:

• Zorunlu: Tarayıcı veritabanıyla doğrudan konuşuyorsa (bazı barındırılan veritabanı ürünleri buna izin verir), her tablo için satır düzeyinde kurallar açık olmalı. Aksi halde genel anahtarı olan herkes tüm tabloyu okuyabilir.
• Zorunlu: Sorgular, tarayıcının gönderdiği bir kimliğe göre değil, geçerli kullanıcıya ya da ekibe göre filtrelenir.
• Olmalı: Paylaşılan veri (bir ekibin projeleri) için, ekibe kimlerin dahil olduğuna dair tek bir yerde uygulanan net bir kural vardır.

4. Gizli değerler ve API anahtarları

API anahtarı bir hizmet için parola gibidir. Stripe, e-posta ve yapay zekâ sağlayıcılarının hepsi bunları kullanır. Arka plan için bkz. ortam değişkenleri ve gizli değerler nedir.

• Zorunlu: Anahtarlar projenin ortam değişkenlerinde ya da gizli değerlerinde saklanır, koda asla yazılmaz.
• Zorunlu: Para harcayabilen ya da özel veriyi okuyabilen anahtarlar yalnızca sunucuda kullanılır. Test: canlı sitenizi açın, geliştirici araçlarında sayfa kaynağına ve JavaScript dosyalarına bakın ve anahtarınızın başlangıcını (ör. sk_) arayın. Görünmemeli.
• Zorunlu: Anahtarlar hiçbir zaman sohbete, herkese açık bir depoya ya da bir ekran görüntüsüne yapıştırılmadı. Yapıştırıldıysa, sağlayıcıda anahtarı yenileyin (yeni bir tane oluşturun, eskisini silin).
• Olmalı: Sağlayıcının sunduğu yerlerde kısıtlı ya da kapsamlı anahtarlar kullanın. Örneğin Stripe, yalnızca entegrasyonunuzun ihtiyaç duyduğu izinlere sahip kısıtlı anahtarları önerir.
• Olmalı: Test ve canlı anahtarlar ayrıdır ve canlı uygulama, siz hazır olduğunuzda canlı anahtarları kullanır.

Bazı anahtarlar herkese açık olacak şekilde tasarlanmıştır — Stripe'ın yayımlanabilir anahtarı (pk_…) ya da yalnızca alan adınıza kısıtlanmış bir harita anahtarı gibi. Kural, güç veren anahtarlarla ilgilidir, anahtara benzeyen her dizeyle değil.

5. Girdi doğrulama

Bir kullanıcının gönderdiği her şey — form alanları, dosya yüklemeleri, URL parametreleri — formunuzun izin verdiği şey olmak zorunda değildir.

• Zorunlu: Doğrulama sunucuda yapılır, yalnızca tarayıcıda değil. Tarayıcı kontrolleri kolaylık içindir; herkes bunları atlayabilir.
• Zorunlu: Veritabanı sorguları parametre kullanır, kullanıcı girdisinden birleştirilmiş metin kullanmaz (bu SQL enjeksiyonunu önler). Yapay zekâdan doğrulamasını isteyin.
• Zorunlu: Kullanıcıların girdiği metin HTML olarak değil, metin olarak gösterilir. Test: adınız olarak <b>merhaba</b> girin. Kalın metin yerine etiketleri görmelisiniz.
• Olmalı: Dosya yüklemeleri tür ve boyutu denetler ve yüklenen dosyalar uygulamanızın ana alan adından çalıştırılabilir sayfa olarak sunulmaz.
• Olmalı: Kullanıcılara gösterilen hatalar sade olur (“Bir şeyler ters gitti”); ayrıntılı hatalar yalnızca sunucu günlüklerine gider.
• Olmalı: Stripe gibi hizmetlerden gelen webhook'lar, işlem yapmadan önce sağlayıcının imzasını doğrular. Bkz. webhook nedir.

Her form ve API uç noktasına sunucu tarafı doğrulama ekleyin: zorunlu alanlar, uzunluklar, biçimler ve izin verilen değerler. Başka her şeyi açık bir mesajla reddedin. Kullanıcılara iç hata ayrıntılarını göstermeyin.

6. Hız sınırları ve kötüye kullanım

Hız sınırı, bir kişinin belirli bir süre içinde yapabileceği istek sayısını sınırlar. Bu olmazsa, herhangi biri gün boyu parola tahmin edebilir, kayıt formunuzu doldurabilir ya da ücretli bir API'de faturanızı şişirebilir.

• Zorunlu: Giriş, kayıt ve parola sıfırlama, IP adresi ve hesap başına hız sınırlıdır.
• Zorunlu: Çağrı başına size para mal olan her şey — yapay zekâ model istekleri, SMS, e-posta — kullanıcı başına bir sınıra sahiptir ve giriş gerektirir.
• Olmalı: Herkese açık formlar (iletişim, bekleme listesi) spam korumasına sahiptir: bir hız sınırı, gizli bir tuzak alan ya da bir CAPTCHA.
• Olmalı: Ücretli sağlayıcılarda harcama sınırları ya da uyarıları ayarlayın; böylece bir hata ya da saldırgan sınırsız bir fatura üretemez.

7. Bağımlılıklar

Uygulamalar açık kaynak paketlerden oluşur ve paketlerin bilinen güvenlik açıkları olabilir.

• Olmalı: Yapay zekâdan bilinen açıkları denetlemesini isteyin (JavaScript projeleri için npm audit ya da paket yöneticinizin karşılığı) ve etkilenenleri güncelleyin.
• Olmalı: Uygulamanın artık kullanmadığı paketleri kaldırın.
• Olmalı: Çok az kullanıcısı olan paketlerden ya da popüler paketlerin yazım hatası gibi görünen adlardan kaçının.
• Sonra: Her bir veya iki ayda bir yeniden kontrol edin, ya da kodunuz GitHub'daysa otomatik uyarıları açın.

8. Yedekler ve kurtarma

Güvenlik, hatalardan kurtulabilmeyi de kapsar — sizin, yapay zekânın ya da bir saldırganın hatalarından.

• Zorunlu: Verilerinizin nerede durduğunu ve yedeklenip yedeklenmediğini bilin. Varsayımda bulunmayın; barındırma sağlayıcınızın dokümantasyonuna bakın.
• Olmalı: Önemli verilerin kendi periyodik dışa aktarımını tutun (ör. bir CSV dışa aktarma özelliği ya da bir veritabanı dökümü), ayrı bir yerde saklayın.
• Olmalı: Kodunuzu sürüm kontrolünde tutun, böylece herhangi bir sürüme dönülebilsin.
• Olmalı: Yıkıcı işlemler (hesabı sil, projeyi sil) onay ister ve bir süre geri alınabilen bir “yumuşak silme” düşünülür.
• Sonra: Bir geri yüklemeyi gerçekten bir kez test edin. Hiç geri yüklenmemiş bir yedek bir plan değil, bir umuttur.

9. Yayından önce

• Zorunlu: Canlı site her yerde HTTPS kullanır.
• Zorunlu: Geliştirmeden kalma örnek veriler, test hesapları ve hata ayıklama sayfaları kaldırılmıştır.
• Olmalı: Gizlilik politikası hangi verileri neden topladığınızı söyler — kişisel veri topluyorsanız birçok yerde zorunludur. Sahip olmadığınız sertifikaları (SOC 2, HIPAA) iddia etmeyin.
• Olmalı: Güvenlik sorunları için size ulaşılabilecek bir yolunuz vardır ve tüm anahtarları hızla yenilemeyi bilirsiniz.

Güvenlik dışında daha geniş bir yayın öncesi kontrol için bkz. bir yapay zekâ prototipini üretime nasıl taşırsınız.

Ne zaman profesyonel bir inceleme gerekir

Bir kontrol listesi yaygın hataları yakalar; uzmanın yerini tutmaz. Kart numaralarını hosted ödeme sayfası yerine kendiniz işliyorsanız, sağlık, finans ya da çocuk verisi tutuyorsanız, güvenlik anketleri isteyen şirketlere satıyorsanız ya da bir sızıntıdan ciddi zarar görecekseniz, bir inceleme için ödeme yapmayı düşünün. Kodunuzun dışa aktarılabilir olması bu incelemeyi çok kolaylaştırır.

Mythex'te oluşturduğunuz uygulamalarda güvenlik

Mythex'in güvenlik tarama paneli yoktur; bu yüzden yukarıdaki kontrol listesi izlenecek süreçtir. Yardımcı olabilecek birkaç şey:

• Proje gizli değerleri. Anahtarları proje ayarları → Gizli Değerler altında ya da ajanın sohbette gösterdiği gizli değer kartı üzerinden saklayın; böylece kodunuzdan ve mesajlarınızdan uzak durur. Canlı bir uygulamanın gizli değerini değiştirdikten sonra yeniden yayınlayın.
• Plan ve Soru modları. Ajandan düzenlemeden izinleri gözden geçirmesini isteyin: “Soru modunda, her API rotasını ve hangi yetki kontrolünü yaptığını listele.”
• /test, ajanın önizlemenizde bir kullanıcı gibi gezinmesini sağlar — 2. bölümdeki iki hesap testi için kullanışlıdır.
• Kontrol noktaları, bir şeyi bozan bir değişikliği geri almanızı sağlar.

Dokümanlarda uygulamalarınız için güvenlik ve ortam değişkenleri ve gizli değerler bölümlerine bakın. Sıradaki adımınız kullanıcı hesapları eklemekse, uygulamanıza giriş nasıl eklenir yazısını okuyun.

Sorular