Hacker DirectoryHacker Directory
Öğrenmeye devam et
ENHTML kaydet ↓

WEB / CASE tenant-and-object

Kimlik doğrulandı; rapor izni nerede?

Duru ve Ekin’in Atlas raporları için subject, action, object, tenant ve relationship koşullarını birlikte oku.

Gözlem dosyası

Duru member; verified tenant atlas. report-atlas-02 Ekin’e ait. İstenen action report.read. Teaching policy aynı tenant içinde owner read veya reviewer read’e izin verir. Bu örneğin policy’si evrensel bir RBAC kuralı değildir.

Kararı açıkla

Duru’nun login başarısı owner relationship’i değiştirmez. Fixture’da expected decision DENY, reason OWNER_REQUIRED’dır. Ekin reviewer olarak aynı Atlas raporunu okuyabilir; Orion raporunda tenant mismatch kontrolü reviewer’dan önce gelir.

Bir audit allow kaydı yalnız o subject/action/object/context için kanıttır. UI’da düğmenin görünmesi server kararı değildir. Field-level representation kontrolü de action izninden ayrı değerlendirilebilir.

Kontrol ve doğrulama

Sabit policy matrisinde own read, other owner, other tenant, no verified context ve unknown action dallarını karşılaştır. Deny branch’leri protected body taşımaz. Audit minimal actor/action/object/decision alanlarını kaydeder; session secret içermez.

SIRA SENDE

Bu hikâyeyi sen çöz.

Sonucu tahmin et, kanıtın sınırını bul ve nedenini kendi cümlenle anlat.

Duru’nun verified Atlas context’i bu report.read kararını neden allow yapmaz? Policy ve object kaydını birlikte oku.

Sentetik vaka dosyasından seçilen gözlemler

subject
Duru
role
member
verified tenant
atlas
object
report-atlas-02
owner
Ekin
action
report.read
teaching policy
same tenant AND (owner read OR reviewer read)
  1. Verified login bütün Atlas raporlarının okunmasına izin verir.
  2. DENY / OWNER_REQUIRED; Duru owner değil, reviewer da değil.
  3. DENY / TENANT_MISMATCH; report-atlas-02 başka tenant’a aittir.
Gerekçeli cevabı oku

DENY / OWNER_REQUIRED; Duru owner değil, reviewer da değil. — Karar server’daki subject/action/object/tenant/relationship koşullarının birlikte değerlendirilmesine dayanır. Başarılı login owner metadata’sını değiştirmez. OWNER_REQUIRED bu örneğin reason’ıdır; evrensel RBAC sonucu değildir.

Ekin’in Atlas raporu için allow kaydı görülüyor. “Reviewer her tenant’ın raporunu okuyabilir” sonucu neden desteklenmez?

  1. Reviewer rolü tenant kontrolünü bu policy’de gereksiz yapar.
  2. UI’da düğme varsa server’ın diğer tenant için kararı da allow’dur.
  3. Allow yalnız aynı context içindir; Orion object’te tenant mismatch önce değerlendirilir.
Gerekçeli cevabı oku

Allow yalnız aynı context içindir; Orion object’te tenant mismatch önce değerlendirilir. — Yanlış genelleme, gözlenen allow’un subject/action/object/context kapsamını siler. Role, tenant ve object relationship birlikte okunur; UI görünürlüğü bunların yerine geçmez.

Bu teaching policy için olumlu ve olumsuz regression matrisini yaz. Deny body ve audit alanları açısından neyi kontrol edersin?

Gerekçeli cevabı oku

Own read’in izin koşullarını ve same-tenant reviewer read’i olumlu kontrol olarak korurum. Other owner/member, other tenant, verified context yokluğu ve unknown action dallarını ayrı deny kontrolleriyle karşılaştırırım. Deny response protected body taşımaz. Audit actor/action/object/decision gibi gerekli alanları kaydeder, session secret içermez. Bu matris yalnız verilen teaching policy’yi doğrular; bütün RBAC sistemleri için sonuç üretmez.

□ Meşru own/reviewer read olumlu kontrol olarak kaldı mı?

□ Owner, tenant, verified context ve unknown action deny dalları ayrı mı?

□ Deny protected body taşımıyor ve audit secret içermiyor mu?

□ Sonuç teaching policy kapsamıyla sınırlandı mı?

Bu vakayla bağlantılı dersler · 23

Bu derslerdeki kavramlarla vakaya dön. Bağlantılar vaka kaydına yeni gözlem eklemez; farklı sorumlulukları birlikte incelemene yardımcı olur.