はじめに
前回は "Azure上での権限管理（アクセスコントロール）を考えてみた話" と題して、Azure上で権限管理をどうするかについて書いてみました。
今回は、Azure上での AWS で言うところの "Switch Role" ってどうするの？について書いてみたいと思います。
基本的に 必要な人が、必要なときにのみ、(ある程度)必要最小の権限を持つ ようになっていれば良い。これは、セキュリティ系の用語だと 最小権限(特権)の原則, 特権処理の局所化, 職務分離・責務分離の原則 にあたります。
の、必要な人が、(ある程度)必要最小の権限を持つ については前回の記事で、必要なときにのみ については今回の記事で実現します。
注意: この記事の内容は2020年9月現在のものです。新しいサービスやサービスの拡張により、この内容が古くなっている可能性がありますことをご承知おきください。
何を実現したいのか
「商用環境で時々作業する予定あるんだけど、いつもはダッシュボード見るだけでいいんだよねー。」とか、「障害発生でデータのバックアップリカバリしなきゃいけないから、個人情報の入ったDBにアクセスする必要ができちゃった！」といった状況がやって来ることは、容易に想像がつくと思います。
普段は、うっかり商用環境を落としちゃったり、個人情報をうっかり見ちゃったり、といったことができない、安全で弱い権限を持っておき、作業が発生するときだけ作業に必要な権限に昇格する仕組みが欲しい。
これは、AWSだとswitch roleという機能があり、最近では使っている人もとても増えていると思います。
ほか、
- 誰かどの時間、強い権限を持っていたか記録したい
- 本番環境を変更する権限に昇格する際に、承認を必須としたい
- 特に個人情報DBなどにアクセスできる権限は、短い時間だけの昇格を許可したい
といった要望もあるかと思います。
何か事故・事件が起きた時に、調査のために権限を保有していた人を記録しておくのは有効です。また、オペレーターが自分で昇格するのではなく、リーダーや管理者の承認を得るようにすることで、作業内容の把握や透明性がアップします。
重要な情報にいつでもアクセスできる・商用環境を変更できる権限を持っている、もしくはその権限にいつでも自由に昇格できるメンバーがいる、というのは心臓にも悪いです。ちょっと昼寝してる間に頭でキーボード連打して本番環境のDB消しちゃった、なんて達人も現れるかもしれません。
また、この仕組は、内部犯の抑止・防止という面でも役に立ちます。考えたくないことですが、内部犯はセキュリティインシデントの原因の大きな一つですし、犯人にできることが多い分、被害も大きくなりがちです。権限を管理・記録しているという抑止力、時間制約のある権限昇格の仕組みは内部犯が発生する確率を下げてくれることでしょう。
そこで Privileged Identity Management (PIM) 機能です。
Privileged Identity Management (PIM) で実現できること
こちらに、実現できること、使用する理由が書いてあります。素晴らしい。
実現できること一覧を、ここにも引用しておきます。
- Azure AD と Azure のリソースに対する Just-In-Time の特権アクセスを提供する
- 開始日と終了日を使用した期限付きアクセス権をリソースに割り当てる
- 特権ロールをアクティブ化するために承認を要求する
- ロールをアクティブ化するために多要素認証を強制する
- なぜユーザーをアクティブ化するのかを把握するために理由を使用する
- 特権ロールがアクティブ化されたときに通知を受ける
- 継続してユーザーにロールが必要であることを確認するためにアクセス レビューを実施する
- 社内監査または外部監査に使用する監査履歴をダウンロードする
この機能は、Subscription内のロール、カスタムロールにも使えるようになったので、前の記事で作成したカスタムロールに対して設定することも可能です。
承認者に関しては、AzureADのアカウントかGroupを選べるので、承認者が複数いる・入れ替わりが激しい場合は、承認者Groupを作成して承認できるアカウントを入れて管理するのもありだと思います。
また、同じ組織内でもSubscriptionが違うと承認者も変わる、というケースに於いては、Subscriptionごと、もしくは体制ごとにGroupを作っておくのもよいかと思います。
というわけで、商用環境でのシステムアップデート作業が発生したケースを考えてみます。
普段は monitoring、すなわち監視系の閲覧権限しか持っていないメンバーが上記作業を行う時に、予め作っておいたカスタムロール(ここでは仮に operation)に昇格して作業を行います。
組織によって「昇格の証跡が残っており、後から参照できればOK」というケースもあると思いますし、「誰かしらの承認が必要」としたいケースもあると思います。PIM機能ではそのどちらも実現できます。
さらに、作業が終わっても特権を外し忘れる、なんて事はよくあるかと思います。その対策として、期間指定の昇格を設定する事もできます。これで指定した時間が経過したら、自動的に降格してくれます。重要な作業中に権限が外れないように注意する必要がありますが、権限外し忘れはあるあるすぎるので積極的に使っていきたい機能です。
昇格先のロールによって、「このロールには○時間までしか昇格できない」というように、期間指定の時間の上限を決めておくこともできます。
上記のシステムアップデートのシナリオだと、
- 作業時間は長くとも5時間と想定し、5時間の期間指定とする
- 商用環境なので承認を必須とする
- 承認にあたって理由が知りたいので理由も必須とする
- 権限昇格時にはMFAを必須とする
- 権限の昇格が発生したことを、必要なメンバーにメールで通知する
みたいな設定ができます。できることが多いですね！
さらに、監査用の履歴を作成してくれ、ダウンロードできるなんて素敵すぎます。使わない手はない。
ライセンス上の注意
PIM機能を利用するには、AzureADのライセンスが必要になります。
詳細は、Privileged Identity Management を使用するためのライセンスの要件を見ていただければと思います。
ざっくりいうと、AzureADのライセンスには、Premium P1とPremium P2があり、それぞれ $6/user/month, $9/user/monthの料金がかかります。PIM機能の利用には、P2のライセンスが必要になります。
また、P1とP2では、それぞれ必要なライセンス数が違うことに注意してください。
Premium P1ライセンスでは、例えば「条件付きアクセス」の機能を使って、ユーザーが自分でパスワードリセットができるようにする設定にしていたとします。
この設定は全ユーザーが恩恵を受けるので、全ユーザー分のライセンス購入・ライセンス適用が必要です。
逆にPremium P2ライセンスでは、P2の対象の機能を利用するユーザーにのみ来仙を適用すれば良いので、例えば「ダッシュボードを見るだけで実環境は触らないユーザー」のライセンスは購入する必要がありません。ただし、上記の自分でパスワードリセットができる設定をしているのであれば、このユーザーにはP1のライセンスが必要になります。
設計の例
設定の手順や、設定に必要なロールなどは公式ドキュメントをご参照ください。
ここでは、自分が最初にPIM機能を利用する時に悩んだ点、知りたかった点を書きます。
設定できる対象
いま公式ドキュメントを改めて見てみた所、ここに書いてありました。
Privileged Identity Management で管理できないロール
参照したドキュメントや記事が古いと、AzureADのロールしか管理できないように見えるんですが、ちゃんとAzureロール（Azure RBACに使用される、各SubscriptionのIAMロール）も対象です。独自に作成したカスタムロールも対象のようです！
対象外のものとしては、従来のサブスクリプション管理者ロールが挙げられていますが、現在そもそもざっくりしたロールすぎるということで非推奨ですし、PIM機能を使いたい組織・チームはより細かいロール管理をしていると思うのであまり気にしなくて良さそう。
本記事ではOffice365は対象にしていませんが、対象外のロールもあるようです。
権限昇格までのフロー例
触ってみて、実際にどんな動きで権限昇格が行われるか見てみました。ここでは、PIMの設定がすでに行われている前提です。
- 作業者はAzureのPortal > Privileged Identity Management から、昇格したい権限を選択し、期間と承認理由を記載
- 昇格の要求がメールで承認者(複数の場合は複数)に通知
- 承認者が AzureのPortal > Privileged Identity Management で内容を確認、承認
- 作業者に昇格先の権限がアクティブになる
- 作業者に昇格の通知がメールで届く
- 作業終了後、作業者は自身で権限を非アクティブにする、もしくは指定した期間が過ぎて自動で非アクティブになる
この流れはメールとAzurePortalを使っていますが、CLIが使えるのであればSlackなど好きなツール上で回すこともできそうです。
CLIについて
PIM support #13064 のリクエストによると、"Azure CLI currently has no native support for Privileged Identity Management" ということで azure cliのサポートはまだのようです。
ただ、ここで示されている通り、GraphAPIは使用できるようなので、どうしてもCLIで操作したい場合はこちらが使えそうです。
Graph API や CLI を利用すれば、設定の自動化や、権限昇格操作・承認の流れをslackなどのチャットツールと連携したりして、より便利に使えそうですね。
ロールの割り当てとアクティブ化
Privileged Identity Management は、「ロールの割り当て」と「アクティブ/非アクティブ化」という操作で成り立っています。
ロールは、予め「非アクティブな状態で割り当てておく」ことも、割り当てないこともできます。（アクティブな状態の割り当ては、すなわち昇格機能を使わずずっとロールが使える状態なので、PIM機能の目的とずれる）
非アクティブな状態で割り当てられたロールに関しては、作業差が自身でPIM機能を通じて昇格の要求を送ることができます。一方割り当てがない場合は、権限管理者に別パスで連絡してロールを割り当ててもらうなど、ロールを割り当ててもらうところから始めることになります。
こちらは、昇格頻度の高そうなメンバーだけ非アクティブな割り当てをしておく運用にしてもいいですし、可能性のあるメンバー全員に割り当てておく運用でもよいかと思います。
個人的には
- 商用環境のDeployや障害対応できる権限には、担当する可能性のあるメンバーに非アクティブな割り当て
- 個人情報を閲覧・データリカバリなど操作する権限には、割り当てを予めしない
みたいな使い分けが良いかな、と思っています。下の権限は、承認者がうっかり「はいはーい、OK！」って内容をあまり水に承認してしまうリスクと、昇格頻度を考えると、割り当てなしの運用でも良いかな、と。
割り当てなしの運用は、PIMを使うメリットが有るのか？と思ったのですが、昇格の期間を設定できる・理由を残せる・監査の際に提出できる、といった大きな恩恵を受けることができるのでした。
承認なしで昇格
こちらも、今回昇格機能を導入するのに欲しいと思っていた機能です。
上でも少し触れましたが、どういうケースで使えそうか、もう少し触れておきます。
昇格にあたり、承認不要のフローも設定できます。
これは、承認者自身が昇格対象のロールや、比較的軽い権限のロールに対して考えうるフローです。
たとえ承認を不要にしても、先程と同様、「昇格の期間を設定できる・理由を残せる・監査の際に提出できる」といった恩恵を受けることはできるので、設定しておくに越したことはないと思います。
この場合のフローは、先ほど紹介した"権限昇格までのフロー例"から、承認の部分を削ったフローになります。
おわりに
以上、Azureで権限昇格、AWSで言うswitch roleをする話でした。
昇格できる時間を明示的に指定したり、理由まで書ける承認フローが用意されていたりと、かなり使いやすそうな印象を受けました。
まだ触り始めたばかりなので、これから実際運用して知見が溜まったら、この記事も更新したいと思っています。
