B2B hizmeti olarak diğer şirketler (müşterilerimiz) tarafından kullanılan Nice REST/JSON API'sini oluşturdum. Müşterilerimizin her birinin bir kullanıcı adı/şifre çifti vardır ve ayrıca HTTPS yapıyoruz ve hizmet taleplerinin kaynak IP'sini doğrulıyoruz. Hizmet kullanımı maliyetlidir ve müşteri hizmet kullanımı için aylık olarak faturalandırılır.
Şimdi, bazı müşteriler kullanıcılarına (B2C - son kullanıcılar) dağıttıkları mobil uygulamalar geliştirmektedir. Hizmetimizin bu son kullanıcılarının hepsi sunuculara sahip değildir ve hizmeti doğrudan akıllı telefondan kullanmak isterler (teknik olarak JSON/REST olmak büyük bir sorun değildir).
Sorun şu ki, hizmeti sahtekarlığa karşı nasıl koruyacağımdan emin değilim. Bir üçüncü taraf geliştiricinin müşterinin mobil uygulamasından birini sökmesini ve kullanıcı adını/şifresini/hangi güvenlik bilgilerini kopyalamasını ve bunu uygulamasında kullanmasını ne engelleyecektir? Bu, hizmeti tüketmesine ve kullanımı yasal müşterilerimizden birine talep etmesine izin verecektir!
Son kullanıcılar bazı sunuculara kimlik doğrulaması yapmadığı sürece bu soruna mükemmel bir kripto çözümü olmadığından eminim. Ancak durum her zaman böyle değildir.
Son çare olarak sanırım Android/IPhone için gizlenmiş bir kütüphane dağıtabilirim, ki bu en azından güvenlik yanılsamasını verecekti ...
DÜZENLE (açıklama) :)
Senaryoyu basitleştirmeye çalışayım.
Bu durdurulabilir mi?
Sorunuz "Bu durdurulabilir mi?", Ancak sistemle ilgili önemli bir şeyin gerçekten değiştirilemeyeceği/değiştirilemeyeceği hissine kapılıyorum.
Eğer doğru anlıyorsam, soruyorsun
Aynı kullanıcı adını ve şifreyi paylaşan birçok müşterim var. Yanlış kullanımı durdurabilir miyim?
Bunun cevabı hayır. Sorunu göz ardı edip edemeyeceğinize veya doğru çözümleri uygulayıp uygulayamayacağınıza karar vermelisiniz.
Bunu gerçekten doğru bir şekilde yapmak istiyorsanız, OAuth gibi bir şey uygulamaya bakın, böylece son kullanıcılar için ayrı kimlik doğrulama jetonlarını düzgün bir şekilde dağıtabilir, faturalandırma, erişimi iptal etme vb. İçin müşterilerinize bağlayabilirsiniz.
-
Yapmanız gereken en az şey, müşterilerinizin (şirketlerin) daha iyi bir kimlik doğrulama düzeni kullanmayı seçmelerine izin vermektir. Örneğin, son kullanıcıları için ayrı erişim belirteçleri istemek (ve iptal etmek) için bir API oluşturursunuz.
Bir şirket bunu yapmak istemiyorsa, kullanıcı adını/şifresini kullanarak bağlantı kurmaya devam edebilir, ancak sonuçta ortaya çıkan tüm kullanımdan tamamen sorumlu olacaktır.
Mesele şu ki, hizmeti kullanmanın başka bir yolu yoksa, müşterilerinizi kimlik bilgilerini (mobil uygulama senaryosunda yapılması imkansız bir şey) sızdırmaktan gerçekten sorumlu tutamazsınız.
Bu yüzden umarım bu doğru olur. Geçerli bir API anahtarı kullanarak bir istemcinin kimliğini doğrulamak için güvenli bir yol mu istiyorsunuz? API anahtarını güvenli bir şekilde saklamanın, uygulamayı değil, şirketi geliştiren şirketten büyük ölçüde sorumlu olduğunu düşünüyorum.
Günlük hackerlardan korumak için anahtarı şifrelemeniz ve gizlemeniz gerekecek, ancak kararlı bir hacker'ı önleyebileceğinizi sanmıyorum. İkili hata ayıklama zor yapmak için biraz hackery yapabilir, bu da uygulamanızın internette yüzen şansını azaltabilir. Ancak bu mutlak bir güvenlik değildir ve şirketiniz şirket içi uygulamaları geliştirmedikçe bu tür önlemleri nasıl uygulayabilirsiniz?
Yani senaryonuza bir cevap olarak, hayır, kullanıcı deneyimine zarar vermeden etkili bir şekilde durduğunu düşünmüyorum. API'nızı kullanarak şirketleri eğitebilirsiniz - onlar için küçük bir el kitabı bir araya getirin ve onların = onların api anahtarını güvende tutmanın açık olduğundan emin olun .
Sonunda, bazı azaltma özelliklerini de uygulayabilirsiniz. Örneğin:
Başarısızlık hedefi (en iyisi olur) hasarı en aza indirmektir.
İyi şanslar.
Müşterilerinizin kullanıcı adlarını/şifrelerini tüm kullanıcılarına dağıtabilecekleri bir mobil uygulamaya yerleştirmeleri konusunda şüpheci davranabilirsiniz. Doğru bir şekilde tanımladığınız gibi, bazı saldırganların bu mobil uygulamayı sökmesi, mobil uygulamadan kullanıcı adını/şifreyi çıkarması ve kendi uygulamasında kullanması kolay olacaktır. Ne yazık ki, müşteriniz bunu yapıp yapmayacağınıza karar veren kişidir, ancak maliyet size uygulanır. Yani, bu bir dışsallıktır ve maliyetleri, riskleri ve teşvikleri daha uyumlu hale getirmek için bir yol bulmanız gerekir. Aşağıda bunun nasıl yapılacağı hakkında bazı önerilerim var.
Genel olarak, bunun iki mantıklı çözümünü görüyorum:
Risk transferi. Her müşteri için, o müşteriden kaç istek kabul edeceğinize bir sınır getirin. Müşterilere, kullanıcı adlarını/parolalarını güvende tutma sorumluluğunun olduğunu, bu kullanıcı adını/parolayı kullanarak gelen tüm isteklerin limitleri dahilinde sayılacağını ve çok fazla istek gelmesi durumunda hesaplarının devre dışı bırakılabileceğini söyleyin. Kullanıcı adlarını/şifrelerini bir mobil uygulamaya yerleştirirlerse, haksız birinin kullanıcı adını/şifreyi çalabileceğini ve birçok istekte bulunmak için kullanabileceğini ve hesaplarının devre dışı bırakılmasına ve mobil uygulamalarının çalışmayı durdurmasına neden olabileceğini söyleyin . Risk almak isteyip istemediklerine karar vermelerine izin verin.
Sözleşme gereklilikleri. Müşterilerinize, kullanıcı adlarını/şifrelerini başkalarıyla paylaşmalarının yasak olduğunu söyleyin ve başkaları tarafından indirilebilen uygulamalara kullanıcı adlarını/şifrelerini yerleştirmelerine izin verilmez. Bu politikanın herhangi bir ihlalini tespit ederseniz hesaplarının devre dışı bırakılabileceğini ve bunun sunucularınıza yüklediği maliyetler için faturalandırılabileceğini söyleyin.
Müşterileriniz bir mobil uygulama oluşturmak istiyorsa, müşterilerinize mobil uygulamaya kendi kullanıcı adlarını/şifrelerini gömmek yerine, bu tür istekleri kendi sunucularına proxy vermeleri gerektiğini söyleyin. Başka bir deyişle, istemcinin istemcinin kullanıcı adını/şifresini bilen bir sunucu kurması gerekir, ancak bu kullanıcı adı/şifre mobil uygulamaya gömülmemelidir. İstemcinin mobil uygulaması istemcinin sunucusunda kimlik doğrulaması yapmalı, sunucuya bir istek göndermeli ve ardından sunucu isteği size iletmeli ve yanıtı mobil uygulamaya geri göndermelidir. Sunucuları, son kullanıcının kimliğini doğrulamalıdır (ör. Mobil uygulamanın her son kullanıcısının, sunucularında kendi kullanıcı adı/şifresi ile bir hesap oluşturmasını zorunlu kılmalıdır). Sunucuları, kullanıcı başına bant genişliği sınırları koymalı ve bu sınırları aşan son kullanıcıların hesabını devre dışı bırakmalıdır.
Ayrıca, istemcilerin şu iki seçenek arasında seçim yapmasına da izin verebilirsiniz: ör., Sınırlı bant genişliği hesabı (risk aktarımı ile) veya sınırsız bant genişliği hesabı (kullanıcı adı/parolayı başkalarına erişebilen uygulamalara yerleştirmeme şartıyla) arasında ).
Umarım bu mantıklı gelir. Bu biraz kafa karıştırıcı olabilir, çünkü üç taraf vardır - siz, müşteriniz ve müşterinizin son kullanıcısı - her birinin kendi ilgi alanları ve kaygılar. Umarım her üçünü de yeterince ayırt etmişimdir.
Verilerinizi SSL ile iletimde güvenli hale getirmek zaten ortadaki adam saldırısını kapsamaktadır. Kaynak kodda sabit kodlanmış şifreler zaten güvenli bir uygulama değildir. Kullanıcıların IP adreslerini veya IMEI'yi önemsememelisiniz. Takip hakkında konuşmayalım ve ilk etapta işleri düzeltmeye çalışalım.
Dediğin gibi REST kullanıyorsun. Umarım birkaç şey size yardımcı olur.
Kaynak kodunuz için endişelenmeyin. Yine de sökük olabilir ama sorun değil. Başlıca işlevleriniz sunucuda çalışacak ve yanıtları istemcilere iletecektir. Tüm iyi şeyleri sunucu tarafında tutun.
Mobil cephede karşılaşacağınızı düşündüğüm sorunlardan biri IP adresi doğrulaması. Tipik olarak telco tarafından atanan mobil IP adresleri netleştirilir. Ağa bağlanan IP, sunucu tarafında benimsenen IP doğrulama mekanizmasını kullanılmaz hale getirecektir.
Çözümü Android ve Iphone'lar) üzerine uygulamak için; yaklaşımın şöyle olması gerektiğini düşünüyorum:
Mobil ortam için tartışıyor olsak da inanıyorum; IP doğrulaması dışında, riskler PC ortamında da mevcuttur. Gelecekte, PC ortamında imza tabanlı ve istemci sertifikasına dayalı uygulamayı da benimseyebilir veya istemcilerin yanlış faturalandırma sorunlarıyla karşılaşırsanız geçiş yapabilirsiniz.
Sahtecilik belirsizdir ve sadece teknik bir uygulama ile ele alınamaz, ancak artan IP doğrulaması ve kilitlemesi uyguladıysanız endişelenecek bir şey yoktur. Ayrıca gerçek kimlik bilgilerinizi müşterilerinize (B2B) vermemelisiniz. Neden ve nasıl olduğunu açıklayayım.
Ne yazdığınızı anladığımdan, B2B tarafı (KENDİNİZ - KENDİNİZ) ile ilgili temel ve ortalama güvenlik kavramları ve uygulamaları zaten uygulanmıştır. Bu iyi. IP Doğrulama, SSL/TLS, Kullanıcı/Geçiş vb. Artık, müşterilerinize son kullanıcılara mobil uygulamalar sunmak için kullanılan API kimlik bilgilerinin, üçüncü taraf son kullanıcının yararlanacağı şekilde kusurlu olabileceğinden endişe ediyorsunuz. istemcinizin mobil uygulamasından bir şekilde yararlandıysa bu kimlik bilgileri.
Temel olarak bir dizi güvenlik katmanına kadar kaynar. Soru, şirketinizin bu katmanları nasıl tasarlayıp uyguladığıdır?
JSON/REST API SERVER cihazınız gerçek kimlik bilgilerinizi içermelidir. Bir hizmet veriyorsanız ve bir ağ sağlayıcısına/operatöre bağlantı gerektiriyorsa, bu kimlik bilgileri de burada bulunabilir. Ne demek istediğimi biliyorsun.
SİZİN JSON/REST API SUNUCUSU'na doğrudan erişim vermeyin. Bunun yerine, güvenilir ortam için Ana Bilgisayar görevi görecek bir atlama Ana Bilgisayarına ihtiyacınız vardır; JSON/REST uygulamanızın bulunduğu API sunucusu, SADECE IP Adresi doğrulama/kilitleme kullanarak bu sunucu ile kimlik doğrulaması yapmalıdır. IP veya ortak/özel anahtar çiftlerini kullanarak sunucudan sunucuya kimlik doğrulama. Ne kullanacağınız sizin takdirinize bağlıdır.
Bu sunucu aynı zamanda kendisini bir yapılandırma dosyasıyla eşleyen ve isteği JSON/REST API SUNUCUSU'na geçiren bir dizi kullanıcı adı/parola içeren bir web hizmeti olarak da hareket etmelidir. Şimdi, YOURCLIENTS, IP doğrulama/kilitleme temelinde de bu sunucuya erişebilmeli ve HTTPS kullanılarak korunmalıdır. Kavram, API SUNUCUSU ile eşleşen anahtar/sır dışında burada gerçek kullanıcı/geçiş kimlik bilgilerinin bulunamamasıdır.
Şimdi, örneğin, bir üçüncü taraf geliştirici (son kullanıcı), YOURCLIENT tarafından oluşturulan bir mobil uygulamadaki bir kusurdan yararlandı ve kimlik bilgilerini aldı:
Gizleme iyidir ve bir saldırıyı yavaşlatır, ancak en az güvenlik şeklidir. Anahtarları kullanan kriptoya daha iyi güvenmelisiniz.
Unutmayın, teknik ve operasyonel bir güvenlik perspektifinden dolandırıcılıkla mücadele konusundaki sürekli çabanız dışında kesin bir güvenlik çözümü yoktur.