Azure App Serviceと組み合わせて移行する認証、データベース、可用性、バッチ：.NET 5モダナイズ入門（5）

既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する連載。今回は、Azure App Serviceと組み合わせて移行する認証、データベース、可用性、バッチについて紹介します。

[鈴木友宏，NTTデータ先端技術株式会社]

　既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する本連載「.NET 5モダナイズ入門」。今回は、前回の続きとして、「Microsoft Azure」上で「Azure App Service」を中心に、その他の機能をどのように組み合わせてモダナイゼーションを進めていくかを考える際の、認証、データベース、可用性、バッチの移行を紹介します。

独自のアプリケーション独自の認証を使用していればIDaaSに乗り換えを検討する

　社内システムなどの小中規模のシステムにおいて、認証に関して最も重要なのは「可能な限り認証機能を独自実装しない」ことです。アプリケーション独自の認証機能で、例えば、「Azure Active Directory」（Azure AD）のような認証プラットフォームを独自実装するのは時間も費用もかかります。また、独自実装で既存のサービスと同様のセキュリティを保証するのも困難です。従って、古い社内システムなどでそのアプリケーション固有のIDとパスワードで認証しているような場合は、モダナイゼーション時にオンプレミスの認証プラットフォームや、Azure ADのようなIDaaS（Identity as a Service）の認証サービスへの乗り換えの検討をお勧めします。

　例えば、オンプレミス上の社内システムのASP.NETアプリケーションをAzureでモダナイゼーションする場合、既に、社内でActive Directoryによるシングルサインオンが導入されているなら、「Azure AD Connect」の導入を検討するとよいでしょう。

　なお、システムが大規模なECサイトなどの場合、要件上、独自認証がフィットしますが、そのようなシステムならそのECサイト自体が大規模なサービスの一部として存在しており、既に独自の高機能な認証プラットフォームが存在し、それを利用するようになっていると考えられます。

　Azure AD Connectの詳細は下記の参考情報をご覧ください。

• 参考情報：Azure AD Connectとは

　Azure AD Connectを導入すると、ユーザーはクラウドとオンプレミス両方のリソースに同じパスワードを使用してサインインできます。また、MFA（Multi-Factor Authentication：多要素認証）も利用できます。MFAでは例えば、PCの他にiPhoneやAndroidのスマートフォンの認証を必須にできます。

　なお、下記の参考情報にも記述があるように、MFAはアカウントの保護にとても効果的です。

• 参考情報：条件付きアクセス:すべてのユーザーに対してMFAを必須にする

　クラウドとオンプレミスのIDを統合する場合、さらにMFAを導入する場合でも、既存のアプリケーションの設計にもよりますが、たいていの場合、簡単な設定だけで複雑な実装はおおむね不要であり、軽微なコード修正でマイグレーション可能です。これらの認証をASP.NETアプリケーションで利用するためのSDKやサンプルコードも提供されています。

• 参考情報：Microsoft IDプラットフォームのコードサンプル（v2.0 エンドポイント）

　また、オンプレミスとクラウドのIDを統合する場合、IDの連携が確実に動作し、セキュリティを強化することが求められますが、ADFS（Active Directory Federation Services）サーバを監視するツールとして、「Azure AD Connect Health」が提供されています。

• 参考情報：Azure AD Connect Healthとは

データベースに関する留意事項

Azure SQL Databaseへの認証情報の取り扱い

　「Azure SQL Database」への接続文字列の格納には「Azure Key Vault」を使用します。この場合のVaultは「金庫」や「貴重品保管庫」というような意味です。つまり、シークレットやキー、証明書といった重要なリソースを安全に管理するためのサービスです。

　Azure Key Vaultを使うことで、アプリケーションコードや設定ファイル、Azure App Serviceの設定からでも認証情報を分離できるので、アプリケーションのセキュリティを強化できると同時に、その情報にアクセスするための環境依存のパラメーターも分離できるので、デプロイ時の取り扱いも簡単になります。

　具体的には、ポータルから設定できるAzure App Serviceのアプリケーション設定の設定値をAzure Key Vaultに格納したシークレットを参照するように設定した上で、アプリケーションコードからAzure App Serviceのアプリケーション設定の設定値を読むようにします。

参考情報：App ServiceとAzure FunctionsのKey Vault参照を使用する

データベース上の日時の扱い

　オンプレミスで運用されている比較的古いシステムでは、日時データに「DateTime」が使用されていることも多いでしょう。その場合、データベース上のタイムゾーンはJST（日本標準時）の場合がほとんどです。ですが、Azure SQL Databaseでは、タイムゾーンはUTC（協定世界時）固定で変更できません。

　なお「Azure SQL Database Managed Instance」の場合、リソース作成時にのみですがタイムゾーンを設定できますが規定値はUTCとなります。

　従って、オンプレミス上のJSTのタイムゾーンにおけるデータをAzureにそのままマイグレーションすると、時差の違いで面倒が発生してしまいます。解決策としては、AzureのデータベースサービスのタイムゾーンはUTCのままにして、.NETアプリケーション上では、DateTimeの代わりに「DateTimeOffset」を使用することを推奨します。

※注意：Azure SQL Databaseの「Managed Instance」は高価なので、お試しの際は料金にご注意ください。

クラウドにおける冗長性の考え方