好奇心の足跡

飽きっぽくすぐ他のことをしてしまうので、忘れないため・形にして頭に残すための備忘録。

Azure上での権限管理(アクセスコントロール)を考えてみた話

はじめに

こんにちは!kusuwadaです!
Azureを触りはじめて、約1ヶ月が経過しました。
復職して2ヶ月。まさかAzureを触るようになるとは、復職前(いや、正確には1ヶ月前まで)は夢にも思っていませんでした。
AWSマン + ちょびっとGCPマンだったのですが、また新しいクラウドベンダかー!と、AWS vs Azure表なんかを見たりAzureドキュメントを読んだりしながら、お勉強中です。

今回は、Azure上での権限管理について、こんな感じで設定・運用したらどうじゃろうか、というのをまとめてみました。

Azureは、AWSとアカウント・ユーザー・ロール的な考え方が結構違います。AWSはアカウントを開設するごとに、これを使用するユーザーをIAMで作成して権限を付与するのに対し、AzureはAWSのアカウントに(環境という意味で)相当するSubscription、という単位があります。

この辺のことは、このあたりの記事を読むと理解の助けになるかと思います。
Azure と AWS のアカウントとサブスクリプション
AzureはAWSとの比較ドキュメントを結構出してくれていて、AWSから入った勢に親切な印象。

また、Azure サブスクリプション、リソース、ロール、Azure AD の関係 その1 こちらの記事の、 "Azure AD でユーザー認証をして、サブスクリプションというアプリを使う" という説明が端的でわかりやすかったです。

⚠️注意: この記事の内容は2020年9月現在のものです。新しいサービスやサービスの拡張により、この内容が古くなっている可能性がありますことをご承知おきください。

Azure初心者ゆえ、ご指摘などございましたら是非ご連絡ください!

なぜ権限管理が必要なのか

qiita.com

いやぁ、私の記事なんですけどね。良いこと言ってたんでこっちでも引用しておきます。

やらかしがちな事故

  • サービスを商用として運用している場合、システムに影響のあるオペレーションが誰でもできてしまうと、プロジェクトに参画したての初心者がサービスを止めてしまったり・顧客のデータを消してしまったり、ということが起こり得る
  • 普段権限を持っている偉い人ほど、たまに何か確認したりオペレーションしようとすると、操作に慣れておらず「うっかりやらかした!」ということも起こりがち
  • 顧客データを扱うサービスだと特に、誰がどの顧客のデータを閲覧できるかを細かく制御する必要がある
    • 例えば写真管理サービスでStorageに集めた、顧客のプライベートな写真や Database上に保管されたコメントログなどが、開発者が居室から簡単にアクセスして見れる,DLできるというのは問題

他にもまだまだありますが、「閲覧」「編集」「管理者」権限、みたいにざっくりした権限を、恒久的にメンバーにつけていると上記のような事故が発生する可能性が高まります。クラウドベンダ黎明期はどこも上記のような設定しかできず、そこから権限の細分化、昇格機能の登場、と進化してきました。

そこで、

基本的に 必要な人が、必要なときにのみ、(ある程度)必要最小の権限を持つ ようになっていれば良い。これは、セキュリティ系の用語だと 最小権限(特権)の原則, 特権処理の局所化, 職務分離・責務分離の原則 にあたります。

というのを念頭に、どのような設計が良さそうか考えてみましたの記事です。

上記の記事はGCPに関する権限コントロールの考察記事ですが、AWSでもAzureでも考え方は共通の部分が多いので、権限管理が何故必要か、めんどくさくて整理・運用できてないな、という方は是非読んでみてください。

次の Azureの権限管理(基本形) では、この 必要な人が、(ある程度)必要最小の権限を持つ の部分を実現する方法を考えます。
必要なときにのみ というのを実現する方法については、この次の Azureで Switch Role (スイッチロール) する話 で考えたいと思います。

Azureの権限管理(基本形)

権限管理を設計する際は、まずどういった種類のオペレーションがあり、どれくらいの種類の権限が必要かを把握します。細かい事を言い出すと、人ごとに立場やオペレーションが違うので人ごとに付けなければなりませんが、運用コストがかかること・管理しきれず結局ルールがワークしないほうが問題なので、ある程度グルーピングして考えます。

※「最小の」権限を厳密に実現しようとすると、無数にあるAzure Resourceへのアクセス権限の中から allow, deny を選定し、個人ごとに付けていくことになります。が、こんなのメンテも管理も把握もできない予感しかしません。なので、今回は下記のようなグルーピングして考える方式を検討しました。

役割の種類 権限 備考
owner Subscriptionの所有者 1Subscriptionに1人は必要
admin 管理者 何でもできる
auth 権限の管理者 ユーザーやシステムに付与する権限を管理する
pi 顧客の個人情報(pi)にアクセスできる 障害時のデータ復旧作業などができる
operator システム管理者 システムの運用保守・障害の調査などができる
monitor システム監視者 監視用の権限。システムリソースやログを閲覧できる
developer 開発者 開発環境をほぼ自由に使える

これくらいの粒度に分けてみます。

Azureのアカウント管理と権限管理の関係について。この図をご覧ください。

f:id:kusuwada:20200912153450p:plain

個人のアカウントはAzureAD(ActiveDirectory)で管理され、ADに関する権限の管理はこのAzureAD上のロール割当によって制御されます(Azure AD Built in roles)。UserAccountをADに追加する権限だったり、Groupを作成したり、Office製品に関する権限だったり。

そして、各Subscriptionに関する権限の管理は、Subscription内の「アクセス制御(IAM)」で実現されます。これはAzureリソース(VMへのアクセス権限やDBのwrite権限など)に関する権限を管理するイメージで、権限の組み合わせで定義されている Built in roles を Azure AD で管理されている UserAccount、もしくはGroupに割り当てることでアクセス権を付与します。

ここで、先程のグループを管理する方法が2つ考えてみます。

  1. AzureADのgroupを作成
  2. Subscription内のIAMで、各group用のカスタムロールを作成

これまでAWSやGCPで権限周りの事をやってきた時に、1のようにUserをまとめるGroupに対して権限を付与、そのGroupにメンバーを所属させる、という形をとってきたので、今回も最初は1の方向で検討していました。が、AzureのアカウントとSubscriptionの関係が特殊なことを思い出しました。(上の図参照)

1つのAzureAD(組織)に、復数のSubscriptionを作成することが可能で、MicrosoftもSubsctiprionごとにADを作るのではなく、ポリシーやメンバーが同一の組織であれば、一つのADで復数Subscriptionを持つことを推奨しています。
となると、AzureADに作成するGroupは、Subscriptionを超えた存在になり、{subscription-name}-{role-name}などネーミングルールを徹底したりしないと管理が難しそう。ちなみにSubscription内でアカウントのGroupを作成する機能はありません。
また、一つのADに所属するSubscriptionが増えるにしたがって、AzureADのGroupもガンガン増えていきます。各Subscriptionのリソースの操作に関する権限なのに、AzureADにめっちゃ染み出してしまう。

ということで、Subscription内のリソース管理の話は、Subscription内で収めたほうが良かろうと思い、2の方法を選択することにしました。

自分の組織・チーム・プロジェクト・プロダクトに合うように、ロールを設計し、操作するリソースの権限だけをつけるようにします。必要に応じてカスタムロールを作成するとわかりやすいでしょう。今回でいうと、custom-admin,custom-auth,custom-pi,custom-operator,custom-monitor,custom-developer(開発環境のみ)というカスタムロールを作成し、メンバーをどれかに所属させるという運用方法にするとわかりやすいかと思います。

※カスタムロールは、AD内でユニークな名前を付ける必要があるので、復数Subscriptionを作成する場合はSubscription別のprefixをロール名の前につけるなどの対応が必要です

このあたりの話は、公式ドキュメントにも載っています。

Azure RBAC のベスト プラクティス

適切なメンバーに、適切なロールをアサインしておくことで、必要な人が、(ある程度)必要最小の権限を持つ の部分が実現できました。

新しくメンバーが増えた時に、1からポチポチそのメンバーに必要な権限をつけるのではなく、すでに用意してあるロールのどれかにアサインするだけでよいので、運用がとても楽になるはずです。

おわりに

これで、必要な人が、(ある程度)必要最小の権限を持つ までは実現できました。
つぎは、必要なときにのみ について書きたいと思います。

kusuwada.hatenablog.com

まだ触り始めたばかりなので、これから実際運用して知見が溜まったら、この記事も更新したいと思っています(◍•ᴗ•◍)ゝ

参考リンク