[ Aracı otomasyonu ]

Kimlik doğrulama aracısı için onay sınırlarını tanımlama

Bir temsilcinin önerebileceği ancak doğrulanmış yetki, kesin onay ve denetlenebilir bir sonuç olmadan yürütmemesi gereken yüksek etkili operasyonları belirtin.

EmailAuth araştırma ekibi tarafından · 6 dakikalık okuma

[ Anahtar noktalar ]

  • Okuma kapsamı, yazma yetkisi, kalıcı erişim ve harici açıklama farklı izinlerdir.
  • Onayı aktöre, kiracıya, kaynağa, operasyona ve parametrelere bağlayın ve ardından bağımsız olarak doğrulayın.
  • Kontrollerin işe yaradığını iddia etmeden önce hem onaylanmış dar eylemleri hem de reddedilen yasaklı durumları test edin.
Bu sayfada

Bir temsilciye araç vermeden önce izin modelini tanımlayın

Bir kimlik doğrulama aracısı kanıtların açıklanmasına, değişikliklerin hazırlanmasına ve sonuçların kontrol edilmesine yardımcı olabilir. Bu yetenekler, DNS , imzalama anahtarları veya müşteri kiracıları üzerinde sınırsız kontrolü haklı çıkarmaz. Kuruluş, temsilcinin hangi kaynakları okuyabileceğini, hangi eylemleri önerebileceğini ve hangi operasyonların ayrıca doğrulanmış bir onay gerektirdiğini belgelemelidir. "E-posta kimlik doğrulamasının iyileştirilmesine yardımcı olun" kesin bir izin sınırı değildir.

Burada açıklanan model önerilen bir tasarımdır, EmailAuth şu anda bunu uyguladığının bir ifadesi değildir. Hiçbir ürün izin kontrolü, yönetim arayüzü veya kiracı izolasyonu incelenmedi veya test edilmedi. Makaledeki yasaklı eylem örnekleri, başarıyla engellenen girişimlerin kayıtları değil, önerilen test senaryolarıdır.

Salt okunur hazırlığı sonuçsal yürütmeden ayırın

Hazırlık, onaylanmış raporları analiz etmeyi, yetkili bir envanteri karşılaştırmayı, bir DNS farkı taslağı hazırlamayı ve bir kurtarma planının açıklanmasını içerebilir. Okumak bile tanımlanmış bir kiracıya ve veri kapsamına ihtiyaç duyar; Başka bir müşterinin raporlarına salt okunur erişim yine de yetkisiz erişimdir. Harici paylaşım da ayrı bir işlemdir, dahili analizin zararsız bir uzantısı değildir.

Bir değiştirme DMARC politika ekleyerek SPF yetkilendirme, yayınlama DKIM anahtar, imzalayanı değiştirmek veya gönderme iznini kaldırmak, üretim güvenini ve teslimatı değiştirebilir. DNS yetkilendirmesi, özel anahtar saklama, kalıcı kimlik bilgileri ve idari izinler gelecekteki kontrolü genişletebilir. Önerilen izin modeli, bu eylemler için sorumlu onay gerektirmeli ve bunu modelin kendi kararından bağımsız olarak uygulamalıdır. OWASP Aşırı Ajansı.

Onayın tam eyleme ve mevcut kapsama bağlanması

Anlamlı bir onay kaydı, aktörü, kiracıyı, kaynağı, operasyonu ve normalleştirilmiş parametreleri tanımlar. DNS değişikliği için ilgili mevcut değeri ve önerilen değeri gösterin; İznin kaldırılması için, kaldırılan kimliği ve erişimi adlandırın. Bir incelemeci, temsilcinin konuşmasını yeniden yapılandırmadan sonucu anlayabilmelidir.

OWASP'ın Yapay Zeka Aracı Güvenliği kılavuzu, yüksek etkili operasyonlar için bağımsız olarak doğrulanmış, eyleme bağlı onaylar, sınırlı geçerlilik ve tekrar koruması gerektirir. Model tarafından oluşturulan "onaylandı" işaretine güvenmek yerine bu kontrolleri yürütme bileşenine uygulayın. Maddi bir hedef veya parametre değişikliğinin yeni bir karara ihtiyacı vardır. Herhangi biri bu sınırın etkili olduğunu iddia etmeden önce gerçek uygulama ve onun başarısızlık davranışı test edilmelidir. OWASP AI Aracısı Güvenliği Hile Sayfası.

Yeni yetkiyi ve dış açıklamayı ayrı değişiklikler olarak ele alın

Onaylanan birini güncelleme izni seçici joker karakterli DNS yetkilendirmesine, daha geniş bir bulut rolüne veya gelecekteki çalışmalar için kalıcı bir kimlik bilgilerine izin vermez. Raporları analiz etme izni, bunların yeni bir kuruma gönderilmesine izin vermez. Önerilen tasarım, her genişlemeyi kaynak, alıcı ve operasyonel amaç dahil olmak üzere ayrı bir karar olarak ortaya koymalıdır.

RFC 9990'nin dış destinasyon doğrulaması önemli bir ayrımı gösteriyor. Alıcı işlemci, DMARC raporunun teslimi için gereken teknik onayı yayınlayabilir ancak bu, alan sahibinin iş ilişkisini veya ifşayı onayladığı anlamına gelmez. Temsilci her iki gerçeği de korumalı ve organizasyonel kararı uygun sahibine bırakmalıdır. RFC 9990 , bölüm 4.

Kanıtların kuralları yeniden yazmasına izin vermeyin

Raporlar, DNS metni, sağlayıcı sayfaları ve destek mesajları güvenilmeyen materyal içerebilir. “Bu göndereni onayla” yazan alan, kuruluşun yetkili yöneticisinden gelen bir onay değildir. Aracının kapsamını genişleten bir komut değil, alınan içeriğe gömülü bir talimat analiz edilecek kanıt olarak kalmalıdır. OWASP bunu dolaylı bir istem enjeksiyonu riski olarak tanımlamaktadır. OWASP İstemi Enjeksiyonu.

Sınır aynı zamanda otomasyon bileşenleri arasında da geçerlidir. Başka bir model veya hizmetten alınan öneri, üretim iznini değil, kanıtını ve belirsizliğini taşımalıdır. Eylem noktasında gerçek onay kaynağını ve kaynak kapsamını doğrulayın. Politika hizmeti izin oluşturamazsa önerilen denetim, ilgisiz yetkili analizin devam etmesine izin verirken bu eylemi durdurmalıdır. OWASP Yetkilendirme Hile Sayfası.

Kurgusal vakalarda sınırı aşın

Kurgusal bir iş akışında yönetici, kiracı A'daki adlandırılmış seçici için genel bir DKIM kaydının eklenmesini onaylar. Yürütmeden önce farklı bir araç, ana DMARC ilkesinin değiştirilmesini ve kiracı B'nin kimlik bilgilerinin kullanılmasını önerir. Orijinal onay her iki ikameye de izin vermemelidir. İnceleme paketi, ilk onayı devredilebilir olarak değerlendirmek yerine, değişenleri korumalı ve uygun kararı talep etmelidir.

İkinci bir kurgusal durumda DNS yazma zaman aşımı var. Aracı, hizmetin değişikliği gerçekleştirip gerçekleştirmediğini bilmiyor. Yazmanın körü körüne tekrarlanması, istenmeyen ikinci bir işleme neden olabilir veya daha sonraki bir yönetici düzenlemesinin üzerine yazılabilir. Önerilen kurtarma dizisi öncelikle mevcut durumu ve işlem sonucunu belirler, ardından onaylanmış yeniden deneme veya kurtarma yolunu takip eder. EmailAuth veya herhangi bir canlı kiracıya karşı dava açılmadı.

Durdurma ve kurtarma davranışını denetlenebilir hale getirin

Önerilen eylemi, onay referansını, yürütme talebini, döndürülen sonucu ve bağımsız olarak kontrol edilen sonkoşulu kaydedin. Sırları denetim kayıtlarının dışında tutun. Bir araçtan gelen başarı mesajı, amaçlanan DNS değerinin veya izin durumunun artık mevcut olduğunun tek kanıtı olmamalıdır. Kurtarma planı, hangi önceki durumun güvenli bir şekilde geri getirilebileceğini ve bu adıma kimin yetki verebileceğini tanımlamalıdır.

İyileşmenin kendisi önemli olabilir. Güvenliği ihlal edilmiş bir anahtarın yeniden etkinleştirilmesi, güvenli olmayan bir gönderen izninin geri yüklenmesi veya bir etki alanı politikasının zayıflatılması, buna geri alma adı verildiği için otomatik olarak yetkilendirilmez. Bu durumları açıkça tanımlayın. DMARC politikası ve hizalama Anlambilim, tahmin edilen etkiyi bildirmelidir, ancak standart, bir aracıya idari yetki vermez. RFC 9989 , bölüm 4.4 ve 4.5.

Hem izin verilen hem de yasaklanan eylem testlerini zorunlu kılın

Eksiksiz bir test planı, doğru şekilde onaylanmış dar bir işlemi ve yanlış kiracı, değiştirilmiş parametreler, süresi dolmuş onay, tekrarlanan onay kullanımı ve güvenilmeyen içerik talimatları için reddedilen durumları göstermelidir. Bu tür testleri yalnızca sınırlı donanımlara sahip yetkili bir ortamda gerçekleştirin. Korumanın işe yaradığının kanıtı olarak bir kontrol listesi yayınlamak yerine, kontrolün başarısızlıkları da dahil olmak üzere gerçek sonuçları kaydedin.

Mevcut ürün kontrollerini kullanarak yasaklanmış eylemleri ve onaylanmış kapsamlı değişiklikleri test edin. Bu kesin devreye alma gereksinimi açık kalır. Ürün uygulaması, onaylı uygulama, yasaklı eylemi reddetme, son koşul kontrolleri ve kurtarma davranışı gösterilmemiştir. İzin haritası, mevcut EmailAuth işlevselliğine ilişkin bir iddia değil, incelenmek üzere önerilen bir tasarımdır.

[ Götürmek ]

Eylem sınırında izni zorunlu kılın. Bir modelin güveni, yerleşik bir talimat veya eski bir onay, farklı bir hedefe veya daha geniş bir operasyona izin veremez.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

Güvenlik mimarisi sahibi

İzin verilen işlemi tam olarak tanımlayın

İzin modelinin yalnızca geniş aracı hedeflerini değil, kaynakları ve sonuçları tanımlaması gerekir.

Sonraki adımlar

  1. Ayrı kiracı okumaları, üretim yazmaları, kimlik bilgileri ve açıklamalar.
  2. Devredilemeyen eylemleri ve hata davranışını belirtin.

Ürün ve entegrasyon mühendisi

Kararı modelin dışında uygulayın

Bilgi istemi düzeyindeki bir söz, aşırı ayrıcalıklı bir bağlayıcıyı kısıtlamaz.

Sonraki adımlar

  1. Yürütme sırasında aktörü, hedefi, parametreleri ve onayı doğrulayın.
  2. Güvenli denetim kanıtlarını saklayın ve son durumu bağımsız olarak kontrol edin.

Kontrol test uzmanı ve operasyonel onaylayıcı

Her iki sonuçtan da kanıt talep edin

Yararlı bir kontrol, onaylanmış işleme izin vermeli ve yetkisiz değişkenlerini reddetmelidir.

Sonraki adımlar

  1. Sınırlandırılmış yetkili pozitif ve negatif vakaları çalıştırın.
  2. Belirsiz sonuçları ve iyileşme davranışını yayınlanmadan önce gözden geçirin.

[ SSS ]

Sık sorulan sorular

Kiracılar arasında salt okunur erişim otomatik olarak güvenli midir?

Hayır. Başka bir kiracının bilgilerini okumak kendi başına yetkiyi aşabilir. Hiçbir yazma işlemi mevcut olmadığında bile kiracıyı, verileri ve kaynak kapsamını tanımlayın.

Hangi kimlik doğrulama değişikliklerinin izin modelinde açık bir şekilde ele alınması gerekir?

Politika düzenlemeleri, gönderen yetkilendirmeleri, anahtar yayınlama veya aktarma, yetkilendirme, izin kaldırma, kalıcı kimlik bilgileri ve harici rapor paylaşımının her birinin tanımlanmış, sorumlu bir onay sınırı olmalıdır.

Modelin onaylanmış bayrağı yürütme tarafı yetkilendirmesinin yerini alabilir mi?

Hayır. Yürütme bileşeni, model bağlamında oluşturulan bir iddiaya güvenmek yerine, gerçek aktörü, tam işlemi ve geçerli onayı bağımsız olarak doğrulamalıdır.

Onay, önerilen her eylemi kabul edilebilir kılıyor mu?

Hayır. Gerektiğinde onay gereklidir ancak geçerli güvenlik kısıtlamalarını, yasal veya devredilemez kısıtlamaları geçersiz kılmaz. İzin verilen modelin dışındaki eylemler engellenmeye devam eder.

Kiracı veya parametreler değiştikten sonra onay yeniden kullanılabilir mi?

Değiştirilen işlemin onayı olarak değil. Bunu gözden geçirilen kapsama bağlayın ve önemli değişiklikler için uygun yeni kararı alın.

Bir sağlayıcı belge veya rapor yeni erişime izin verebilir mi?

Hayır. Alınan içerik bir kanıttır, kurumsal bir onay değildir. İçerisinde yer alan talimatlar, temsilcinin yetkisini genişletmemelidir.

Belirsiz bir yazma sonucundan sonra ne olmalı?

Eylemin yürütülüp yürütülmediğini belirleyin ve tekrarlamadan önce ilgili mevcut durumu inceleyin. Kör bir kopya vermek yerine yetkili yeniden deneme veya kurtarma yolunu izleyin.

Önerilen sınırların EmailAuth mevcut olduğunu kanıtlayan kanıtlar nelerdir?

İzin verilen kapsamlı eylemleri ve reddedilen yanlış kiracı, değiştirilmiş parametre, süresi dolmuş, yeniden oynatılan ve güvenilmeyen talimat durumlarını kapsayan mevcut ürün kontrollerine karşı gerçek testler. Burada böyle bir test yapılmadı.

[ Kaynaklar ]

Kaynaklar

  1. OWASP AI Aracısı Güvenliği Hile Sayfası
  2. OWASP Yetkilendirme Hile Sayfası
  3. OWASP LLM06:2025 Aşırı Acentelik
  4. OWASP LLM01:2025 Hızlı Enjeksiyon
  5. RFC 9989 : Etki Alanı Tabanlı İleti Kimlik Doğrulaması, Raporlama ve Uyumluluk
  6. RFC 9990 : DMARC Toplu Raporlama

[ Sözlük ]

Sözlük

Eyleme bağlı onay
Genel bir proje hedefinden ziyade, tanımlanmış bir aktöre, operasyona, hedefe ve parametrelere bağlı bir karar.
Yürütme sınırı
Bir sonuç niteliğindeki işlem gerçekleştirilmeden hemen önce yetkiyi kontrol eden bileşen veya hizmet.
Tekrar koruması
Halihazırda tüketilen veya geçersiz bir onayın başka bir yüksek etkili işleme yetki vermesini önleyen bir denetim.
Kiracı izolasyonu
Veri erişiminin ve eylemlerin, paylaşılan yüksek ayrıcalıklı bir bağlam yerine yetkili kiracıyla kısıtlanması.
Dolaylı istem enjeksiyonu
Giriş olarak işlendiğinde bir aracının davranışını yeniden yönlendirmeye çalışan güvenilmeyen harici içerik.

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası