Azureでの PaaS データベースのセキュリティ保護に関するベスト プラクティス

この記事では、Azure SQL DatabaseおよびAzure Synapse Analyticsのプラットフォーム・アズ・ア・サービス(PaaS)ウェブおよびモバイルアプリケーションのセキュリティ対策のベストプラクティスをまとめて紹介します。 MicrosoftはこれらのベストプラクティスをAzureおよびAzureの顧客との経験から導き出しました。

Azure SQL DatabaseおよびAzure Synapse Analytics は、インターネット ベースのアプリケーションにリレーショナル データベース サービスを提供します。 PaaS導入でAzure SQL DatabaseやAzure Synapse Analyticsを使用する場合、アプリケーションやデータを保護するのに役立つサービスをレビューしてください:

  • Microsoft Entra 認証 (SQL Server認証の代わりに)
  • Azure SQL ファイアウォール
  • Transparent Data Encryption(TDE)

一元化された ID リポジトリを使用する

Azure SQL Databaseは2種類の認証のいずれかを使用するように設定できます:

  • SQL 認証 では、ユーザー名とパスワードが使用されます。 データベース用のサーバーを作成する際に、ユーザー名とパスワードで server admin 認証を指定します。 これらの認証情報を使って、そのサーバー上の任意のデータベースに対してデータベース所有者として認証してください。

  • Microsoft Entra認証はMicrosoft Entra IDで管理されるアイデンティティを使用し、管理ドメインおよび統合ドメインをサポートします。 Microsoft Entra認証を使用するには、Microsoft Entra adminという別のサーバー管理者を作成し、Microsoft Entraユーザーやグループを管理する必要があります。 この管理者は、通常のサーバー管理者が実行できるすべての操作も実行できます。

Microsoft Entra認証は、Microsoft Entra ID内のIDを使ってAzure SQL DatabaseおよびAzure Synapse Analyticsに接続する仕組みです。 Microsoft Entra IDでは、SQL Server認証の代替手段が提供されるため、データベース サーバー間でのユーザー ID の急増を阻止できます。 Microsoft Entra 認証を使用すると、データベース ユーザーとその他の Microsoft サービスの ID を 1 か所で一元的に管理できます。 ID の一元管理では、1 か所でデータベース ユーザーを管理できるようになるため、アクセス許可の管理が容易になります。

SQL認証の代わりにMicrosoft Entra IDの利点

  • 1 か所でのパスワードのローテーションを許可します。
  • 外部のMicrosoft Entraグループを使ってデータベース権限を管理できます。
  • 統合されたWindows 認証や、Microsoft Entra IDでサポートされているその他の形式の認証を有効にすることで、パスワードを格納する必要がなくなります。
  • 包含データベース ユーザーを使用して、データベース レベルで ID を認証します。
  • SQL Database に接続するアプリケーションのトークンベースの認証をサポートします。
  • ドメイン同期を使用しないローカル Microsoft Entra IDに対して、Active Directory フェデレーション サービス (AD FS) (ADFS) またはネイティブ ユーザー/パスワード認証によるドメイン フェデレーションをサポートします。
  • SQL Server Management Studioからの接続をサポートし、Active Directoryユニバーサル認証(MFA)を含む複数認証を含みます。 MFA には、さまざまな簡単な検証オプションを使用した強力な認証が含まれています。 認証オプションは電話、テキストメッセージ、PIN付きのスマートカード、またはモバイルアプリの通知です。 詳細については、「 SQL Database と Azure Synapse Analytics を使用したUniversal 認証を参照してください。

Microsoft Entra認証に関する詳細は、以下をご覧ください:

注

Microsoft Entra IDが環境に適していることを確認するには、Microsoft Entra の機能と制限事項を参照してください。

IP アドレスに基づいてaccessを制限する

許容される IP アドレスの範囲を指定するファイアウォール規則を作成できます。 これらのルールはサーバーレベルとデータベースレベルの両方でターゲットにできます。 可能な限りデータベースレベルのファイアウォールルールを使用して、セキュリティを強化し、データベースをより持ち運びやすくしましょう。 管理者用や同じアクセス要件を持つ多くのデータベースに対して、個別に設定する時間を避けたい場合はサーバーレベルのファイアウォールルールを使いましょう。

SQL Database の既定のソース IP アドレス制限では、他のサブスクリプションやテナントを含め、任意のAzure アドレスからaccessできます。 IP アドレスのみがインスタンスにアクセスできるように制限できます。 SQL ファイアウォールと IP アドレスの制限がある場合でも、強力な認証が必要です。 この記事で前述した推奨事項を参照してください。

Azure SQLのファイアウォールおよびIP制限についての詳細は、以下をご覧ください:

データを保存時に暗号化する

Transparent Data Encryption (TDE) は既定で有効になっています。 TDE は、SQL Server、Azure SQL Database、Azure Synapse Analytics のデータ ファイルとログ ファイルを透過的に暗号化します。 TDE は、ファイルまたはそのバックアップへの直接accessの侵害から保護します。 この機能により、既存のアプリケーションを変更することなく静止状態でデータを暗号化できます。 TDEを有効にしておきましょう。 しかし、TDEは通常のアクセス経路を使う攻撃者を止めることはできない。 TDEは、さまざまな業界で定められた多くの法律、規制、ガイドラインの遵守を支援します。

Azure SQL は TDE のキー関連問題を管理します。 TDEオンプレミスと同様に、復旧可能性を確保し、データベース移動をサポートすることに特別な注意を払ってください。 より高度なシナリオでは、拡張可能な鍵管理を通じてAzure Key Vaultでキーを明示的に管理できます。 SQL ServerでのEKMを使用したTDEの有効化を参照してください。 この機能はまた、Azure Key Vault BYOK機能を通じて「自分で鍵を持ち込む(BYOK)」もサポートしています。

Azure SQLでは、Always Encrypted を介した列の暗号化が提供されます。 この機能により、認可されたアプリケーションのみが機密カラムにアクセスできます。 この種の暗号化により、暗号化された列のSQLクエリは等式に基づく値に制限されます。

選択的なデータにはアプリケーションレベルの暗号化を使いましょう。 正しい国や地域に保存された鍵でデータを暗号化することで、データ主権の懸念を軽減できることがあります。 この方法は、AES-256のような強力なアルゴリズムを用いると仮定して鍵なしではデータを復号できないため、偶発的なデータ転送でも問題を引き起こすことを防いでいます。

安全なシステムの設計、機密資産の暗号化、データベースサーバーの周りにファイアウォールを構築するなど、より多くの対策を講じることができます。

次のステップ

この記事では、PaaS Web アプリケーションとモバイル アプリケーションをセキュリティで保護するための SQL Database と Azure Synapse Analytics のセキュリティのベスト プラクティスのコレクションについて説明しました。 PaaS デプロイのセキュリティ保護の詳細については、次のリンク先をご覧ください。

  • Last updated on