チュートリアル:Azure SQL Database 内のデータベースをセキュリティで保護する

[アーティクル]
02/01/2024

適用対象:Azure SQL Database

このチュートリアルで学習する内容は次のとおりです。

サーバーレベルとデータベースレベルのファイアウォール規則を作成する
Microsoft Entra 管理者を構成する
SQL 認証、Microsoft Entra 認証、セキュリティで保護された接続文字列を使用して、ユーザーアクセスを管理する
Microsoft Defender for SQL、監査、データマスキング、暗号化などのセキュリティ機能を有効にする

Note

Microsoft Entra ID の、旧称は Azure Active Directory（Azure AD）です。

Azure SQL Database は、次のようにしてデータをセキュリティで保護します。

ファイアウォール規則を使用したアクセス制限
ID の入力を求める認証メカニズムの使用
ロールベースのメンバーシップとアクセス許可による認可の使用
セキュリティ機能の有効化

Note

Azure SQL Managed Instance は、Azure SQL Database Managed Instance と接続アーキテクチャに関するページに記載されているように、ネットワークセキュリティ規則とプライベートエンドポイントを使用してセキュリティで保護されます。

詳細については、Azure SQL Database のセキュリティの概要と機能に関する記事を参照してください。

ヒント

この無料の Learn モジュールでは、Azure SQL Database でデータベースをセキュリティで保護する方法がわかります。

前提条件

このチュートリアルを完了するには、前提条件として次のものが必要です。

SQL Server Management Studio
サーバーおよび単一データベース
- Azure portal、CLI、または PowerShell を使用して作成します

Azure サブスクリプションをお持ちでない場合は、開始する前に無料アカウントを作成してください。

このチュートリアルのすべての手順は、Azure portal にサインインして行います

ファイアウォール規則を作成する

SQL Database とデータベースは、Azure 内のファイアウォールによって保護されます。既定では、サーバーとデータベースに対する接続がすべて拒否されます。詳細については、サーバーレベルとデータベースレベルのファイアウォール規則に関するページを参照してください。

最も安全な構成は、 [Azure サービスへのアクセスを許可] を [オフ] にしておくことです。次に、Azure VM やクラウドサービスなど、接続する必要があるリソース用に予約済み IP (クラシックデプロイ) を作成し、その IP アドレスだけにファイアウォール経由のアクセスを許可します。 Resource Manager デプロイモデルを使用している場合は、リソースごとに専用のパブリック IP アドレスが必要です。

注意

SQL Database の通信は、ポート 1433 上で行われます。企業ネットワーク内から接続しようとしても、ポート 1433 での送信トラフィックがネットワークのファイアウォールで禁止されている場合があります。その場合、管理者によってポート 1433 が開放されない限り、サーバーに接続することはできません。

サーバーレベルのファイアウォール規則を設定する

サーバーレベルの IP ファイアウォール規則は、同じサーバー内のすべてのデータベースに適用されます。

サーバーレベルのファイアウォール規則を設定する手順は次のとおりです。

Azure portal で、左側のメニューから [SQL データベース] を選択し、 [SQL データベース] ページで目的のデータベースをクリックします。

Note

チュートリアルの後の手順で使用するために、完全修飾サーバー名 (yourserver.database.windows.net など) をコピーしておいてください。
[設定] で、 [ネットワーク] を選択します。 [パブリックアクセス] タブを選択し、[パブリックネットワークアクセス] で [選択したネットワーク] を選択して、[ファイアウォール規則] セクションを表示します。
ツールバーの [クライアント IP の追加] を選び、現在の IP アドレスを新しい IP ファイアウォール規則に追加します。 IP ファイアウォール規則は、単一の IP アドレスまたは IP アドレスの範囲に対して、ポート 1433 を開くことができます。
[OK] を選択してファイアウォールの設定を保存します。

これで、指定した IP アドレスまたは IP アドレスの範囲を使用して、サーバー内の任意のデータベースに接続できるようになりました。

データベースのファイアウォール規則の設定

データベースレベルのファイアウォール規則は、個々のデータベースのみに適用されます。サーバーのフェールオーバーの間、これらの規則はデータベースに保持されます。データベースレベルのファイアウォール規則は、サーバーレベルのファイアウォール規則を構成した後にのみ、Transact-SQL (T-SQL) ステートメントを使用して構成することができます。

データベースレベルのファイアウォール規則を設定するには:

SQL Server Management Studio などを使用して、データベースに接続します。
オブジェクトエクスプローラーでデータベースを右クリックし、 [新しいクエリ] を選択します。
クエリウィンドウで次のステートメントを追加し、その IP アドレスをお使いのパブリック IP アドレスに変更します。
```
EXECUTE sp_set_database_firewall_rule N'Example DB Rule','0.0.0.4','0.0.0.4';
```
ツールバー上で [実行] を選択して、ファイアウォール規則を作成します。

Note

sp_set_firewall_rule コマンドを使用して、SSMS でサーバーレベルのファイアウォール規則を作成することもできます。ただし、master データベースに接続する必要があります。

Microsoft Entra 管理者を作成する

適切な Microsoft Entra ID (旧称 Azure Active Directory) マネージドドメインを使用していることを確認します。ドメインを選択するには、Azure portal の右上隅を使用します。このプロセスでは、Microsoft Entra ID とデータベースまたはデータウェアハウスをホストする論理サーバーの両方に同じサブスクリプションが使用されていることを確認します。

Screenshot of the Azure portal showing the Directory + subscription filter page, where you would choose the directory.

Microsoft Entra 管理者を設定するには:

Azure portal の SQL server ページで、リソースメニューから [Microsoft Entra ID] を択し、[管理者の設定] を選択して [Microsoft Entra ID] ペインを開きます。

重要

このタスクを実行するには、"グローバル管理者" である必要があります。
[Microsoft Entra ID] ペインで、Microsoft Entra ユーザーまたはグループを検索して選択し、[選択] を選択します。 Microsoft Entra 組織のすべてのメンバーとグループが一覧表示され、グレーアウトしたエントリは Microsoft Entra 管理者としてサポートされていません。「Microsoft Entra の機能と制限事項」を参照してください。

重要

Azure ロールベースのアクセス制御 (Azure RBAC) はポータルにのみ適用され、SQL Server には反映されません。
[Microsoft Entra 管理者] ページの上部にある [保存] を選択します。

管理者を変更する処理には数分かかる場合があります。新しい管理者が [Microsoft Entra 管理者] フィールドに表示されます。

Note

Microsoft Entra 管理者を設定する場合、新しい管理者名 (ユーザーまたはグループ) がログインまたはユーザーとして "master" データベースに存在できません。存在していると、セットアップが失敗して変更がロールバックされ、その管理者名が既に存在していることが示されます。サーバーログインまたはユーザーは Microsoft Entra ID の一部ではないため、Microsoft Entra 認証を使用してこのユーザーに接続しようとしても失敗します。

Microsoft Entra ID の構成については、次を参照してください。

データベースアクセスを管理する

データベースにユーザーを追加するか、セキュリティで保護された接続文字列でのユーザーアクセスを許可することにより、データベースアクセスを管理します。接続文字列は、外部アプリケーションの場合に便利です。詳細については、ログインとユーザーアカウントの管理と Microsoft Entra 認証に関するページを参照してください。

ユーザーを追加するには、データベース認証の種類を選択します。

SQL 認証: ログインにユーザー名とパスワードを使用します。サーバー内の特定のデータベースのコンテキストでのみ有効です。
Microsoft Entra 認証: Microsoft Entra ID によって管理される ID を使用します。

SQL 認証

SQL 認証を使用するユーザーを追加する手順は次のとおりです。

SQL Server Management Studio などを使用して、データベースに接続します。
オブジェクトエクスプローラーでデータベースを右クリックし、 [新しいクエリ] を選択します。
クエリウィンドウで、次のコマンドを入力します。
```
CREATE USER ApplicationUser WITH PASSWORD = 'YourStrongPassword1';
```
ツールバーの [実行] を選択して、ユーザーを作成します。
既定では、ユーザーはデータベースに接続できますが、データを読み取ったり書き込んだりするアクセス許可は付与されていません。これらのアクセス許可を付与するには、新しいクエリウィンドウで次のコマンドを実行します。
```
ALTER ROLE db_datareader ADD MEMBER ApplicationUser;
ALTER ROLE db_datawriter ADD MEMBER ApplicationUser;
```

Note

新規ユーザーの作成などの管理者タスクを実行する必要がない場合は、データベースレベルで非管理者アカウントを作成します。

Microsoft Entra 認証

Azure SQL Database は Microsoft Entra サーバープリンシパル (ログイン) をサポートしていないため、Microsoft Entra アカウントで作成されたデータベースユーザーは包含データベースユーザーとして作成されます。包含データベースユーザーは、同じ名前の master ログインが存在する場合でも、データベース内のログインに関連付けられません。 AMicrosoft Entra ID は、個々のユーザーまたはグループに対応しています。詳細については、「包含データベースユーザー - データベースの可搬性を確保する」と、Microsoft Entra を使用して認証する方法に関する「Microsoft Entra チュートリアル」を参照してください。

Note

Azure portal を使用してデータベースユーザー (管理者を除く) を作成することはできません。 Microsoft Entra ロールは、SQL server、データベース、データウェアハウスには反映されません。これらは Azure リソースの管理のみに使用され、データベースのアクセス許可には適用されません。

たとえば、"SQL Server 共同作成者" ロールでは、データベースやデータウェアハウスに接続するためのアクセス権は付与されません。このアクセス許可は、T-SQL ステートメントを使用して、データベース内で付与する必要があります。

重要

コロン : やアンパサンド & などの特殊文字は、T-SQL の CREATE LOGIN ステートメントと CREATE USER ステートメントのユーザー名ではサポートされていません。

Microsoft Entra 認証を使用してユーザーを追加するには:

少なくとも ALTER ANY USER アクセス許可を持つ Microsoft Entra アカウントを使用して、Azure のサーバーに接続します。
オブジェクトエクスプローラーでデータベースを右クリックし、 [新しいクエリ] を選択します。
クエリウィンドウで、次のコマンドを入力し、<Azure_AD_principal_name> を Microsoft Entra ユーザーのプリンシパル名または Microsoft Entra グループの表示名に変更します。
```
CREATE USER [<Azure_AD_principal_name>] FROM EXTERNAL PROVIDER;
```

Note

Microsoft Entra ユーザーは、データベースメタデータ内でグループのタイプ E (EXTERNAL_USER) およびタイプ X (EXTERNAL_GROUPS) としてマークされます。詳細については、「sys.database_principals」を参照してください。

セキュリティで保護された接続文字列

クライアントアプリケーションと SQL データベースの間に暗号化された安全な接続を確立するには、接続文字列を次のように構成する必要があります。

暗号化接続を要求する
サーバー証明書を信頼しない

トランスポート層セキュリティ (TLS) を使用して接続が確立され、中間者攻撃のリスクが軽減されます。接続文字列はデータベースごとに利用可能で、ADO.NET、JDBC、ODBC、PHP などのクライアントドライバーをサポートするように事前構成されます。 TLS と接続の詳細については、TLS に関する考慮事項に関するセクションを参照してください。

セキュリティで保護された接続文字列をコピーする手順は次のとおりです。

Azure portal で、左側のメニューから [SQL データベース] を選択し、 [SQL データベース] ページで目的のデータベースをクリックします。
[概要] ページで、 [データベース接続文字列の表示] を選択します。
[ドライバー] タブを選択し、完全な接続文字列をコピーします。

セキュリティ機能の有効化

Azure SQL Database は、Azure portal を使用してアクセスされるセキュリティ機能を提供します。これらの機能は、データベースとサーバーの両方で利用可能です。ただし、データマスクは例外で、データベースのみで利用可能です。詳細については、Microsoft Defender for SQL、監査、動的データマスクキング、透過的なデータ暗号化に関するページを参照してください。

Microsoft Defender for SQL

Microsoft Defender for SQL 機能は、潜在的な脅威の発生を検出し、異常なアクティビティがあればセキュリティアラートを送信します。ユーザーは、監査機能を使用して、こうした疑わしいイベントを調査し、そのイベントがデータベース内のデータへのアクセス、侵害、悪用かどうかを判断できます。また、脆弱性評価を含めたセキュリティ概要や、データの検出と分類ツールも提供されます。

Note

脅威の一例として SQL インジェクションがあります。これは、攻撃者がアプリケーションの入力に悪意のある SQL を挿入するプロセスです。これにより、アプリケーションが知らないうちに悪意のある SQL を実行し、攻撃者がデータベース内のデータにアクセスして侵害や変更を行えるようになります。

Microsoft Defender for SQL を有効にする手順は次のとおりです。

Azure portal で、左側のメニューから [SQL データベース] を選択し、 [SQL データベース] ページで目的のデータベースをクリックします。
[概要] ページで、 [サーバー名] リンクを選択します。サーバーのページが開きます。
[SQL サーバー] ページで [セキュリティ] セクションを探し、 [Defender for Cloud] を選択します。
1. この機能を有効にするには、 [Microsoft Defender for SQL] で [オン] を選択します。脆弱性評価の結果を保存するためのストレージアカウントを選択します。次に、 [保存] を選択します。
  
  電子メールを構成して、セキュリティのアラート、ストレージの詳細、脅威検出の種類を受信することもできます。
目的のデータベースの [SQL データベース] ページに戻り、 [セキュリティ] セクションの [Defender for Cloud] を選択します。ここには、データベースのさまざまなセキュリティインジケーターがあります。

異常なアクティビティが検出されると、そのイベントの情報が電子メールで届きます。これには、アクティビティの性質、データベース、サーバー、イベントの発生時点、考えられる原因、推奨アクションが含まれていて、潜在的な脅威を調査してその影響を軽減することができます。このような電子メールを受信したら、 [Azure SQL Auditing Log](Azure SQL 監査ログ) リンクを選択して Azure portal を起動し、そのイベントの時点に関連する監査レコードを確認します。

Screenshot of a sample email from Azure, indicating a Potential Sql Injection Threat detection. A link in the body of the email to Azure SQL DB Audit Logs is highlighted.

監査

監査機能は、データベースイベントを追跡し、Azure Storage の監査ログ、Azure Monitor ログ、またはイベントハブのいずれかにイベントを書き込みます。監査により、規制に対するコンプライアンスの維持、データベースアクティビティの把握、セキュリティ侵害の可能性がある差異や異常に対する分析が容易になります。

監査を有効にする手順は次のとおりです。

Azure portal で、左側のメニューから [SQL データベース] を選択し、 [SQL データベース] ページで目的のデータベースをクリックします。
[セキュリティ] セクションで、 [監査] を選択します。
[監査] の設定で、次の値を設定します。
1. [監査] を [オン] に設定します。
2. [監査ログの保存先] として、次のいずれかを選択します。
  - [ストレージ] : イベントログが保存され、 .xel ファイルとしてダウンロードできる Azure ストレージアカウント。
    
    ヒント
    
    監査レポートのテンプレートを最大限活用するには、すべての監査済みデータベースに同じストレージアカウントを使用してください。
  - [Log Analytics] : クエリや詳細な分析のために、イベントが自動的に保存されます。
    
    Note
    
    分析、カスタムのアラートルール、Excel や Power BI のエクスポートなどの高度な機能をサポートするには、Log Analytics ワークスペースが必要です。ワークスペースがない場合は、クエリエディターのみを使用できます。
  - [イベントハブ] : イベントをルーティングして、他のアプリケーションで使用できるようにします。
3. [保存] を選択します。
これで、 [監査ログの表示] を選択してデータベースイベントのデータを表示できるようになりました。

重要

PowerShell や REST API を使用して監査イベントをさらにカスタマイズする方法については、SQL Database の監査に関するページを参照してください。

動的データマスク

データマスク機能は、データベース内の機密データを自動的に隠します。

データマスクを有効にする手順は次のとおりです。

Azure portal で、左側のメニューから [SQL データベース] を選択し、 [SQL データベース] ページで目的のデータベースをクリックします。
[セキュリティ] セクションで、 [動的データマスク] を選択します。
[動的データマスク] の設定で、 [マスクの追加] を選択してマスクの規則を追加します。使用可能なデータベーススキーマ、テーブル、選択元の列は自動的に設定されます。
[保存] を選択します。これで、選択した情報はプライバシー保護のためマスクされます。

透過的なデータ暗号化

暗号化機能では、保存データが自動的に暗号化されます。暗号化されたデータベースにアクセスするアプリケーションの変更は必要ありません。新しいデータベースの場合、暗号化は既定で有効になっています。 SSMS と Always Encrypted 機能を使用してデータを暗号化することもできます。

暗号化を有効化または確認する手順は次のとおりです。

Azure portal で、左側のメニューから [SQL データベース] を選択し、 [SQL データベース] ページで目的のデータベースをクリックします。
[セキュリティ] セクションで、 [透過的なデータ暗号化] を選択します。
必要に応じて、 [データの暗号化] を [オン] に設定します。 [保存] を選択します。

Note

暗号化の状態を確認するには、SSMS を使用してデータベースに接続し、sys.dm_database_encryption_keys ビューの encryption_state 列にクエリを実行します。状態 3 は、データベースが暗号化されていることを示します。

Note

テーブル名、オブジェクト名、インデックス名など、カスタマーコンテンツと見なされる一部の項目は、Microsoft によるサポートとトラブルシューティングのためにログファイルで送信される場合があります。

ヒント

.NET アプリケーションの開発を開始する準備はできましたか? この無料の Learn モジュールでは、単純なデータベースの作成など、Azure SQL Database に対してクエリを行う ASP.NET アプリケーションを開発および構成する方法を学習できます。

次のステップ

次のチュートリアルに進み、地理的分散の実装方法を学習してください。

チュートリアル:geo 分散型データベースを実装する (Azure SQL Database)

チュートリアル:Azure SQL Database 内のデータベースをセキュリティで保護する

前提条件