セキュリティ機能とタスク

  • 10 分

SQL Server と Azure SQL サービスは、特にエンタープライズ クラスであるという点で、セキュリティに対する重要性を認識されています。 このユニットでは、ネットワーク セキュリティとアクセス管理に関連するさまざまなセキュリティ機能について学習します。 その後のユニットでは、これらの機能のいくつかをハンズオン形式で体験します。

Diagram of enterprise-class security.

ネットワーク セキュリティ

セキュリティの第 1 層にはネットワークが関係します。 Azure SQL Database と Azure SQL Managed Instance ではネットワーク機能とタスクが異なります。 Azure SQL Managed Instance のネットワーク機能の詳細については、「Azure SQL Managed Instance の接続アーキテクチャ」を参照してください。

Azure SQL Database のネットワーク セキュリティ

Azure SQL Database 用のネットワークをセキュリティで保護する場合、主に次の 4 つの選択肢があります。

  • Azure サービスへのアクセス許可
  • ファイアウォール規則を使用する
  • 仮想ネットワーク規則を使用する
  • Azure Private Link を使用する

これらの主な選択肢に加えて、すべてのパブリック アクセスをブロックでき (Azure Private Link でのみ)、トランスポート層セキュリティ (TLS) の最小バージョンを強制するオプションもあります。 最も安全性の低い方法ですが、最も構成が簡単なのは Azure サービスへのアクセスを許可することです。 最も安全な方法は、プライベート リンクを使用することです。 次のセクションでは、各オプションの機能と、各オプションの構成および保守方法について説明します。

Azure サービスへのアクセス許可

Azure SQL Database のデプロイ中に、[Azure のサービスとリソースにこのサーバーへのアクセスを許可する] を [はい] に設定するオプションがあります。 このオプションを選択した場合、任意のリージョンまたはサブスクリプションのリソースがご自分のリソースにアクセスできます。 このオプションを使用すると、Azure SQL Database を稼働させ、Azure Virtual Machines、Azure App Service、または Azure Cloud Shell などのその他のサービスに接続させるのが容易になります。これは、Azure を経由するすべての接続を許可しているためです。

Diagram of allowing access to Azure services.

ただし、Azure サービスへのアクセスを許可しても、Azure の外部 (たとえば、オンプレミス環境) がアクセスすることは許可されません。

最も安全な構成では、[Azure のサービスとリソースにこのサーバーへのアクセスを許可する] を [いいえ] に設定します。これにより、次のセクションで説明するさまざまなオプションで明示的に追加したもの以外のすべての接続とネットワークがブロックされます。

ファイアウォール規則

次の選択肢は、ファイアウォール規則を適用することです。 結果は、[Azure のサービスとリソースにこのサーバーへのアクセスを許可する] の結果と似ていますが、サービス (次の図では仮想マシン (VM)) ごとに、その接続を許可する固有のファイアウォール規則を追加する必要がある点が異なります。 また、オンプレミス環境のマシンとアプリケーションに対して規則を追加できるため、ファイアウォール規則によってオンプレミス環境の Azure SQL Database リソースへの接続も有効にできます。

Diagram of firewall rules.

Azure で接続を取得するには、Azure サービスへのアクセスを許可し、オンプレミスの接続に対してのみファイアウォール規則を追加することもできます。 既に説明したように、[Azure のサービスとリソースにこのサーバーへのアクセスを許可する] は、すべての Azure トラフィックが許可されるため、それほど安全ではありません。 ファイアウォール規則のみを使用することをお勧めします。

ファイアウォール規則が構成された前の例を見てみましょう。 SQL Server Management Studio (SSMS) のように Transact-SQL (T-SQL) をサポートするツールを使用して、仮想ネットワーク SQLDBVNET-EUS 内の Azure VM から次のクエリを実行できます。

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

結果は 174.17.218.16 になります。 これは Azure VM のパブリック IP アドレスです。 ファイアウォール規則を使用している場合でも、実行されているすべての接続がパブリックになります。

仮想ネットワーク規則

ファイアウォール規則のみを使用するとすれば、設定が複雑になる場合があります。 ファイアウォール規則のみを使用するということは、すべての接続 (動的 IP アドレスが使用される可能性もあります) の IP アドレスの範囲を指定する必要があることを意味します。 より簡単な代替手段として、仮想ネットワーク規則を使用して、データにアクセスする必要がある VM またはその他のサービスを含む特定のネットワークからアクセスを確立し、管理する方法があります。

仮想ネットワーク規則を使用して仮想ネットワークからのアクセスを構成すると、その仮想ネットワーク内のすべてのリソースが Azure SQL Database 論理サーバーにアクセスできるようになります。 これにより、データへのアクセスが必要なすべての静的および動的 IP アドレスへのアクセスを構成するという課題が軽減されます。 仮想ネットワーク規則を使用すると、1 つまたは複数の仮想ネットワークを指定し、その中のすべてのリソースを含めることができます。 また、仮想ネットワーク テクノロジの適用を開始して、Azure とオンプレミスの両方のリージョン間でネットワークを接続することもできます。

Diagram of virtual network rules.

この例では、前のセクションと同様に、仮想ネットワーク SQLDBVNET-EUS 内の Azure VM から同じクエリを実行できます。

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

結果は Azure VM のプライベート IP アドレス 10.0.0.2 になります。 この結果により、リソースが仮想ネットワークを介して接続されるようになったため、Azure SQL Database 論理サーバーへのプライベート接続の作成に一歩近づきました。

接続を分析するためのもう 1 つの一般的な方法は、ドメイン ネーム システム (DNS) 階層を調べることです。 同じ Azure VM のコマンド プロンプトで次のコマンドを実行します。

nslookup aw-server.database.windows.net

このコマンドを使用すると、DNS インフラストラクチャに関連する詳細情報を取得できます。 結果はおおよそ次のようになります。

Server: Unknown
Address: 168.63.129.16

Non-authoritative answer:
Name:   cr2.eastus1-a.control.database.windows.net
Address:    174.17.218.16
Aliases:    aw-server.database.windows.net
            dataslice2.eastus.database.windows.net

権限のない応答の下に、次のような注目すべき重要な点がいくつかあります。

  • [名前]: cr2 で始まるエンドポイントは、パブリック DNS 階層の一部です。 階層に入り込みすぎずに、cr2 は "制御リング 2" で、その下に複数のデータ "スライス" があるとします。
  • [アドレス]: ここで返される IP アドレスは、Azure VM のパブリック IP アドレスと一致している必要があります。 SSMS の最終ホップのようなツールが VM のプライベート IP アドレスを介している場合でも、VM のパブリック IP アドレスはある程度の接続に使用されたままになります。
  • [エイリアス]: エイリアスは、DNS 階層内のさまざまなポイントです。この例では、特定のデータ "スライス" と接続先のエンドポイントです。

Note

前の出力ブロックで、 アドレス:168.63.129.16 は、Azure プラットフォーム リソースへの通信チャネルを円滑化するために使用される仮想パブリック IP アドレスです。 これはすべての地域とすべての国内クラウドに適用され、変更されることはありません。

SSMS 経由の接続は Azure VM のプライベート IP アドレスを介して行われますが、それでも究極的にはパブリック エンドポイントを介して接続しています。

パブリック エンドポイントで Azure SQL Database のデータベースを使用して、最も安全なネットワークを構成する方法について確認しました。 この Azure SQL Database のデータベースをセキュリティで保護する方法は、何年も使用されています。 しかしながら、2019 年、Azure のプライベート リンクの概念への移行が開始されました。これは、Azure SQL Managed Instance をデプロイする方法にさらに似ています。 Azure Private Link では、プライベート エンドポイントを使用して、SQL Database のデータベースや他のいくつかのサービスとしてのプラットフォーム (PaaS) オファリングに接続できます。 これは、特定の仮想ネットワーク内にプライベート IP アドレスがあることを意味します。

Diagram of a private endpoint connection.

前の例では、一般的なネットワーク インフラストラクチャは変更されておらず、引き続き仮想ネットワーク規則から仮想ネットワーク接続戦略を適用することができます。 ただし、仮想ネットワーク規則を作成する必要はありません。 データベース サーバーに接続する必要があるリソースは、エンドポイントが置かれている仮想ネットワークにアクセスできる必要があります。 この例では、エンドポイントは SQLDBVNet-EUS です。 プライベート エンドポイントを経由する接続のみがアクセスを許可され、他のすべての接続 (たとえば、インターネットからの接続) は拒否されます。

この例を続行すると、仮想ネットワーク SQLDBVNet-EUS の Azure VM で、次の T-SQL コマンドをもう一度実行できます。

SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;

結果は 10.0.0.2 になります。この例では、Azure VM のプライベート IP アドレスです。 仮想ネットワークからのアクセスを追加することにより、VM から Azure SQL Database への接続が、VM のプライベート IP アドレス経由で行われているように見えます。 これは、仮想ネットワーク規則の場合と同じ結果です。

ただし、次のコマンドを使用すると、コマンド プロンプトを使用して DNS 階層を確認することもできます。

nslookup aw-server.database.windows.net

上記のコマンドを使用すると、構成されたプライベート エンドポイントとは結果が若干異なります。

Server: Unknown
Address: 168.63.129.16

Non-authoritative answer:
Name:   aw-server.privatelink.database.windows.net
Address:    10.0.0.5
Aliases:    aw-server.database.windows.net

権限のない応答の下に、次のような注目すべき重要な点がいくつかあります。

  • [名前]: パブリック DNS 階層を参照しなくなったことに注意してください。Private Link DNS のみを参照しています。 これは、データベース サーバーに関する情報が少なくなったことを意味します。
  • [アドレス]: 仮想ネットワーク規則では、返されるアドレスは VM のパブリック IP アドレスですが、ここでは Private Link 階層内の 1 つ以上の プライベート IP アドレスである必要があります (1 つは Azure SQL Database のプライベート エンドポイントです)。
  • [エイリアス]: Name フィールドと同様に、DNS 階層に関連するものはありません。ただし、サーバー名 (aw-server.database.windows.net など) に接続することはできます。

プライベート エンドポイントに接続している場合に、"なぜ同じサーバー名を引き続き使用しているのか" と疑問に思うかもしれません。Azure SQL Database への接続で Private Link の接続方法のみを使用する (つまり、ファイアウォール規則や仮想ネットワーク規則を適用しない) 場合、バックエンドでは情報は次のように処理されます。

  • aw-server.database.windows.net
    • サービスによって、aw-server.privatelink.database.net に解決されます
      • サービスによって、10.0.0.5 (プライベート エンドポイントの IP アドレス) に解決されます

また、aw-server.database.windows.net 以外を使用した直接接続はサービスによってブロックされます。

アクセス管理

ネットワーク アクセスを解決した後、次に考慮すべきレイヤーはアクセス管理です。

ロールベースのアクセス制御

Azure SQL Database に対する Azure のすべての種類の操作は、ロールベースのアクセス制御 (RBAC) によって制御されます。 現在、RBAC は Azure SQL セキュリティから分離されていますが、サブスクリプション、リソース グループ、リソースなどのスコープを使用する、SQL Database のデータベースの外部にあるセキュリティ権限と考えることができます。 この権限は、Azure portal、Azure CLI、および Azure PowerShell の操作に適用されます。 RBAC を使用すると、デプロイ、管理、使用の間で職務を分離することができます。

所有者や共同作成者などの高度な RBAC ロールの必要性を軽減するには、組み込みのロールが利用できます。 実際には、これらのロールを使用して、特定の個人が Azure SQL リソースをデプロイする (またはセキュリティ ポリシーを管理する) 一方で、他のユーザーに実際のアクセスを許可したり、データベースを管理したりすることができます。 たとえば、SQL Server の共同作成者はサーバーをデプロイしてユーザーをサーバーとデータベースの管理者に割り当てることができます。 Azure SQL Database の組み込みロールには次のものがあります。

  • SQL DB 共同作成者: データベースを作成および管理できますが、データベースにアクセスすることはできません (たとえば、接続してデータを読み取ることはできません)。
  • SQL セキュリティ管理者: データベースとインスタンス (監査など) のセキュリティ ポリシーを管理できますが、それらにアクセスすることはできません。
  • SQL Server 共同作成者: サーバーとデータベースを管理できますが、それらにアクセスすることはできません。

認証

Azure SQL Database の論理サーバーのデプロイ中に、次の認証方法を指定できます。

  • Microsoft Entra 認証のみを使う
  • SQL と Microsoft Entra の両方の認証を使う
  • SQL 認証を使用する

デプロイ中にサーバー管理者を設定する必要があります。 Azure SQL Database 内のデータベースの場合、サーバー管理者は Azure SQL Database 論理サーバーのサーバーレベル プリンシパルです。

Windows 認証が必要なワークロードを移行する場合、または組織が Microsoft Entra ID を使っている場合は、Microsoft Entra ID を使用できます。 ポータルまたはコマンドライン ツールを使って Microsoft Entra サーバー管理者を割り当てることができます。

Microsoft Entra 専用認証は、新しいサーバーを構成するときの既定のオプションです。 Microsoft Entra サーバー プリンシパルを許可するサーバー ログインが導入されました。これは、SQL Database の仮想 master データベース内のログインです。 Microsoft Entra ログインは、Microsoft Entra の "ユーザー、グループ、サービス プリンシパル" から作成できます。 Microsoft Entra 専用認証を使うと、SQL 認証ログインを作成でき、かつ既存のログインも残ります。 ただし、論理サーバーに接続できるのは、Microsoft Entra 認証のログインとユーザーのみです。 Microsoft Entra 専用認証の詳細については、「Azure SQL を使用した Microsoft Entra 専用認証」を参照してください。

Screenshot of setting the Microsoft Entra administrator.

組織が Microsoft Entra インスタンスをどのように構成しているかに応じて、次の 3 つの方法のいずれかを使ってそれに接続することができます (たとえば、SSMS で)。

  • Microsoft Entra ID - 統合:フェデレーション ドメインの Microsoft Entra 資格情報を使って Windows にサインインしている場合に使用できる非対話型の手法です。

  • Microsoft Entra ID - パスワード:Microsoft Entra ID マネージド ドメインを使って Microsoft Entra のプリンシパル名を使って接続できる非対話型の手法です。 ドキュメントより抜粋:

    これは、ネイティブまたはフェデレーション Microsoft Entra ユーザーに適用できます。 ネイティブ ユーザーは Microsoft Entra ID で明示的に作成され、ユーザー名とパスワードを使って認証されます。一方、フェデレーション ユーザーは、ドメインが Microsoft Entra ID とフェデレーションされている Windows ユーザーです。 後者の方法 (ユーザー名とパスワードを使用) は、ユーザーが Windows の資格情報を使いたくても、ローカル コンピューターがドメインに参加していない場合 (たとえば、リモート アクセスを使う場合) に使用できます。 この場合、Windows ユーザーはドメイン アカウントとパスワードを示すことができ、フェデレーション資格情報を使用して SQL Database または Azure Synapse Analytics (以前の SQL DW) に対して認証できます。

  • Microsoft Entra ID - 多要素認証 (MFA) を使ったユニバーサル:Microsoft Entra 多要素認証を使ったシングル サインイン プロセスに対する組織の需要に応えながら、データへのアクセスを保護する対話型の手法です。

Azure SQL Database では、いくつかの微妙な違いがあります。 仮想 master データベース、データベース ユーザー、さらには Microsoft Entra アカウントの包含データベース ユーザーに存在するログインを設定できます (推奨)。 Azure SQL Database のサーバー管理者には基本的に sysadmin 権限がありますが、サーバーまたはデータベース レベルのロールを使用して、より制限された管理者を作成できます。 仮想 master データベースにのみ存在する SQL Database には、次の 2 つのデータベース レベル ロールを使用できます。

  • loginmanager: データベースレベルのロールで、メンバーはデータベース サーバーのログインを作成することができます
  • dbmanager: データベース レベルのロールで、メンバーはデータベース サーバーのデータベースの作成および削除を行えます

Azure SQL Database のサーバーレベルのロールの一覧を次に示します。

  • ##MS_DatabaseConnector##
  • ##MS_DatabaseManager##
  • ##MS_DefinitionReader##
  • ##MS_LoginManager##
  • ##MS_SecurityDefinitionReader##
  • ##MS_ServerStateReader##
  • ##MS_ServerStateManager##

最後に、認証と承認を設定および構成するときには、次の 4 つのガイドラインに従ってください。

  • サーバー管理者と共にデプロイする
  • 必要に応じて他の管理者を作成する
  • 管理者はユーザーを作成できる
  • SQL Server の場合と同じようにアクセス権を付与する

その他の機能

ネットワークと認証の機能のいくつかを実践した後、モジュールの後半では、データの保護、監視、ログ記録、監査のためのその他の機能 (および関連するタスク) を確認します。

知識チェック

1.

Azure SQL Database 用のネットワークを保護するために推奨される、最も安全な方法は何ですか。

2.

Azure VM のパブリック IP アドレスが 174.17.218.16 で、Azure VM のプライベート IP アドレスが 10.0.0.2 であるユニットの例を考えてみましょう。 仮想ネットワーク規則を使用して Azure SQL Database へのネットワーク アクセスを構成する場合、SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID; から何が返されますか。