Yapay zekâ tarafından English dilinden çevrildi ·
2.0.1 sürümünden itibaren kendi erişim gruplarınızı oluşturabilirsiniz. Bu, bir test organizasyonunda, herhangi bir şey eklemeden önce Settings > Access Control bölümünün Groups sekmesidir.
Yerleşik roller burada, her birinin anahtarı, sahip olduğu izin sayısı ve üyeleriyle birlikte gruplar olarak görünür: Owner (OWNER) 1426 ile, Admin (ADMIN) 1343 ile ve User (USER) 294 ile. Organizasyonun tek bir üyesi vardır, o da sahibi. Yerleşik roller sabittir. Sayıları planınızdaki modüllere bağlıdır, çünkü sahip olmadığınız bir modül hiçbir izin eklemez.Şimdi bir tesis ekibi. Diyelim ki bir tesisin operatörlerinin cihazları düzenlemesi ve öznitelik yazması gerekiyor, ama cihaz kimlik bilgilerini görmemeli ve ayarlara dokunmamalılar. Onları Admin yapmak, bunların hepsini ve daha fazlasını onlara verir. Bunun yerine:
- New group. Anahtar
plant.north.operators, etiket “North plant operators”. Anahtar daha sonra değiştirilemez ve denetim günlüğünde ve erişim politikalarında görünür, bu yüzden düzgün bir ad verin. - Create, grubu açın ve izinlerini işaretleyin. Bu durum için, User’ın zaten sahip olduklarına ek olarak
iot_device.devices.updateveiot_device.attributes.write. - Users sekmesinde, onları User olarak bırakın ve grubu ekleyin.
Gruplar rolün izinlerine yalnızca ekler; hiçbir zaman izin almazlar. Bir grup, bir üyeyi Admin asgari seviyesinin üzerine çıkarabilir, ancak Owner seviyesinin üzerine asla çıkaramaz; bu yüzden ham komutlar, firmware imzalama anahtarları ve sahiplik devri, grup ne derse desin sahiplerde kalır.Bir gruptaki Active anahtarı kullanışlıdır: etkin olmayan bir grup üyelerini korur ama hiçbir yetki vermez. New group yanındaki From template… seçeneği, diğer grup gibi düzenleyebileceğiniz hazır bir grup ekler.Sonucu kişi bazında, üyenin üye sayfasındaki, etkin erişimi gösteren Permissions sekmesinden kontrol edin. Dokümantasyon: Groups and permissions.
Since 2.0.1 you can make your own access groups. This is the Groups tab of Settings > Access Control on a test organisation, before I add anything.
The built-in roles appear here as groups, each with its key, the number of permissions it holds and its members: Owner (OWNER) with 1426, Admin (ADMIN) with 1343 and User (USER) with 294. The organisation has one member, the owner. The built-in roles are fixed. Their numbers depend on the modules your plan has, since a module you don’t have adds no permissions.
Now a plant team. Say the operators of one plant need to edit devices and write attributes, but must not see device credentials or touch settings. Making them Admin hands them all of that and much more. Instead:
- New group. Key
plant.north.operators, label “North plant operators”. The key can’t be changed later and it shows up in the audit log and in access policies, so name it properly. - Create, open the group, and tick its permissions. For this case
iot_device.devices.updateandiot_device.attributes.write, on top of what User already has. - On the Users tab, leave them as User and add the group.
Groups only add permissions to the role; they never take one away. A group can lift a member over an Admin minimum, never over an Owner one, so raw commands, firmware signing keys and ownership transfer stay with owners whatever a group says.
The Active switch on a group is handy: an inactive group keeps its members but grants nothing. From template… next to New group adds a ready-made group that you can then edit like any other.
Check the result per person on their member page, Permissions tab, which shows effective access. Docs: Groups and permissions.
Yapay zekâ tarafından English dilinden çevrildi ·
Peki ya diğer yön? User seviyesinde olan ve hiçbir komut göndermemesi gereken yükleniciler var. Gruplar yalnızca izin ekliyorsa, bunu onlardan nasıl alabilirim?
And the other direction? We have contractors at User level who should not send any commands at all. If groups only add, how do I take that away from them?
Yapay zekâ tarafından English dilinden çevrildi ·
İki yol var.Hiçbir Kullanıcının komut göndermemesi gerekiyorsa, Erişim Hakları sekmesinde Kullanıcı için iot_rpc.send.basic seçeneğinin işaretini kaldırın.Yalnızca taşeronlar için geçerliyse, onları bir gruba ekleyin (anahtar contractors, örneğin) ve bir Reddet erişim politikası ekleyin: eylemler iot_rpc.send.basic, iot_rpc.send.privileged ve iot_device.attributes.write, koşul subject.roles contains contractors. Reddetme, herhangi bir izni geçersiz kılar. Politikalar için Sahip rolü gerekir. Uygulamadan önce önce gölge modunu açın ve karar günlüğünü birkaç gün izleyin.
Two ways.
If no User should send commands, untick iot_rpc.send.basic for User on the Access Rights tab.
If it’s only the contractors, put them in a group (key contractors, say) and add a Deny access policy: actions iot_rpc.send.basic, iot_rpc.send.privileged and iot_device.attributes.write, condition subject.roles contains contractors. A deny wins over any permit. Policies need the Owner role. Turn on shadow mode first and watch the decision log for a few days before you enforce it.
Yapay zekâ tarafından English dilinden çevrildi ·
Bir grup yalnızca tek bir tesisin cihazlarıyla sınırlandırılabilir mi? Yani kuzey operatörleri yalnızca kuzey cihazlarını görebilsin mi?
Can a group be limited to one plant’s devices? So the north operators only see north devices?
Yapay zekâ tarafından English dilinden çevrildi ·
Hayır. Eylem üzerinde gruplar ve politikalar karar verir; IoT sayfaları politikalara cihaz özniteliği iletmez, dolayısıyla cihazları görüntüleme yetkisi olan bir üye, organizasyondaki tüm cihazları görür. Kuzey tesisinin güney tesisin cihazlarını hiçbir zaman görmemesi gerekiyorsa, bunlar iki ayrı organizasyonda olmalıdır. Tek bir hesap, her birinde farklı bir rolle, ikisinin de üyesi olabilir.
No. Groups and policies decide on the action, and IoT pages pass no device attributes to policies, so a member who may view devices sees all devices of the organisation. If the north plant must never see the south plant’s devices, they belong in two organisations. One account can be a member of both, with a different role in each.
Yapay zekâ tarafından English dilinden çevrildi ·
Paketleme hattımız için buna benzer bir operatörler grubu oluşturdum. Üye sayfasındaki Permissions sekmesi benim bir hatamı yakaladı: attributes write seçeneğini işaretlemiş, devices update seçeneğini unutmuştum; bu yüzden özellikleri değiştirebiliyorlardı ama bir cihazın adını değiştiremiyorlardı.
Did an operators group like this for our packaging line. The Permissions tab on the member page caught a mistake for me, I had ticked attributes write and forgotten devices update, so they could change attributes but not rename a device.
- Bu konuyu yanıtlamak için giriş yapmış olmalısınız.
Sohbete katılın
Soru sormak ve yanıtlamak, yararlı gönderileri beğenmek ve sorununuzu çözen yanıtı işaretlemek için oturum açın. Her katkı puan ve seviye kazandırır.