ロールベースのアクセス制御 (RBAC) を設計する
Azure RBAC を使用すると、自分が制御する Azure リソースに対するアクセス権を付与できます。 Azure RBAC は、アクセスの各要求を評価し、アクセスをブロックするか、許可しないか、許可するかを決定します。
RBAC は許可モデルです。 "許可モデル" とは、ユーザーに特定のロールが割り当てられていると、Azure RBAC はユーザーがそのロールに関連付けられたアクションを実行するのを許可することを意味します。 ロールの割り当てによって、リソース グループの読み取りアクセス許可がユーザーに付与される場合があります。 書き込みアクセス許可を持つには、ロールで書き込みアクセスが明示的に許可されている必要があります。
Azure RBAC について知っておくべきこと
Tailwind Trader の開発、エンジニアリング、マーケティング チームについて、Azure 内のリソースへのアクセス許可を管理する必要があるものとします。 ここでは、Azure RBAC を使用して実装できるシナリオをいくつか紹介します。
あるユーザーにサブスクリプション内の仮想マシンの管理を許可し、別のユーザーに仮想ネットワークの管理を許可します。
データベース管理者グループのメンバーに、サブスクリプション内の SQL データベースの管理を許可します。
あるユーザーに、仮想マシン、Web サイト、サブネットなど、リソース グループ内のすべてのリソースの管理を許可します。
あるアプリケーションに、リソース グループ内のすべてのリソースへのアクセスを許可します。
Azure RBAC を使用するときに考慮すべきこと
あなたには、Tailwind Traders のアプリケーションに Azure Policy の設定を適用する方法に関する計画があります。 ここでは、Azure RBAC を統合してユーザー特権とリソース アクセスを制御する方法を検討します。
各要件の最高のスコープ レベルを検討します。 最初のステップは、各ロールの定義とそのアクセス許可を正確に定義することです。 次に、特定のユーザー、グループ、サービス プリンシパルにロールを割り当てます。 最後に、ロールのスコープを、管理グループ、サブスクリプション、リソース グループ、またはリソースに設定します。 要件を満たす最も高いレベルのスコープで各ロールを割り当てます。
各ユーザーのアクセス ニーズを検討します。 アクセス制御戦略を計画するときのベスト プラクティスは、ユーザーが作業を実行するために必要な最低限の特権をユーザーに付与することです。 この方法を使用すると、チーム メンバーの責任を簡単に分離できます。 ロールとスコープを制限することで、セキュリティ プリンシパルが万が一侵害された場合にリスクにさらされるリソースを制限します。 次の例のような図を作成し、Tailwind Traders の Azure RBAC ロールの計画に役立てることができます。
ユーザーではなくグループにロールを割り当てることを検討します。 ロール割り当てをより管理しやすくするために、ロールをユーザーに直接割り当てないようにします。 代わりに、グループにロールを割り当ててください。 ロールをグループに割り当てると、ロールの割り当ての数を最小限に抑えるのに役立ちます。
どのようなときに Azure ポリシーを使うか検討します。 Azure ポリシーは、リソースのプロパティに注目するために使われます。 デプロイ中は、Azure ポリシーを使って、ユーザーがリソース グループの特定の仮想マシンのみをデプロイできるようにすることができます。 Azure ポリシーと Azure RBAC の組み合わせを使うと、Tailwind Traders ソリューションでの効果的なアクセス制御を提供できます。 次の表では、これらのアクセス モデルを比較します。
Azure Policy Azure RBAC 説明 リソースを規則のセットに準拠させるための定義済みポリシー。 きめ細かなアクセス制御を提供する認可システム。 主なフォーカス リソースのプロパティが対象。 ユーザーがアクセスできるリソースが対象。 実装 規則のセットを指定します。 ロールとスコープを割り当てます。 既定のアクセス 既定では、ポリシーの規則は "許可" に設定されます。 既定では、すべてのユーザーのすべてのアクセスが "拒否" されます。 どのようなときにカスタム ロールを作成するかを検討します。 場合によっては、組み込みロールでは必要なレベルのアクセス権が付与されないことがあります。 カスタム ロールを使用すると、組織の特定のニーズを満たすロールを定義できます。 カスタム ロールは、同じ Microsoft Entra ID を信頼するサブスクリプション間で共有できます。
重複するロールの割り当てを解決する方法を検討します。 Azure RBAC は加算方式のモデルであるため、自分で行ったロール割り当ての合計が自分の実際のアクセス許可になります。 ユーザーは、サブスクリプション スコープで共同作成者ロールを付与され、リソース グループで閲覧者ロールを付与されているとします。 共同作成者アクセス許可と閲覧者アクセス許可を足すと、実質的にサブスクリプションの共同作成者ロールになります。 そのため、この場合、閲覧者ロールの割り当ては効果がありません。