RFC 7516, JSON Web Encryption veya kısa adıyla JWE yapısını tanımlar. JWE, içerik şifreleme anahtarının nasıl korunduğu ile gerçek payload verisinin nasıl şifrelendiğini birbirinden ayırır. Compact Serialization veya JSON Serialization biçiminde kullanılabilir.
RFC 7516 JSON Web Encryption: Hızlı Bakış
| Standart | RFC 7516 |
|---|---|
| Korumalı içerik | Plaintext, JWT veya uygulama verisi |
| Anahtar yönetimi | alg parametresi |
| İçerik şifreleme | enc parametresi |
| Compact bölümleri | Beş bölüm |
RFC 7516 JSON Web Encryption Neden Önemlidir?
Dağıtık sistemlerde kullanıcı, token ve yetkilendirme verileri farklı servisler arasında taşınır. RFC 7516 JSON Web Encryption ortak bir şifreleme yapısı sağlayarak özel ve birbiriyle uyumsuz çözümlerin azalmasına yardımcı olur.
Ancak JWE kullanılması, payload içindeki verinin otomatik olarak yetkili veya güvenilir olduğu anlamına gelmez. Şifre çözme işleminden sonra içerik türü, veri şeması, issuer, audience, süre ve uygulama yetkileri ayrıca doğrulanmalıdır.
RFC 7516 JSON Web Encryption İçin 10 Kritik Güvenlik Kontrolü
1. alg ve enc İçin İzin Listesi Tanımlayın
Anahtar yönetimi ile içerik şifreleme algoritmalarını ayrı ayrı doğrulayın. Uygulamanın beklemediği veya güvenlik politikasından çıkarılmış algoritmaları reddedin.
2. Authenticated Encryption Kullanın
Şifreli metnin değiştirilmesini algılayan AEAD tabanlı enc seçeneklerini tercih edin. Authentication tag doğrulanmadan plaintext hiçbir işleme verilmemelidir.
3. Her Mesaj İçin Benzersiz IV Üretin
Seçilen algoritmanın gerektirdiği uzunlukta, öngörülemez ve tekrar etmeyen IV kullanın. IV tekrarları bazı şifreleme kiplerinde gizliliği ciddi biçimde zedeleyebilir.
4. Anahtar Kaynağını Doğrulayın
kid veya jku değerini sınırsız ağ erişimi için kullanmayın. Alıcı anahtarı güvenilir yapılandırmadan seçilmeli ve anahtar ikamesi saldırıları engellenmelidir.
5. Protected Header Bütünlüğünü Koruyun
alg, enc, zip, typ ve crit gibi güvenlik kararını etkileyen alanları korumalı başlıkta taşıyın. Korumasız alanların şifreleme politikasını değiştirmesine izin vermeyin.
6. Şifre Çözme Hatalarını Tek Biçimli Yönetin
Yanlış anahtar, geçersiz etiket ve bozuk biçim hatalarında istemciye farklı teknik ayrıntılar vermeyin. Ayrıntılı hata yanıtları saldırganlara oracle sağlayabilir.
7. zip Kullanımını Sınırlayın
Şifreleme öncesi sıkıştırma, saldırgan kontrollü veri ile gizli veriler birlikte işlendiğinde uzunluk sızıntısı yaratabilir. Açık ihtiyaç yoksa zip parametresini reddedin.
8. İç İçe JWT Sırasını Sabitleyin
İmzalama ve şifreleme birlikte kullanılıyorsa işlem sırasını, typ ve cty değerlerini ve her iki güvenlik katmanının doğrulanmasını açıkça tanımlayın.
9. Plaintext Boyutunu ve Türünü Denetleyin
Şifre çözme sonrasında içeriğin türünü, şemasını ve boyutunu doğrulayın. Aşırı büyük veya beklenmeyen yapıdaki verileri alt sistemlere göndermeyin.
10. Anahtar Rotasyonu ve Geri Alma Testi Yapın
Yeni anahtarın dağıtılmasını, eski mesajların kabul süresini ve ele geçirilmiş anahtarın iptalini test edin. Anahtarların sınırsız süre etkin kalmasına izin vermeyin.
RFC 7516 JSON Web Encryption Uygulama Örneği
protected = BASE64URL({
"alg": "RSA-OAEP-256",
"enc": "A256GCM",
"cty": "JWT"
})
cek = RANDOM_CONTENT_ENCRYPTION_KEY()
iv = UNIQUE_RANDOM_IV()
ciphertext, tag = AEAD_ENCRYPT(
cek,
iv,
plaintext,
protected
)
encrypted_key = WRAP(recipient_public_key, cek)
Bu örnek yalnız işlem sırasını gösterir. Üretim ortamında gerçek anahtarlar, algoritmalar ve anahtar yönetim sistemi kuruluşun tehdit modeline göre seçilmelidir.
Sık Yapılan Uygulama Hataları
- alg ile enc alanlarını birbirine karıştırmak
- Aynı IV değerini birden fazla mesajda kullanmak
- Authentication tag doğrulanmadan plaintext işlemek
- Uzak anahtar adreslerini kontrolsüz çağırmak
- Şifrelemeyi kimlik doğrulama veya yetkilendirme yerine kullanmak
Üretim Ortamı Kontrol Sırası
- JWE yapısının beklenen bölüm sayısını içerdiğini doğrulayın.
- alg ve enc değerlerini sunucu izin listesiyle karşılaştırın.
- Alıcı anahtarını güvenilir anahtar deposundan seçin.
- Authentication tag doğrulanmadan plaintext üretmeyin.
- Şifre çözülen verinin türünü ve uygulama yetkilerini kontrol edin.
Testler; bozuk ciphertext, yanlış anahtar, değiştirilmiş protected header, geçersiz authentication tag, IV tekrarı ve eski anahtar senaryolarını kapsamalıdır. Günlük kayıtlarında plaintext veri, şifreleme anahtarı veya hassas kullanıcı bilgisi bulunmamalıdır.
İlgili Tekno Türkiye İçerikleri
RFC 7662 Token Introspection, RFC 9449 DPoP ve RFC 8414 Authorization Server Metadata rehberlerini de inceleyebilirsiniz.
Sık Sorulan Sorular
JWE ile JWS arasındaki fark nedir?
JWE gizlilik ve bütünlük sağlar. JWS ise içeriği gizlemeden imza veya MAC ile korur.
Compact JWE kaç parçadan oluşur?
Protected header, encrypted key, IV, ciphertext ve authentication tag olmak üzere beş parçadan oluşur.
JWE içinde JWT taşınabilir mi?
Evet. İçerik türü cty alanıyla belirtilebilir ve içte bulunan JWT ayrıca doğrulanmalıdır.
Şifre çözme başarılıysa veri güvenilir midir?
Hayır. Yalnız şifreleme katmanı doğrulanmıştır. Payload şeması, issuer, audience ve yetki kontrolleri ayrıca uygulanmalıdır.
Essential Uygulama Özeti
RFC 7516 JSON Web Encryption uygulanırken giriş doğrulama, anahtar yönetimi ve bağlam kontrolleri birlikte ele alınmalıdır. RFC 7516 JSON Web Encryption yalnız veri biçimi olarak görülmemeli, uçtan uca güvenlik politikasıyla desteklenmelidir. Her RFC 7516 JSON Web Encryption dağıtımı negatif testler ve gözlemlenebilir güvenlik kayıtları içermelidir. Güvenli bir RFC 7516 JSON Web Encryption uygulaması authentication tag doğrulanmadan plaintext verisini kullanmaz.
Resmî Kaynaklar
Sonuç
RFC 7516 JSON Web Encryption, doğru anahtar yönetimi ve sıkı doğrulama kurallarıyla uygulandığında hassas verilerin güvenli ve standart biçimde taşınmasını sağlar.
