情報漏えいを防ぐためにアプリケーションの設定情報はどう管理すべきか。設定ファイル暗号化にない Azure Key Vault の利点とは
はじめに
この記事はトピック「Azure上でセキュアなアプリケーションを作るベストプラクティス」の中の一記事となります。
本稿は、アプリケーションで使われるセンシティブ情報(パスワード等)の保護のベストプラクティスを検討するために、OWASP が提案する設定ファイル暗号化対策と、Azure が提供する Key Vault を比較して、Key Vault に保存する利点を論じています。
Key Vaultには、鍵、証明書、シークレット、ストレージアカウントを扱う機能がありますが、ここでは話を単純化するためシークレットを前提に話をします。鍵、証明書をKey Vaultで扱うことでより高度なデータの保護が実装できますが、それは本稿の範囲外とします。実装は、.NET Framework/Core 前提ですが、他の言語でも似たような機能が用意されています。
OWASPが提案する暗号化対策
アプリケーションにはパスワード(SQL Database等)、アクセスキー（Storge、Redis等）など様々なセンシティブ情報(Sensitive Information)があります。これらは、開発、本番など環境によって異なったものが使われ、ソースコードと別に管理される必要があります。そして、これらの情報の漏洩は、データベースなどに保存された保護対象の機密情報（個人情報やクレジットカード情報等）の漏洩に繋がる危険性があるため、厳重に管理する必要があります。
情報漏洩は、相変わらずセキュリティインシデントの上位にあり、OWASP Top 10-2017/A3-Sensitive Data Exposure OWASP Cheat Sheet の、.NET securityでは、漏洩の防衛方法として設定ファイルの暗号化が推薦されています。また、CWEでも同様の指摘がされています。
-
OWASP Cheat Sheet/.NET securityから
“Lock down the config file. Encrypt sensitive parts of the web.config using aspnet_regiis -pe (command line help)).”
-
Common Weakness Enumeration (CWE) から
上記、OWASPで紹介されてるのは、このProtecting Connection Strings and Other Configuration Information (C#)方法です。リンク先では、RAS証明書でConfigの暗号化をしています。 この方法をステップを簡単にまとめて、課題を明らかにしていきます。
- 証明書（秘密鍵含む）を作成する
- 証明書（秘密鍵含む）をIISのマシンに登録する
- 公開鍵でconfigを暗号化する
- .NET Frameworkの場合、Web.configで暗号を解く用に暗号化プロバイダを設定
上記の手順を取る場合、秘密鍵を含んだ証明書の扱いをどうするかのが課題となります。作成した証明書の官理とIISのマシン（App Service）への登録の２つの場面が証明書の操作となり、その部分では適切なセキュリティコントロールが必要です。 コントロールには人的な作業が入るため、精度は人的部分に依存してしまいます。
Azure Key Vault の優位点
上記のOWASPやCWEで提案されている対策は、Key Vault と比較して古い方法と言わざる得ません、我々は、セキュリティを高めるために、センシティブ情報は分離し、Key Vault に入れることを推薦します。上記の推薦事項のように、Configの一部を暗号化する方法より優れていて、導入もそれほど難しくありません。
導入で少し複雑な部分は、Azure Active Directry(以下 Azure AD)を使ったアクセス管理の部分(後述)ですが、一旦理解してしまえば、それほど高い敷居というわけではありません。Key Vault は、少しのコストで大きな効果があります。
次項では、以下の視点でなぜKey Vaultが重要か、どのような使い方がベストプラクティスなのか、実装のコストはどの程度なのか等を段階を追って説明していきます。
- 分離：アプリケーションとセンシティブ情報は分離する
- 暗号化：センシティブ情報は暗号化して保存する
- アクセス管理：センシティブ情報のアクセスは制限する
- 監査：センシティブ情報のアクセスを監査する
次の記事
お問い合わせはこちらから
問い合わせる