Kimlik Doğrulama
SecureCodingHub birden fazla kimlik doğrulama yöntemini destekler. Tarayıcı oturumları JWT bearer token kullanır; public API kapsam tabanlı yetkilendirme ve anahtar başına hız limitleri ile uzun ömürlü API anahtarları kullanır.
Kimlik Doğrulama Yöntemleri
Kuruluşunuza en uygun kimlik doğrulama yöntemini seçin:
Magic Code (E-posta OTP)
E-posta ile gönderilen 6 haneli kod aracılığıyla parolasız giriş. Tüm kullanıcılar için varsayılan yöntem. Kodlar 10 dakika sonra sona erer. Yönetilecek ya da hatırlanacak parola yok.
OIDC (OpenID Connect)
Azure AD, Okta veya uyumlu sağlayıcılar üzerinden kurumsal SSO. PKCE ile authorization code akışı. Kuruluşlar için önerilir.
SAML 2.0
Kurumsal ortamlar için federasyon tabanlı SSO. SP-initiated giriş akışı.
Magic Code Akışı
Varsayılan parolasız kimlik doğrulama akışı şöyle çalışır:
Kullanıcı e-posta adresini girer
Sunucu e-postaya 6 haneli bir OTP gönderir
Kullanıcı kodu girer
Sunucu kodu doğrular ve bir JWT verir
JWT, oturum yönetimi için tarayıcıda saklanır
SSO Akışı
Kuruluşunuz için SSO yapılandırıldığında kimlik doğrulama akışı değişir:
Kullanıcı kuruluşunun SSO giriş noktasını açar (bağlantı kurum slug'ını içerir; bugün otomatik e-posta → domain algılaması yoktur)
Tarayıcı yapılandırılmış kimlik sağlayıcıya yönlendirir
Kullanıcı kurumsal kimlik bilgileriyle kimlik doğrular
IdP, SecureCodingHub geri çağırma uç noktasına bir authorization code (OIDC) ya da SAML iddiası döndürür
Sunucu yanıtı doğrular, ilk girişte kullanıcıyı JIT ile sağlar ve bir JWT verir
Kullanıcı giriş yapmış olur
JWT Token
Tüm tarayıcı tabanlı kimliği doğrulanmış oturumlar, magic code ya da SSO adımı başarılı olduktan sonra arka uç tarafından verilen JSON Web Token'lar kullanılarak yönetilir.
| Özellik | Değer |
|---|---|
| Algoritma | HS256 |
| Geçerlilik süresi | Verildiği andan itibaren 30 gün. Uygulama içi bir yenileme akışı yoktur; token süresi dolduğunda kullanıcılar magic code ya da SSO ile yeniden kimlik doğrular. |
| Talepler | Kullanıcı id, kurum id, rol, ad, e-posta, son kullanma tarihi. |
| İletim | Her dahili API çağrısında Authorization: Bearer … başlığı. |
| Depolama | İstemci tarafında localStorage içinde sch-token anahtarı altında saklanır. Bugün HttpOnly cookie seçeneği yoktur. |
API Key Bearer (Public API)
/api/public/v1/* altındaki public REST ve webhook yüzeyi JWT yerine uzun ömürlü API anahtarları kullanır. Anahtarlar yönetici konsolundan Kurum → API Anahtarları altında oluşturulur ve her istekte standart bir bearer başlığı olarak gönderilir:
Authorization: Bearer scs_live_…| Özellik | Değer |
|---|---|
| Format | scs_live_ + 32 rastgele base62 karakter. Toplam 41 karakter. |
| Depolama | Sunucuda yalnızca SHA-256 özeti, önek ve son dört karakter tutulur. Tam token oluşturma sırasında bir kez gösterilir ve bir daha alınamaz. |
| Kapsamlar | 16 ince taneli kapsam (ör. users:read, assignments:write, sarif:ingest). Gerekli kapsamı olmayan bir istek 403 insufficient_scope döndürür. |
| Geçerlilik süresi | Varsayılan olarak süresizdir. Oluşturma sırasında isteğe bağlı bir son kullanma tarihi belirlenebilir. Anahtarlar herhangi bir anda iptal edilebilir; iptal anında etkili olur. |
| Son kullanım takibi | Her başarılı çağrı, denetim ve rotasyon hijyeni için anahtarın lastUsedAt alanını günceller. |
Tam referans için API → Kimlik Doğrulama ve Kapsamlar.
Hız Sınırlama
Her public API anahtarı, platformu kontrolden çıkmış betiklerden koruyan ve bir kiracının diğerini aç bırakmasını engelleyen iki kayan pencere ile sınırlandırılır:
| Pencere | Limit | Yanıt başlıkları |
|---|---|---|
| Dakika başına | 60 istek | Retry-After, X-RateLimit-Window: per_minute, X-RateLimit-Limit: 60 |
| Saat başına | 1.000 istek | Retry-After, X-RateLimit-Window: per_hour, X-RateLimit-Limit: 1000 |
Her iki pencereyi de aşan istekler 429 rate_limited ve saniye cinsinden bir Retry-After başlığı alır. Ayrı bir IP tabanlı limit (15 dakikada 5 istek) anonim web iletişim formunu kapsar. JWT korumalı yönetici API'sine karşı dahili tarayıcı oturumu trafiği bugün hız sınırlamasına tabi değildir.
Ayrıntılı yeniden deneme rehberi ve örnek bir üstel geri çekilme istemcisi için API → Hız Limitleri.
Denetim Günlüğü
Tarayıcıdaki bir yönetici kullanıcıdan ya da public API anahtarından kaynaklansın, mutasyona neden olan her eylem kurum başına bir denetim günlüğü tablosuna yazılır. Salt okunur eylemler (listele, getir, panel sorguları) denetlenmez; odak, aşağı akış etkisi olan değişikliklerdir.
| Alan | Anlam |
|---|---|
action | Olanın noktalı tanımlayıcısı (ör. user.updated, assignment.created, apikey.revoked, sarif.ingested). |
actorEmail / actorRole | Aktörün e-postası ve rolü. Yönetici UI mutasyonları insanın e-postasını ve org_admin bilgisini taşır. API anahtarı mutasyonları apikey:<api-key-uuid> ve api_key rolünü taşır. |
targetType, targetId, targetLabel | Değiştirilen kaynak. Etiket, denetim günlüğü UI'sinde kullanılan kısa, insan okuyabilir bir açıklamadır. |
metadata | Tam olarak neyin değiştiğini açıklayan JSON formatına serileştirilmiş bağlam (ör. bir API anahtarındaki yeni kapsamlar, bir atamadaki önceki ve sonraki son tarih). |
ipAddress | Değişikliğe neden olan isteğin kaynak IP'si. |
createdAt | UTC zaman damgası. |
Tam denetim akışı yönetici UI'sinden (Kurum → Denetim Günlüğü) ya da programatik olarak GET /api/public/v1/audit-log aracılığıyla sorgulanabilir. Her iki yüzey de eyleme, aktöre ve tarih aralığına göre filtrelemeyi destekler; yönetici UI'si ayrıca kanıt paketleri için CSV dışa aktarımı sunar.
Oturum Güvenliği
- Token'lar her API isteğinde doğrulanır
- Geçersiz veya süresi dolmuş token'lar reddedilir
- SSO oturumları IdP oturum politikalarına uyar
- Magic Code'lar tek kullanımlık ve süre sınırlıdır
SecureCodingHub'ın yaptığı kimlik doğrulama tasarım seçimleri ve nedenleri
SecureCodingHub'da varsayılan kimlik doğrulama yolu parolasızdır. Bu kararı bilinçli olarak verdik. Müşteri eğitim verilerinde gördüğümüz kimlik bilgisi ihlallerinin büyük çoğunluğu hâlâ parola tekrar kullanımı, zayıf parola seçimleri ve statik sırların kimlik avına dayanmaktadır. Parolayı birincil giriş akışından çıkarmak, hiçbir politikanın tam olarak hafifletemeyeceği bir başarısızlık modu sınıfını ortadan kaldırır. Geleneksel bir parola yedeği gerektiren kuruluşlar için güncel NIST rehberliğiyle tutarlı asgari değerleri zorunlu kılıyoruz: karmaşıklık kuralları yerine bir uzunluk tabanı, bilinen ihlal edilmiş parola dizinlerine karşı tarama ve ihlal kanıtı olmadan zorunlu rotasyon istemiyoruz.
SSO destekli hesaplar için bile e-posta tabanlı kurtarma bilinçli olarak korunmuştur. Bir kimlik sağlayıcı ulaşılamaz hale geldiğinde ya da bir yüklenicinin kurumsal dizin girdisi iş ortasında kaldırıldığında, doğrulanmış sahibe hesaba dönmesi için belirli ve denetlenebilir bir yola yine ihtiyacımız vardır. Kurtarma kanalı hız sınırlıdır, tek kullanımlıktır ve standart giriş olay akışından ayrı olarak loglanır; böylece güvenlik ekipleri anormal kurtarma etkinliklerini normal giriş gürültüsüne karışmadan tespit edebilir.
Paylaşılan hesaplar ürün düzeyinde tamamen engellenmek yerine caydırılır. Tek bir koltuğun birden fazla kişi tarafından paylaşıldığına dair kullanım kalıpları olduğunda yönetici konsolunda bir uyarı yüzeye çıkarırız; çünkü paylaşılan koltuklar bireysel hesap verilebilirliği bozar, ilerleme raporlamasını çarpıtır ve gelecekteki olay araştırmalarını zorlaştırır. Panellere ekip arası erişime ihtiyaç duyan kuruluşların kimlik bilgilerini yeniden kullanmak yerine Veri Güvenliği bölümünde açıklanan rol atamasını ve SCIM ile sağlanan öğrenci rollerini kullanması gerekir.
Kimlik doğrulamayı uyumluluğa eşleme
SecureCodingHub, SOC 2 Type II'ye hazırlanmaktadır ve henüz denetimi tamamlamamıştır, dolayısıyla sertifika iddiasında bulunmuyoruz. Bununla birlikte, bir güvenlik ekibinin bu denetim için bir satıcıyı değerlendirirken bekleyeceği aynı kontrol aileleri karşısında kimlik doğrulama alt sistemini tasarlıyoruz. SOC 2 CC6.1'in mantıksal erişimle ilgili beklentileri — her kullanıcının benzersiz tanımlanması, hassas eylemler için çok faktörlü ya da eşdeğer adım yükseltme ve işten ayrılışta iptal — kullanıcı başına hesap, ikinci faktör olarak magic code ya da IdP tarafından verilen kimlik bilgisi ve SCIM odaklı hesap kapatma yoluyla karşılanır.
ISO 27001 Annex A.9 erişim kontrolü politikası, kullanıcı kaydı ve ayrıcalıklı erişimi kapsayan kontroller belgelenmiş rol tanımları, istendiğinde doğrulanmış domain'lerle sınırlı kurum kapsamlı kayıt ve her kiracı içindeki açık org_admin / learner rol ayrımı ile karşılanır. PCI DSS bölüm 8'e tabi kuruluşlar için ilgili kontrol, kart sahibi verisini hiçbir zaman saklamadığımız ve kart sahiplerinin platforma karşı kimlik doğrulamadığıdır; SecureCodingHub bir eğitim ortamıdır, ödeme ortamı değildir, dolayısıyla PCI'nin uygulandığı yüzey bilinçli olarak dardır.
Yukarıdakilerin hiçbiri kendi değerlendirmenizin yerine geçmez. Alt işleyici listeleri, veri akış diyagramları ve mevcut denetim duruşu dahil kanıt paketleri talep üzerine security@securecodinghub.com adresinden sağlanır.
SSO etkinleştirildiğinde neler değişir
SSO'yu etkinleştirmek yalnızca bir giriş ekranını diğeriyle değiştirmek değildir — güvenlik ekiplerinin yaymadan önce anlaması gereken birkaç çalışma zamanı davranışını değiştirir. Kuruluşunuz bir kimlik sağlayıcıya bağlandığında, e-postası doğrulanmış domain'inizle eşleşen kullanıcılara yerel magic code yolu artık sunulmaz. Bunun yerine IdP'nize yönlendirilirler. Bu doğru varsayılandır, ama bir IdP kesintisi sırasında kurtarmanın tamamen SecureCodingHub desteğinden BT ekibinize kaydığı anlamına gelir. Büyük bir kullanıcı tabanı için SSO'yu açmadan önce bu yükseltme yolunu kurum içinde belgelemenizi öneririz.
Kilitleme davranışı da değişir: yerel magic code yolunda hız sınırlı başarısız denemeler artık SSO aynı kullanıcı için devredeyken geçerli değildir, çünkü tüm kimlik bilgisi doğrulaması IdP'de gerçekleşir. Kilitleme politikası artık SecureCodingHub varsayılanları tarafından değil, IdP yapılandırmanız tarafından belirlenir. Kullanıcı oturum açtıktan sonra yaptığı mutasyonlar tarafından yazılan denetim günlüğü girdileri kullanıcının e-postasını ve org_admin / learner rolünü taşımaya devam eder; platform şu anda IdP tarafında kimlik doğrulama yönteminin (örneğin MFA'nın IdP'de karşılanıp karşılanmadığı) denetim satırında saklamıyor, bu nedenle o seviyedeki ayrıntı için merkezi kimlik sağlayıcınızın kendi log akışıyla ilişkilendirmeniz gerekir.