Erişim politikaları

Erişim politikaları, rollerin ve grupların üzerine öznitelik tabanlı 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ı, rollerin ve grupların aksi halde izin verecekleri şeyleri kısıtlamak için kullanın; örneğin “hiç kimse tesisin ağı dışından kritik komut gönderemez” veya “firmware yalnızca passkey ile açılmış bir oturumdan atanabilir”. 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 geri çevrilir. Ret her zaman kazanır.
Aksi halde, biri 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 (Ret) politikaları olarak yazın. Koşulları sağlanmayan bir Permit (İzin) politikası hiçbir şeyi reddetmez; istek basitçe rol kararına geri düşer.

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; birkaçı yapmaz, çünkü değerlendirilecek oturumdaki bir üye yoktur (oturum açma işleminin kendisi, cihaz bağlantıları, webhook geri çağrıları, zamanlanmış işler, SCIM gibi bir 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ğu” bilgisini 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 yetkisi olan 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. Kuruluşlar arasındaki ayrım veritabanında satır düzeyinde güvenlik ile zorunlu kılınır. Her zaman önce bir politikayı erişim test aracında ve gölge modunda deneyin.

Politika oluşturma

New policy (Yeni politika) seçeneğini seçin (ya da hazır politikalarla başlamak için Load examples (Örnekleri yükle) seçeneğini kullanın).
Bir Name (Ad), Effect (Etki; Permit (İzin) veya Deny (overrides any permit) (Ret (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çeneğini 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.assign gibi 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çeneğini seçin.
Conditions (Koşullar) altında, her test için Add condition (Koşul ekle) seçeneğini seçin. “Politikanın uygulanması için tüm koşulların sağlanması gerekir (VE).” Save conditions (Koşulları kaydet) seçeneğini 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ış)) değerinden oluşur.

Ö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 bir faktör), `HIGH` (bir passkey)
`environment.ip`	Çağıranın adresi
`environment.now`, `environment.method`, `environment.userAgent`, `environment.host`	Zaman, HTTP yöntemi, tarayıcı, sunucu adı
`action`	Denetlenen 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, not equals ve not in list koşullarını sağlar. Bu nedenle ret kuralları güvenlidir, izin kuralları değildir.

Örnekler

Oturum ikinci bir faktör veya passkey kullanmadıkça kritik ve ham komutları reddedin:

Alan	Değer
Etki	Deny (Ret)
Eylemler	`iot_rpc.send.critical, iot_rpc.send.raw`
Koşul	`subject.acr` not in list (listede değil) `SUBSTANTIAL, HIGH`

contractors grubundaki üyelerin rolleri ne olursa olsun öznitelik yazmasını veya komut göndermesini engelleyin:

Alan	Değer
Etki	Deny (Ret)
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 “ret” isteği 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ı kuru çalıştırı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) ve bir RBAC fallback role (RBAC yedek rolü) girin, sonra Evaluate (Değerlendir) seçeneğini 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 listelenir. Gölge modundaki retler 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. Retler 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.
Kuruluş sahiplerini 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.