ナビゲーションをスキップする

Azure Functions と App Service を使用したサーバーレスと Web アプリのセキュリティの単純化

11月 28, 2018 に投稿済み

Senior Program Manager, Azure Functions

サーバーレスと PaaS は、一言でいうと、管理上の負担を軽減し、最も重要なこと、つまりアプリケーション ロジックに集中できるようにすることで開発者の生産性を向上させるサービスです。セキュリティを犠牲にすることはできませんが、ベスト プラクティスを簡単に達成できるようにする必要があります。App Service と Azure Functions プラットフォームには、アプリのセキュリティ確保の負担を大幅に軽減する機能が多数あるので、お役立ていただけます。

本日、新しいセキュリティ機能を発表いたします。この機能によって、マネージド ID およびシークレットを処理するために必要なコードの量を減らすことができます。これには次のものが含まれます。

  • アプリケーション設定の Key Vault 参照 (パブリック プレビュー)
  • ユーザー割り当て済みマネージド ID (パブリック プレビュー)
  • App Service on Linux/Web App for Containers のマネージド ID サポート (パブリック プレビュー)
  • Azure Functions の ClaimsPrincipal バインディング データ
  • CORS config の Access-Control-Allow-Credentials のサポート

Microsoft は、Azure のリソース全体のセキュリティのためのプライマリ ハブとして Azure Security Center に引き続き投資しています。これは、構成上の脆弱性を突き止めて解決したり、脅威にさらされる状態を軽減したり、攻撃を検出したり、それに対処したりすることができるからです。たとえば、自分はすべてのアプリを HTTPS だけに限定しているから大丈夫、と思われるかもしれませんが、Security Center を使用すれば万全を期すことができます。もしまだであれば、是非お試しください。

難しい話は抜きにして早速、これらの新しい機能の詳しい説明に入りたいと思います。

アプリケーション設定の Key Vault 参照 (パブリック プレビュー)

Microsoft Ignite 2018 では、アプリが Key Vault からアプリケーション設定を取得できるようにする新しい機能のプレビューをご紹介しました。本日、その機能のパブリック プレビューが利用可能になったことを発表いたします。

ますます多くの組織が、シークレット管理ポリシーの保護に移行しています。本当にありがとうございます。Azure Key Vault は、アクセス ポリシーと監査履歴を完全に制御しながら、シークレットに信頼できる 1 つのソースを提供します。App Service と Azure Functions の既存のアプリケーション設定機能は安全であるとみなされ、シークレットが静的に暗号化されていますが、必要としているこれらの管理機能は提供されていません。

しかし、以前から、Key Vault を使って作業する場合には、新しいコードを書く必要がありました。チームのアプリケーションを実行している場所によっては、シークレットを簡単に更新できないことがあるようです。特に、従来のアプリケーションでこの現象が見られます。Azure Functions のトリガーも問題になります。プラットフォームによって管理されているからです。これらのシナリオはどちらも、この新しい機能で対処されています。

Key Vault からアプリケーション設定を取得する

Key Vault 参照という機能を使用することで、これまでのようにアプリ設定を使用しているかのようにアプリを実行させることができます。つまり、コードを変更する必要がありません。Key Vault 参照のドキュメントにその詳細が記載されていますが、この記事では、基本的な要点のみを取り上げます。

この機能を使用するには、ご使用のアプリのシステム割り当てマネージド ID が必要です。この記事の後半でユーザー割り当て済み ID について説明しますが、今のところ、これらのプレビューを分けておきます。

アプリケーションにシークレットの GET アクセス許可を付与する、Key Vault 上のアクセス ポリシーを構成する必要があります。アクセス ポリシーの構成については、こちらをご覧ください。

最後に、アプリケーション設定の値を次の形式の参照に設定します。

@Microsoft.KeyVault(SecretUri=secret_uri_with_version)

ここで、secret_uri_with_version は Key Vault のシークレットの完全 URI です。たとえば、https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931 のように設定します。

Key Vault からのアプリケーション設定の取得

たったこれだけです。コードを変更する必要はありません。

この初期プレビューでは、回転処理がまだ組み込まれていないため、シークレットのバージョンを明示的に設定する必要があります。できるだけ早く利用できるようにしたいと思います。

ユーザー割り当て済みマネージド ID (パブリック プレビュー)

既存のマネージド ID のサポートを、システム割り当てといいます。考え方は、特定のアプリケーションのプラットフォームによって ID が作成され、それがアプリケーションのライフサイクルに結びつけられるというものです。アプリケーションを削除すると、ID は直ちに Azure Active Directory から削除されます。

本日、ユーザー割り当て ID のプレビューを公開いたします。これは独自の Azure リソースとして作成され、特定のアプリケーションに割り当てられます。ユーザー割り当て ID を複数のアプリケーションに割り当てることも、アプリケーションに複数のユーザー割り当て ID を割り当てることもできます。

ユーザー割り当てマネージド ID

ユーザー割り当て ID の作成と使用の詳細については、「Azure portal を使用してユーザー割り当てマネージド ID を作成、一覧表示、削除したり、それにロールを割り当てたりする」をご覧ください。 ID を作成した後、その ID を指すようポインターを指定してアプリ構成を更新することで、ID をアプリに割り当てることができます。この詳細については、Microsoft のマネージド ID に関するドキュメントでご覧いただけます。ソブリン クラウドではこのプレビューがサポートされていないことにご注意ください。

クイック ヒント: ID を複数のリソースで使用することはできますが、過度に ID を共有したり、必要のないリソースにアクセス許可をリークしたりしないようにしてください。常に最低限の特権の原則を念頭に置き、既定ではアプリケーションのコンポーネントごとに個別の ID を作成するようにしてください。共有は、本当に必要な場合だけにしてください。

App Service on Linux/Web App for Containers のマネージド ID サポート (パブリック プレビュー)

マネージド ID のサポートを、App Service on Linux/Web App for Containers に拡張いたしました。これにより、Linux アプリでも、資格情報を管理することなく、ターンキーのサービス間認証が行えるようになりました。このプレビューには、システム割り当てとユーザー割り当ての両方のサポートが含まれています。この新しいサポートによって、Key Vault や Azure Resource Manager などのリソースへのアクセスを簡単に要求できるトークン サービスだけでなく、前述の Key Vault 参照の機能も Linux アプリで利用できるようになりました。

Linux アプリケーションを使い始めるにあたっては、ドキュメント「App Service と Azure Functions でマネージド ID を使用する方法」の構成手順に従ってください。

のマネージド ID

Azure Functions の ClaimsPrincipal バインディング データ

Azure Functions の初回プレビュー以来、App Service 認証/承認の使用による関数アプリへのアクセス制限は可能でした。今回のパブリック プレビューでは、関数コードからの着信 ID の利用がより簡単になっています。このデプロイはほぼ終了しており、週末までには Azure のすべての関数アプリで利用できるようになります。

.NET の場合、これは ASP.NET にあるような ClaimsPrincipal オブジェクトとして公開されています。ILogger の挿入と同様に、ClaimsPrincipal オブジェクトを関数シグネチャに追加すると、オブジェクトは自動的に挿入されます。

using System.Net;
using Microsoft.AspNetCore.Mvc;
using System.Security.Claims;

public static IActionResult Run(HttpRequest req, ClaimsPrincipal principal, ILogger log)
{
     // ...
     return new OkResult();
}

その他の言語は次回の更新で、コンテキスト オブジェクトを通じてアクセスできるようになります。それまでは、これは .NET のみのプレビューです。この機能の詳細については、HTTP トリガーのリファレンスを参照してください。

これによって、ID に依存する関数がなくなることは魅力です。この機能をトークン バインディングと組み合わせて使用することで、ビジネス ロジックにとって重要ではない多くのコードが取り除かれます。

CORS config の Access-Control-Allow-Credentials のサポート

最後になりましたが、Microsoft は、Access-Control-Allow-Credentials ヘッダーの設定を可能にする CORS 機能を簡単に更新できるようにしました。これは、API 呼び出しの一環としてクッキーやトークンを送信する必要がある場合に常に必要になります。この応答ヘッダーが設定されていないと、ブラウザーでデータが渡されません。

CORS 機能とこの新しい設定の詳細については、「チュートリアル: Azure App Service で CORS を使用して RESTful API をホストする」を参照してください。 CORS config を更新して "supportCredentials" を true に設定するだけでヘッダーを有効にすることができます。

また、コミュニティのプル要求も非常に役に立ちます。これを利用して、開発のためにローカルの Functions ホストで Access-Control-Allow-Credentials ヘッダーを有効にすることもできます。

まとめ

他の Microsoft のプレビューと同様、これらの機能をお試しいただき、ご意見ご感想をお聞かせください。

新しい機能についてご要望がある場合は、UserVoice (Functions または App Service のいずれか) からアイデアをお寄せください。Functions 固有の問題については、GitHub リポジトリに問題をご報告ください。Twitter @AzureFunctions からチームにご連絡いただくこともできます。

お客様からのご意見ご感想をお待ちしています。安全なアプリのご利用をお楽しみください。