既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する連載。今回は、Azure App Serviceと組み合わせて移行する認証、データベース、可用性、バッチについて紹介します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する本連載「.NET 5モダナイズ入門」。今回は、前回の続きとして、「Microsoft Azure」上で「Azure App Service」を中心に、その他の機能をどのように組み合わせてモダナイゼーションを進めていくかを考える際の、認証、データベース、可用性、バッチの移行を紹介します。
社内システムなどの小中規模のシステムにおいて、認証に関して最も重要なのは「可能な限り認証機能を独自実装しない」ことです。アプリケーション独自の認証機能で、例えば、「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を導入すると、ユーザーはクラウドとオンプレミス両方のリソースに同じパスワードを使用してサインインできます。また、MFA(Multi-Factor Authentication:多要素認証)も利用できます。MFAでは例えば、PCの他にiPhoneやAndroidのスマートフォンの認証を必須にできます。
なお、下記の参考情報にも記述があるように、MFAはアカウントの保護にとても効果的です。
クラウドとオンプレミスのIDを統合する場合、さらにMFAを導入する場合でも、既存のアプリケーションの設計にもよりますが、たいていの場合、簡単な設定だけで複雑な実装はおおむね不要であり、軽微なコード修正でマイグレーション可能です。これらの認証をASP.NETアプリケーションで利用するためのSDKやサンプルコードも提供されています。
また、オンプレミスとクラウドのIDを統合する場合、IDの連携が確実に動作し、セキュリティを強化することが求められますが、ADFS(Active Directory Federation Services)サーバを監視するツールとして、「Azure AD Connect Health」が提供されています。
「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」は高価なので、お試しの際は料金にご注意ください。
Copyright © ITmedia, Inc. All Rights Reserved.