ツナ缶雑記

ぐうたらSEのブログです。主にマイクロソフト系技術を中心に扱います。

マネージド ID を使って App Service から SQL Database にアクセスする 前編

f:id:masatsuna:20200720015720p:plain

はじめに

個人的な備忘録をかねて、マネージド ID を用いて App Service に配置した Web アプリケーションから SQL Database にアクセスするまでの手順を3回に分けて解説していきます。 特にユーザー割り当てマネージド ID を用いた接続方法は公式ドキュメントにもあまり解説がなく、読み解くのになかなか苦労しました。

全体の目次は以下の通りです。

内容
前編(本記事) マネージド ID とは一体何かを概念的に解説し、それが Azure Portal 上でそれらがどのように見えるのか、具体的に解説します。
中編 ASP.NET の Web アプリケーションで システム割り当てマネージド ID 、ユーザー割り当てマネージド ID を取り扱う方法について解説します。
後編 Azure 上にアプリケーションを配置して、 App Service 上の Web アプリケーションから SQL Database にアクセスするまでの手順を解説します。

マネージド ID とは

App Service と SQL Database を用いた単純な Web アプリケーションを考えてみましょう。 App Service から SQL Database に対してアクセスするためには、最もシンプルで簡単な方法として、 SQL Database に登録したユーザーアカウント(ログイン ID 、パスワード)を用いる方法がありました。 例えば以下のように、Web.config の connectionStrings セクションに、ログイン ID やパスワードを記入して、 接続文字列を組み立てていました。

  <connectionStrings>
    <add name="Demo0709DbContext"
      connectionString="data source=(localdb)\ProjectsV13;initial catalog=Demo0709Database;User Id=Demo0709User;Password=password1234;MultipleActiveResultSets=True;App=EntityFramework"
      providerName="System.Data.SqlClient"/>
  </connectionStrings>

App Service や SQL Database でも、もちろんこの方法は使えます。 上記の例では接続先がローカル DB になっていますが、これを SQL Database のアドレスに設定することで、ちゃんとつながります。

しかし、この方法には大きな弱点があります。 それは、 SQL Database の接続情報が Web.config にべた書きされてしまうことです。 この接続先がテスト環境ならまだしも、本番環境の接続情報を Web.config 内に記載して、全開発者の目に入るところに置いておくのはセキュアではありません。 内部犯がもしもプロジェクト内にいたら、好き勝手に本番のデータベースにアクセスされてしまうかもしれません。 できる限り接続情報は秘匿しておきたいのです。

そういった要望に応えるために登場したのがマネージド ID です。

認証する、とは何か

認証とは、接続する人が提示したユーザー情報が正しいかを確認することを言います。 前述の例でいえば、接続する人が「Demo0709User」であることを、「Demo0709User」さんしか知らないであろうパスワードを提示してもらうことで確認しているわけです。 ではここでいう「Demo0709User」とは、いったい何者でしょうか。 データベースから見れば、「Demo0709User」とは、このアプリケーションを実行しているエンドユーザーを表すものではありません。 接続してくる Web アプリケーションに対して与えたユーザー情報であると言えます。 すなわち、データベースは接続してくるアプリケーションが、自分自身に接続してもよいアプリケーションなのかを確認している、と考えることもできます。

f:id:masatsuna:20200707010654p:plain
認証のモデル

ここで PaaS の世界を考えてみましょう。 App Service を Web アプリケーションの土台として使用した場合、上図でいうところ「Web アプリ A」は App Service 上で動作することになります。 通常 App Service は 1 つのアプリケーションが 1 つの App Service インスタンス上で動くことになります。 そのため、データベースはアプリケーションではなく、 App Service が誰かを確認することでも、自分自身に接続しても良いアプリケーションを確認することができるようになります。

App Service 自身はただのリソースなので、何も情報を与えなければ、自分が誰かを名乗ることができません。 大雑把に言うと、 App Service 自身に自分が誰か名乗らせる仕組みがマネージド ID なのです。 データベース側から見ると、 App Service が名乗っているマネージド ID を見て、自分自身に接続してもよいか判断することになります。

Azure Portal 上でシステム割り当てマネージド ID を確認する

前述の通り、 App Service 自身は何も情報を与えなければ、自分が誰かを名乗ることができません。 まず App Service 自身に自分の名前を名乗らせる方法を見てみます。

Azure Portal で App Service のインスタンスを作成し、[ID] のメニューから [システム割り当て済み] のタブを選択します。

f:id:masatsuna:20200707012825p:plain
マネージドIDの有効化

すると、図のようにシステム割り当てマネージド ID が無効の状態になっているのがわかるかと思います。 [状態] のスイッチを [オン] に設定して [保存] することで、システム割り当てマネージド ID が有効になります。

f:id:masatsuna:20200707013158p:plain
有効になったシステム割り当てマネージド ID

さて、このようにして有効にしたシステム割り当てマネージド ID ですが、 App Service が勝手に自分自身の名前を名乗ったところで、データベースから見るとそれが本当に正しいのかどうか、確認する手段がありません。 Azure では、この確認のため、作成したシステム割り当てマネージド ID が、Azure AD に登録されるようになっています。 すなわち、 App Service の名乗る名前が正しいかどうかを、 Azure AD によって確認してもらうわけです。

この動作を確認してみましょう。 まず Azure Portal で Azure Active Directory に入ります。 メニューから [エンタープライズ アプリケーション] を選択します。 [アプリケーションの種類] のドロップダウンを [すべてのアプリケーション] に設定して [適用] ボタンを押下してから、 App Service の名前をテキストボックスに入力してみます。

f:id:masatsuna:20200707013805p:plain
エンタープライズアプリケーションの確認

すると、確かに先ほど設定したシステム割り当てマネージド ID が Azure AD に登録されていることが確認できました。

システム割り当てマネージド ID(System Assigned Managed Identity)とユーザー割り当てマネージド ID(User Assigned Managed Identity)

さて、ここまで作成したマネージド ID は「システム割り当てマネージド ID」と呼ばれるものです。 システム割り当てマネージド ID は、App Service のインスタンスに対して 1 つのマネージド ID を割り当ててくれます。 前述の通り、 1 つの App Service インスタンス内に 1 つの Web アプリケーションが配置されているなら、システム割り当てマネージド ID を使用するだけで「私が誰か」を表現できます。 しかし、 1 つの App Service インスタンス内に複数の Web アプリケーションを同居させたいとき、この制限が邪魔になってしまいます。 また複数の App Service インスタンス間や、 Virtual Machine 上のアプリケーションなどで、同じアカウントを共有したい場合も、うまくとりまわすことができません。 こういったときに使うのが、ユーザー割り当てマネージド ID です。

ユーザー割り当てマネージド ID は、 1 つの App Service インスタンスに対して複数割り当てることができます。 また 1 つのユーザー割り当てマネージド ID を、複数の App Service や、 Virtual Machine に割り当てることができます。 ただし、システム割り当てマネージド ID のように、ワンタッチで作成できないデメリットがあります。

ユーザー割り当てマネージド ID を有効にする

では実際に、ユーザー割り当てマネージド ID を作成し、 App Service に対して設定してみましょう。

User Assigned Managed Identity の作成

ユーザー割り当てマネージド ID は、 Azure のリソースとして準備されています。 先ほど登場した App Service と同じリソースグループ内に、このリソースを追加していきます。

f:id:masatsuna:20200713230554p:plain
User Assigned Managed Identity の作成

ユーザー割り当てマネージド ID には、自分で名前を付けてあげる必要があります。 App Service に対して付与するユーザー割り当てマネージド ID ということで、今回はそのリソース名を名前に含めておきます。 同様にして [uami-app-demo0709-02] も作成しておきます。

f:id:masatsuna:20200713231034p:plain
User Assigned Managed Identity に名前を付ける

ここまでの作業を実行すると、以下のようにユーザー割り当てマネージド ID がリソースグループ内のリソースとして確認できるようになります。

f:id:masatsuna:20200713231434p:plain
ユーザー割り当てマネージド ID 作成後

Azure Portal 上でユーザー割り当てマネージド ID を確認する

システム割り当てマネージド ID 同様、ユーザー割り当てマネージド ID も、 Azure AD に登録されます。 登録されている場所はシステム割り当てマネージド ID と同じで、 [エンタープライズアプリケーション] の [すべてのアプリケーション] から確認できます。

f:id:masatsuna:20200713231843p:plain
ユーザー割り当てマネージド ID の確認

App Service に User Assigned Managed Identity を割り当てる

続いて、作成したユーザー割り当てマネージド ID を App Service のインスタンスに対して割り当てていきます。 Azure Portal で作成済みの App Service のインスタンスを選択し、「ID」のメニューを選択します。 [ユーザー割り当て済み] のタブを選択します。

f:id:masatsuna:20200713234902p:plain
ユーザー割り当て済み タブを選択

[+追加] ボタンを押下して、作成した 2 つのユーザー割り当てマネージド ID を選択し、追加します。

f:id:masatsuna:20200713235341p:plain
ユーザー割り当てマネージド ID を選択

しばらく待つと、ユーザー割り当てマネージド ID が App Service に対して設定されます。

f:id:masatsuna:20200714000405p:plain
ユーザー割り当てマネージド ID の追加完了

まとめ

今回は前編として、システム割り当てマネージド ID (System Assigned Managed Id)、ユーザー割り当てマネージド ID (System Assigned Managed Id)の概要を解説しました。 またそれらが Azure Portal 上でどのように見えるのか、具体的にどのように作成・設定を行うのかを解説しました。

次回以降このように設定したマネージド ID を活用したアプリケーションの実装方法についてみていきたいと思います。