ASP.NET Web アプリで、APIキーなどの "秘密のキー" をどこに保存するべきか?

2014/02/26 追記
始めに訂正を。

以下のコメントを頂戴した。

WEBアプリ前提で書いてるようですが、クライアントアプリケーションで app.config はまずくないですか

言われてはたと気がついた。
たしかにそのとおりである(!)。
以下で引用しているツイートをきっかけにこのエントリを作成したのだが、そちらの命題はどちらかというとサンプルコード公開においてバージョン管理にキーが保管されないようにするにはという観点であったため、app.config でよしとしていた。
しかし一般的なデスクトップアプリケーションやその類においては、app.config やその外部参照ファイルにキーを書いてはダダ漏れである。
よって本エントリを訂正し、ASP.NET Webアプリケーションに限定した内容とする。
なお、一般的なデスクトップアプリケーションやその類においては、ではキーをどう扱ったらよいのか、申し訳ないが自分は知識と経験がないため、言及できない。

それでは、以下。

発端はこちらのツイート。

なんとなく、これのC#ライブラリ作ったんだけど、公開するにあたってAPIキーってどうやってもつのがいいんだろうか。NHK 番組表 API を触る為の Emacs クライアント作った - Thanks Driven Life http://t.co/QSwISs2ft9

— 中村 薫 (@kaorun55) 2014, 2月 10

外部サービスと連携する ASP.NET Web アプリ

昨今の Web アプリケーション開発では、上記の NHK 番組表 API などのように、

• Twitter や Facebook へ投稿する
• Microsoft アカウントで認証を行う

など、外部サービスとの連携を行うことも多い。

それら外部サービスを利用するにあたっては、予め、 "アプリケーションキー" や "APIキー"、"シークレットキー" などと呼ばれる、「秘密のキー」をそれら外部サービスから取得しておくのが一般的だ。

そして Web アプリケーションからは、これら「キー」を添えて外部サービスの API を呼び出すことで、呼び出し元のアプリケーションを認証してもらい、サービスを享受することになる。

さて、Web アプリケーションの実行時はこれらキーを外部サービスに提示して認証する以上、アプリケーションはこれらキーをどこからか取得しなくてはならない。

かといって、その Web アプリケーションのソースコードにこれら秘密のキーを書きこんでしまったらどうなるだろう?

キーをソースに書くのはあり得ません!

大抵の場合は、開発中は本番用とは異なる、開発・テスト用のキーを使って開発やテストを行うはずだ。
なのにソースコードにキーを書きこんでしまったら、開発・テスト中と本番リリースとで、毎回アプリケーションをビルドする羽目になる。

さらにいえば、チームで開発してるとなると、メンバ各々が開発用のキーを使うケースも普通に想定され、そうしたときにはバージョン管理システムにおけるソースコードの衝突が多発してしまう。

また、言うまでもないが、この「秘密のキー」は文字どおり秘密にしておくべきだ。

当たり前だが、このキーはあなたのアプリケーションの「身元」を証明するための「証明書」なので、他の人に開示しないよう注意すべきでなのである。

もしも GitHub をはじめとした外部リポジトリサービスにソース公開するオープンソースプロダクトやサンプル公開を手掛けているきに、ソースコード中にじかに「秘密のキー」を記述してしまい、GitHub で全世界に公開! という状況は避けるべきだ。

くどくど書いたが、要するに、
これら秘密のキーをソースコードに埋め込むのは
「あり得ない」
ということだ。

ではどうするか?

ASP.NET Web アプリケーションでは、これら「秘密のキー」は web.config ないしは app.config 中の appSettings セクションに記述するのが王道だ。

<config>

<appSettings>

<add key="appKey" value="abc123"/>

<add key="appSecretKey" value="456def"/>

</appSettings>

</config>

ソースコード中では、System.Coniguration 名前空間の ConfigurationManager クラスの AppSettings 静的プロパティを通して、web.config または app.config ファイル中に記述された appSetting セクションの内容を読み取り、取得することができる。

var appSettings = ConfigurationManager.AppSettings;

var appKey = appSettings["appKey"]; // = "abc123"

var appSecretKey = appSettings["appSecretKey"]; // = "345def"

※さらなるヒント: @shibayan の SwissKnife.T4.AppSettings T4テンプレートを使うともっとスマートに記述できる。

しかしこれだけではまだ道半ばだ。
普通は web.config ないしは app.config もバージョン管理下におくはずだ。
つまり、このままでは何も解決していないことになる。

しかし、さらに appSettings セクションにはもうひとつ仕掛けがある。

もうちょっと記述を書き足すことで、
appSettings セクションの内容を外部ファイルで上書きできる
のだ。

まず、appSettings セクションに、file 属性で外部ファイルへの相対パスを記述する。

<config>

<appSettings file="hoge.config">

<add key="appKey" value="123abc"/>

<add key="appSecretKey" value="345def"/>

</appSettings>

</config>

※file属性で示す外部ファイルのファイル名に規則・制約はない。

ちなみに、この状態で、hoge.config ファイルが存在しなくても、とりあえずアプリは動作し、ConfigrationManager.AppSettings 静的プロパティも普通に機能する。

しかしここで、下記内容の hoge.config ファイルを作成したとする。

<appSettings>

<add key="appSecretKey" value="xyz789"/>

</appSettings>

※file属性で示す外部ファイルのパスは相対パスなので、この例では hoge.config は web.config や app.config ファイルと同じフォルダに作成する必要がある。

すると、ConfigrationManager.AppSettings 静的プロパティは、もとの web.config や app.config に記述された内容ではなく、
上記 hoge.config によって上書きされた内容
が取得されるのだ。

上記例であれば、appSettings セクションの key="appKey" の内容は hoge.config には記載がないので、web.config ないしは app.config に記述した内容 ("123abc") がそのまま取得される。

しかし key="appSecretKey" の内容は hoge.config に記載があるので、そちらの内容 ("345def" ではなく "xyz789") が取得されるのだ。

この仕組みによって、「秘密のキーに関する部分」と「それ以外の部分」にソースを分離することができる。
web.config ないしは app.config はバージョン管理に登録し、しかし hoge.config はバージョン管理に登録せず、ただし Web アプリケーションの配置時は hoge.config を運用チームによって作成・配置することで、正しい管理と運用が可能となる。

web.config ないしは app.config の appSettings セクションには、以下の要領で、キーの設定が必要な旨を記述してバージョン管理に登録しておけばよいだろう。

<config>

<appSettings file="hoge.config">

<add key="appKey" value="<アプリケーションキーを設定>"/>

<add key="appSecretKey" value="<シークレットキーを設定>"/>

</appSettings>

</config> 

Azure Websites や AppHarbor などの PaaS では

ASP.NET による Web アプリケーションを配置可能な PaaS として代表的な、Windows Azure Websites や AppHarbor。

これら PaaS に、これまでに述べたような外部サービスを利用する「秘密のキー」を伴う Web アプリケーションを配置するにはどうしたらよいか?

勿論これまで説明してきたとおり、hoge.config も一緒に配置することでも機能する。

だがしかし、FTPSでアップロードするならまだしも、Gitリポジトリからの発行とかだと hoge.config はバージョン管理下におくわけにはいかないので、この方法はうまくない。

実はもっと簡単な解決方法があるのだ。

Azure Websites や AppHarbor の、管理 Webコンソール上で "アプリケーション構成" の欄に値を設定すると、アプリケーションから ConfigurationManager.AppSettings 静的プロパティで web.config - appSettings セクションの内容を読み取った時に、
管理コンソールで設定された値が優先して読み取られる
のだ。

例えば Windows Azure Websites において、配置した Web アプリの web.config が下記のとおりであったとして、

<config>

<appSettings file="hoge.config">

<add key="appKey" value="abc123"/>

<add key="appSecretKey" value="<シークレットキーを設定>"/>

</appSettings>

</config> 

Azure Webistes の管理コンソールで下図のとおり設定したとすると、アプリケーションからは下記のとおり値が取得されるのだ。

var appSettings = ConfigurationManager.AppSettings;

var appKey = appSettings["appKey"]; // = "abc123"

var appSecretKey = appSettings["appSecretKey"]; // = "x7y8z9"

これで、開発チームは「秘密のキー」をバージョン管理下におくことなく運用チームにアプリケーションの配置イメージを引き渡し、運用チームが PaaS に配置するのと同時に、PaaS の管理 Web コンソールから本番用の「秘密のキー」を設定することで稼働させることができるようになる。

まとめ

• 「秘密のキー」は web.config や app.config の appSettings セクションに書く
• Web アプリケーションからは ConfigurationManager.AppSettinsg 静的プロパティを介してこの値を読み取る
• 但し web.config/app.config に直に「秘密のキー」を書きこまない。代わりに file 属性を使って外部のファイルで設定値を上書きするように構成する。この外部ファイルはバージョン管理及び Visual Studio のプロジェクトアイテム(発行対象)に含めない。
• 開発やテスト時は、この file 属性で示された外部ファイルを作って、開発・テスト用のキーを設定して作業する。
• PaaS への本番リリース時は、PaaS の管理 Web コンソールに本番用のキーを設定する。

以上、サンプルのソースコードだと、ソースコード中や web.config に直接キーを書きこんでしまう例が見受けられるが、そんなサンプルのソースコードでは教えてくれない「現場のノウハウ」ということで。