次の方法で共有


複数のビジネス ユーザーの RBAC 構成の例

多くの Azure Sphere のお客様は、エンジニアリング チームがエンジニアリング所有のデバイスとデバイス グループに対して開発関連の機能を実行できるように RBAC アクセスを構成したいと考えていますが、エンジニアリング チームが運用チームによって通常管理される運用デバイス グループに直接アクセスできないようにしたいと考えています。 次のシナリオでは、一連の RBAC ユーザー グループとアクセス許可を構成して、エンジニアリング チームと運用チームの両方に、必要な機能とリソースにのみアクセスできるようにする方法について詳しく説明します。 多くの Azure Sphere のお客様は、独自の Azure Sphere デバイスを設計し、現場で管理しますが、多くの場合、契約製造元と提携してデバイスを構築します。 このビジネス モデルでは、多くの場合、次の 4 つの異なる Azure Sphere ユーザー プロファイルが得られます。

  • Azure Sphere 製品所有者 ユーザーです。新しい Azure Sphere カタログとその子リソースを作成、構成、管理する必要があるユーザーのための最高特権の Azure Sphere ユーザー グループです。これには、カタログへのデバイスの要求 (要求されたデバイスをそのカタログのみに永続的に関連付ける)、既存の Azure Sphere (レガシ) テナントを Azure Sphere (統合) カタログに統合するなど) が含まれます。
  • 製品エンジニア ユーザー - イメージや証明書など、カタログ リソース自体に属するアイテムに対する特権を必要とするが、カタログに属するすべてのデバイス グループ (機密性の高い運用デバイス グループなど) に対する権限を持つ必要がないユーザーに対して行われます。 このユーザー グループは、特に、デバイス機能ファイルのダウンロード、開発、フィールド テスト、およびフィールド テスト OS 評価デバイス グループ間でのデバイスの移動、および新しいソフトウェアの展開とフィールド テストおよびフィールド テスト OS 評価デバイス グループでのクラッシュ ダンプ ファイルの収集を行うが、実稼働 OS 評価デバイス グループで運用デバイスの管理を許可されていない製品開発ユーザーに適しています。
  • フリート オペレーター ユーザー – 運用デバイス フリートを管理するユーザー向け。新しいソフトウェアおよびファームウェア イメージを展開し、場合によってはクラッシュ ダンプ ファイルの収集を有効にして、運用 OS 評価デバイス グループで OS 小売評価リリースが期待どおりに動作するかどうかを検証するために、運用デバイス グループへのアクセス許可を必要とします。
    • デバイスの製造元 ユーザーです。これは、新しく製造されたデバイスをデバイス所有者の Azure Sphere カタログに要求する一般的な自動化された製造プロセスを目的としています。 デバイスの製造元は、カタログを参照したり、要求および一括要求機能以外の Azure Sphere ユーザー アクションを実行したりする必要はありません。

RBAC 構成の例を参照してください。

Azure RBAC のベスト プラクティスに従って、各ユーザー グループには、ビジネス機能に必要なアクセス許可のみが付与されます。 たとえば、製品エンジニアリング グループはカタログ内のすべてのデバイスを表示できますが、アクションを実行できるのはエンジニアリング指向のデバイス グループ (開発、フィールド テスト、フィールド テスト OS) 内のデバイスのみです。 デバイスの製造元ユーザーは、カタログに対してデバイスを要求できますが、カタログ リソースを参照したり、要求されたデバイスに対してそれ以上のアクションを実行したりすることはできません。

ユーザー グループ Azure RBAC ロール リソース スコープ 特権が有効化されました
Azure Sphere 製品所有者 (1a) Azure Sphere 製品所有者 リソース グループ • リソース グループ内で Azure Sphere カタログを作成、統合、削除する
• リソース グループ内の Azure Sphere リソースに RBAC ロールを割り当てる
• Azure Sphere ユーザー アクションを実行する
• リソース グループ内の Azure Sphere デバイス リソースの Azure Monitor データを構成して表示する
製品エンジニアリング (2a) Azure Sphere Publisher Azure Sphere カタログ • すべてのカタログ リソースの読み取り専用アクセス
• カタログに画像を追加する
• デバイスの開発を可能にするデバイス機能をダウンロードする
• カタログ証明書情報のダウンロード
製品エンジニアリング (2b) Azure Sphere 共同作成者 開発、フィール ドテスト、フィールド テストOS評価デバイス グループ • OS フィード、サード パーティ製アプリの展開、クラッシュ ダンプ設定のデバイス グループのプロパティを設定する
• これらのグループ内のデバイスに新しいイメージを展開する
• これら 3 つのグループに対してのみ、デバイスの割り当てと割り当て解除を行う
• リソース グループ内の Azure Sphere デバイス リソースの Azure Monitor データを構成して表示する
艦隊運用 (3a) Azure Sphere 閲覧者 Azure Sphere カタログ • すべてのカタログ リソースの読み取り専用アクセス
• カタログ証明書情報のダウンロード
フリート運用 (3b) Azure Sphere 共同作成者 運用デバイス グループと運用 OS 評価デバイス グループ • OS フィード、サード パーティ製アプリの展開、クラッシュ ダンプ設定のデバイス グループのプロパティを設定する
• これらのグループ内のデバイスに新しいイメージを展開する
• これら 2 つのグループに対してのみ、デバイスの割り当てと割り当て解除を行う
デバイスの製造元 (4a) Azure RBAC カスタム ロール (以下の詳細を参照) Azure Sphere カタログ • デバイスの要求と一括要求のみ

Device Manufacturer ユーザーの Azure RBAC カスタム ロールの構成 Azure Sphere の組み込み RBAC ロールは多くの一般的なユース ケースを提供しますが、Azure RBAC カスタム ロールが必要になる場合があります。 カスタム ロールを使用すると、ユーザーに対して許可されている特定の個々のアクションを有効にすることができます。 このサンプル シナリオでは、デバイスの製造元がデバイスをカタログに要求できるようにするカスタム RBAC ロールを構成する必要がありますが、デバイスの製造元が他のユーザー 操作を実行したり、カタログ内の他のリソース (イメージ、製品、デバイス グループなど) を参照したりすることはできません。

デバイス製造ユーザーがデバイスを要求できるようにするには、カタログの要求機能と一括要求機能の両方を有効にするカスタム ロールを作成します。

ユーザー アクション 許可 説明
主張 書き込み: Devices_CreateOrUpdate 一度に最大 5 台のデバイスを要求する
一括要求 書き込み: DeviceGroups_ClaimDevices 一度に 5 台を超えるデバイスを要求する

警告

  • Azure Sphere (レガシ) テナントを Azure Sphere (統合) カタログに統合する必要があるユーザーには、テナントが属するサブスクリプションを所有するリソース グループに、Azure Sphere 共同作成者 または Azure Sphere 共同作成者 ロールが適用されている必要があります。

  • ユーザーに RBAC ロールを割り当てることができるのは製品またはデバイス グループだけですが、その親カタログでは割り当てられませんが、ユーザーは Azure ホーム画面から製品またはデバイス グループ、またはその親カタログを検索できません。 製品またはデバイス グループには、直接指す URL を介してのみアクセスできます。 ユーザーの利便性を高めるために、すべてのユーザーが少なくとも Azure Sphere Reader カタログへのアクセス権を持っていることをお勧めします。