Erişim politikaları, roller ve gruplara ek olarak özniteliğe dayalı kurallar (ABAC) ekler. Bir politika kimin istek yaptığına, ne yapmak istediğine ve hangi bağlamda olduğuna bakar ve izin verir veya reddeder. Politikaları, roller ve grupların aksi halde izin vereceği işlemleri kısıtlamak için kullanın; örneğin “hiç kimse tesis ağının dışından kritik komut gönderemez” veya “firmware yalnızca bir passkey ile açılmış oturumdan atanabilir” gibi. Politikalar gelişmiş bir araçtır: çoğu kuruluşun yalnızca roller ve gruplara ihtiyacı vardır.
Owner rolüne sahip olmanız gerekir. Settings > Access Policies yolunu açın (adres /admin/access-policies).
Karar nasıl verilir
Korunan her istek için:
- Hedefi (eylemleri ve kaynak türleri) eşleşen ve tüm koşulları sağlanan her etkin politika, öncelik sırasıyla (düşük değer önce çalışır) toplanır.
- Bunlardan herhangi biri reddederse, istek reddedilir. Ret her zaman kazanır.
- Aksi halde, bir politika izin verirse, istek devam eder.
- Hiçbir politika uygulanmazsa, rol, grup ve matris kararı geçerli kalır (“RBAC yedeği”).
Politikalar ek kısıtlamalardır: gereksinimleri Deny (Reddet) politikaları olarak yazın. Koşulları sağlanmayan bir Permit (İzin ver) politikası hiçbir isteği reddetmez; istek yalnızca rol kararına geri döner.
Politikaların gördüğü istekler
Politikalar, politika motorunu çağıran rotalarda denetlenir. Hermetry’nin sayfalarının ve API rotalarının çoğu bunu yapar; ancak birkaçı yapmaz, çünkü değerlendirilecek oturum açmış bir üye yoktur (oturum açma işleminin kendisi, cihaz bağlantıları, webhook geri çağrıları, zamanlanmış işler, SCIM gibi API anahtarının kendi sözleşmesiyle yapılan istekler). Coverage (Kapsam) sayfası, hangi rotaların motora ulaştığını tam olarak listeler ve diğerleri için “Bunun yerine neyin koruduğunu” gösterir. Bir politikaya güvenmeden önce bunu kontrol edin.
Önemli
IoT sayfaları ve IoT API’si, politikalara eylemi (izni) ve çağıranı iletir, ancak cihaz öznitelikleri iletmez. Tek bir cihaz veya tek bir saha için politika yazamazsınız; cihazları görüntüleme yetkisine sahip bir üye, kuruluşun tüm cihazlarını görür. Birbirinin cihazlarını hiçbir zaman görmemesi gereken kişi grupları varsa, bu cihazları ayrı kuruluşlara koyun. Bir politikayı her zaman önce erişim test aracında ve gölge modunda deneyin.
Politika oluşturma
- New policy (Yeni politika) seçin (veya hazır politikalarla başlamak için Load examples (Örnekleri yükle).
- Name (Ad), Effect (Etki; Permit (İzin ver) veya Deny (overrides any permit) (Reddet; her izni geçersiz kılar)) ve Priority (lower runs first) (Öncelik; düşük değer önce çalışır) girin. Create & edit (Oluştur ve düzenle) seçin.
- Definition (Tanım) bölümünde şunları ayarlayın:
- Actions (comma-separated, empty = all) (Eylemler (virgülle ayrılmış, boş = tümü)):
iot_rpc.send.critical, iot_ota.assigngibi izin kimlikleri. - Resource types (comma-separated, empty = all) (Kaynak türleri (virgülle ayrılmış, boş = tümü)).
- Description (Açıklama): politikanın neden var olduğu.
- Status (Durum): Active (Etkin) veya Inactive (Pasif). Save definition (Tanımı kaydet) seçin.
- Actions (comma-separated, empty = all) (Eylemler (virgülle ayrılmış, boş = tümü)):
- Conditions (Koşullar) altında, her test için Add condition (Koşul ekle) seçin. “Politikanın uygulanması için tüm koşullar sağlanmalıdır (AND).” Save conditions (Koşulları kaydet) seçin.
Koşulu olmayan bir politika, hedefiyle eşleşen her isteğe uygulanır.
Koşullar
Her koşul bir Attribute (Öznitelik), bir Operator (Operatör) ve bir Value (Değer) veya Values (comma-separated) (Değerler (virgülle ayrılmış)) içerir.
| Öznitelik | Anlamı |
|---|---|
subject.role | Yerleşik rol: OWNER, ADMIN, USER |
subject.roles | Rol artı üyenin grup anahtarları |
subject.permissions | Üyenin gruplarının verdiği izinler |
subject.id, subject.email | Üye |
subject.department, subject.jobTitle | Üyenin profilinden, ayarlandığında |
subject.amr | Oturumun nasıl açıldığı: pwd, otp, mfa, hwk (passkey), fed:saml, fed:<provider> |
subject.acr | Buradan elde edilen güvence düzeyi: NONE, LOW (yalnızca parola veya federasyon), SUBSTANTIAL (doğrulanmış ikinci faktör), HIGH (passkey) |
environment.ip | Çağıranın adresi |
environment.now, environment.method, environment.userAgent, environment.host | Zaman, HTTP yöntemi, tarayıcı, sunucu adı |
action | Kontrol edilen izin |
Operatörler: equals (eşittir), not equals (eşit değildir), in list (listede), not in list (listede değil), contains (içerir), greater than (büyüktür), less than (küçüktür), exists (vardır), matches regex (düzenli ifadeyle eşleşir), DN equals (RDN) (DN eşittir (RDN)).
Mevcut olmayan bir öznitelik boş olarak okunur; bu da not equals ve not in list koşullarını sağlar. Bu nedenle ret kuralları güvenlidir, izin kuralları değildir.
Örnekler
Oturum ikinci faktör veya passkey kullanmadıysa kritik ve ham komutları reddedin:
| Alan | Değer |
|---|---|
| Etki | Reddet |
| Eylemler | iot_rpc.send.critical, iot_rpc.send.raw |
| Koşul | subject.acr not in list (listede değil) SUBSTANTIAL, HIGH |
Rolü ne olursa olsun, contractors grubundaki üyelerin öznitelik yazmasını veya komut göndermesini engelleyin:
| Alan | Değer |
|---|---|
| Etki | Reddet |
| Eylemler | iot_device.attributes.write, iot_rpc.send.basic, iot_rpc.send.privileged |
| Koşul | subject.roles contains (içerir) contractors |
Bir hakkı yalnızca tek bir gruba vermek için, genellikle Access Rights (Erişim Hakları) matrisi bir politikadan daha basittir: Admin için izni kaldırın ve grup için işaretleyin. Bkz. Groups and permissions (Gruplar ve izinler).
Gölge modu, erişim test aracı ve karar günlüğü
| Araç | Konum | Kullanımı |
|---|---|---|
| Shadow Mode (Gölge Modu) | Politikalar sayfasındaki Settings (Ayarlar) (Access Control Settings (Erişim Denetimi Ayarları)) | “Politikalar değerlendirilir ve kararlar günlüğe kaydedilir, ancak bir “reddetme” İSTEĞİ ASLA engellemez.” Varsayılan olarak kapalıdır. Yeni bir politikayı zorunlu kılmadan önce açın, günlüğü izleyin, sonra kapatın. |
| Access tester (Erişim test aracı) | Simulator (Simülatör) | “Canlı politikalara karşı bir kararı deneme çalıştırması yapın — hiçbir şey kalıcı olarak kaydedilmez veya günlüğe yazılmaz.” Subject id (Özne kimliği), Subject role (Özne rolü), Action (Eylem), Resource type (Kaynak türü), Resource ownerId (Kaynak ownerId), Environment IP (Ortam IP’si) ve bir RBAC fallback role (RBAC yedek rolü) girin, ardından Evaluate (Değerlendir) seçin. Policy trace (Politika izi) her politikanın hedefini ve kurallarını gösterir. |
| Decision log (Karar günlüğü) | Decision log (Karar günlüğü) | Değerlendirilen her istek; Effect (Etki), Action (Eylem), Reason (Neden; Policy permit (Politika izni), Explicit deny (Açık ret), RBAC fallback (RBAC yedeği), Default deny (Varsayılan ret), Not applicable (Uygulanamaz)) ve Subject (Özne) ile birlikte. Gölge modundaki reddler Shadow (Gölge) olarak işaretlenir. |
Decision Log Mode (Karar Günlüğü Modu) (All decisions (Tüm kararlar), Deny only (Yalnızca ret), Off (Kapalı); varsayılan tümü) ve Permit Log Sample Rate (%) (İzin Günlüğü Örnekleme Oranı (%)) denetim günlüğüne ne kadarının gireceğini belirler. Reddler her zaman günlüğe yazılır.
İyi uygulamalar
- Load examples (Örnekleri yükle) ile başlayın ve kendi politikalarınızı yazmadan önce bunları okuyun.
- Dar eylem listeleriyle ret politikaları kullanın. Eylemi olmayan politikalardan kaçının: her isteği değerlendirirler.
- Sahipleri asla kilitlemeyin: her politikayı erişim test aracında bir owner rolüyle test edin.
- Değişiklikler her düğümde hemen geçerli olur.