Tip
Microsoft Fabric Data Warehouse は、将来のアーキテクチャ、組み込みの AI、および新機能を備えた、Data Lake 基盤上のエンタープライズ 規模のリレーショナル ウェアハウスです。 データ ウェアハウスを初めて使用する場合は、Fabric Data Warehouseから始めます。 既存の dedicated SQL プール ワークロードは、Fabric にアップグレードして、データ サイエンス、リアルタイム分析、レポートの新機能にアクセスできます。
- Fabric無料試用版を開始します。
- Fabric Data Warehouseの移行アシスタント。
この記事では、専用 SQL プール (旧称 SQL DW) のセキュリティ保護の基本について説明します。 特に、この記事では、専用 SQL プール (旧称 SQL DW) を使用して、アクセスの制限、データの保護、およびアクティビティの監視を行うリソースについて説明します。
接続のセキュリティ
接続セキュリティとは、ファイアウォール規則と接続暗号化を使用してデータベースへの接続を制限し、セキュリティで保護する方法を指します。
ファイアウォール規則は、明示的に承認されていない IP アドレスからの接続試行を拒否するために、 論理 SQL サーバー とそのデータベースの両方で使用されます。 アプリケーションまたはクライアント コンピューターのパブリック IP アドレスからの接続を許可するには、まず、Azure portal、REST API、または PowerShell を使用してサーバー レベルのファイアウォール規則を作成する必要があります。
ベスト プラクティスとして、サーバー レベルのファイアウォールで許可される IP アドレスの範囲を可能な限り制限する必要があります。 ローカル コンピューターから専用 SQL プール (以前の SQL DW) にアクセスするには、ネットワーク上のファイアウォールとローカル コンピューターで TCP ポート 1433 での送信通信が許可されていることを確認します。
専用 SQL プール (以前の SQL DW) では、サーバー レベルの IP ファイアウォール規則が使用されます。 データベース レベルの IP ファイアウォール規則はサポートされていません。 詳細については、Azure SQL Database のファイアウォール規則に関するページを参照してください。
専用 SQL プール (以前の SQL DW) への接続は、既定で暗号化されます。 暗号化を無効にするように接続設定を変更することは無視されます。
認証
認証とは、データベースに接続するときに ID を証明する方法を指します。 専用 SQL プール (旧称 SQL DW) では現在、ユーザー名とパスワードと Microsoft Entra ID を使用した SQL Server 認証がサポートされています。
データベースのサーバーを作成するときに、ユーザー名とパスワードを使用して "サーバー管理者" ログインを指定しました。 これらの資格情報を使用すると、そのサーバー上の任意のデータベースに対してデータベース所有者として認証するか、SQL Server 認証を使用して "dbo" を認証できます。
ただし、ベスト プラクティスとして、組織のユーザーは別のアカウントを使用して認証する必要があります。 これにより、アプリケーションに付与されるアクセス許可を制限し、アプリケーション コードが SQL インジェクション攻撃に対して脆弱な場合の悪意のあるアクティビティのリスクを軽減できます。
SQL Server 認証ユーザーを作成するには、サーバー管理者ログインを使用してサーバー上の マスター データベースに接続し、新しいサーバー ログインを作成します。 また、master データベースにユーザーを作成することをお勧めします。 マスターでユーザーを作成すると、ユーザーはデータベース名を指定せずに SSMS などのツールを使用してログインできます。 また、オブジェクト エクスプローラーを使用して、サーバー上のすべてのデータベースを表示することもできます。
-- Connect to master database and create a login
CREATE LOGIN ApplicationLogin WITH PASSWORD = 'Str0ng_password';
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;
次に、サーバー管理者ログインを使用して 専用 SQL プール (旧称 SQL DW) に 接続し、作成したサーバー ログインに基づいてデータベース ユーザーを作成します。
-- Connect to the database and create a database user
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;
ログインの作成や新しいデータベースの作成などの追加操作を実行する権限をユーザーに付与するには、マスター データベースの Loginmanager ロールと dbmanager ロールにユーザーを割り当てます。
これらの追加ロールと SQL Database への認証の詳細については、「 Azure SQL Database でのデータベースとログインの管理」を参照してください。 Microsoft Entra ID を使用した接続の詳細については、「 Microsoft Entra 認証を使用した接続」を参照してください。
権限
承認とは、認証されて接続された後にデータベース内で実行できることを指します。 承認特権は、ロールのメンバーシップとアクセス許可によって決まります。 ベスト プラクティスとして、必要最小限の特権をユーザーに付与する必要があります。 ロールを管理するには、次のストアド プロシージャを使用します。
EXEC sp_addrolemember 'db_datareader', 'ApplicationUser'; -- allows ApplicationUser to read data
EXEC sp_addrolemember 'db_datawriter', 'ApplicationUser'; -- allows ApplicationUser to write data
接続先のサーバー管理者アカウントは、データベース内で何かを行う権限を持つdb_ownerのメンバーです。 スキーマのアップグレードやその他の管理操作をデプロイするために、このアカウントを保存します。 アプリケーションが必要とする最小限の特権でアプリケーションからデータベースに接続するには、より制限されたアクセス許可を持つ "ApplicationUser" アカウントを使用します。
データベース内でユーザーが実行できる操作をさらに制限する方法があります。
- 詳細 なアクセス許可 を使用すると、データベース内の個々の列、テーブル、ビュー、スキーマ、プロシージャ、およびその他のオブジェクトに対して実行できる操作を制御できます。 細かいアクセス許可を使用して、最も制御し、必要な最小限のアクセス許可を付与します。
- db_datareaderおよびdb_datawriter以外のデータベース ロールを使用して、より強力なアプリケーション ユーザー アカウントまたはより強力でない管理アカウントを作成できます。 組み込みの固定データベース ロールを使用すると、アクセス許可を簡単に付与できますが、必要以上に多くのアクセス許可が付与される可能性があります。
- ストアド プロシージャを 使用して、データベースに対して実行できるアクションを制限できます。
次の例では、ユーザー定義スキーマへの読み取りアクセスを許可します。
--CREATE SCHEMA Test
GRANT SELECT ON SCHEMA::Test to ApplicationUser
Azure portal からのデータベースとサーバーの管理、または Azure Resource Manager API の使用は、ポータル ユーザー アカウントのロールの割り当てによって制御されます。 詳細については、Azure portal を使用して Azure ロールを割り当てる方法に関するページを参照してください。
行レベルのセキュリティ
Row-Level セキュリティを使用すると、クエリを実行するユーザーの特性 (グループ メンバーシップや実行コンテキストなど) に基づいて、データベース テーブル内の行へのアクセスを制御できます。 Row-Level Security を使用して、カスタムラベルベースのセキュリティ概念を実装します。 詳細については、「行レベルのセキュリティ」を参照してください。
暗号化
Transparent Data Encryption (TDE) は、保存データを暗号化および復号化することで、悪意のあるアクティビティの脅威から保護するのに役立ちます。 データベースを暗号化すると、関連付けられているバックアップとトランザクション ログ ファイルが暗号化され、アプリケーションに変更を加える必要はありません。 TDE は、データベース暗号化キーと呼ばれる対称キーを使用してデータベース全体のストレージを暗号化します。
SQL Database では、データベース暗号化キーは組み込みのサーバー証明書によって保護されます。 組み込みのサーバー証明書は、サーバーごとに一意です。 これらの証明書は、少なくとも 90 日ごとに自動的にローテーションされます。 使用される暗号化アルゴリズムは AES-256 です。 TDE の一般的な説明については、「 Transparent Data Encryption」を参照してください。
Azure portal または T-SQL を使用してデータベースを暗号化できます。
カスタマー マネージド キーを使用した透過的なデータ暗号化 (保存時の暗号化)
暗号化鍵の制御を強化したい場合は、Azure Synapse AnalyticsのTransparent Data Encryptionは顧客管理鍵(CMK)をサポートしています。 この CMK は論理サーバーに関連付けられ、そのサーバー内のすべてのデータベースのデータベース暗号化キーをラップします。 CMK を管理することで、キーのローテーション、失効、監査を制御できます。これは、多くの場合、コンプライアンスまたは厳格なセキュリティ ポリシーに必要です。
トランスポート層セキュリティ (転送中の暗号化)
Azure Synapse Analyticsは、トランスポートレイヤーセキュリティ(TLS)で移動中のデータを暗号化することで顧客データを保護します。 Azure Synapse Analyticsは常にTLS暗号化接続を強制し、クライアントとサーバー間の転送時にすべてのデータが暗号化されていることを保証します。
具体的には、Azure Synapse Analytics では、構成フラグ ForceEncryption を Yes に設定します。 クライアントとドライバーはこのサービスに接続するために暗号化された接続をサポートしなければなりません。 接続できる TDS プロトコルの最小バージョンは TDS 7.1 です。
ベスト プラクティスとして、 TDS 8.0 対応 SQL ドライバーがある場合は、 厳密な接続暗号化を使用します。
ドライバーが TDS 8.0 をサポートしていない場合は、必須の暗号化を使用し、サーバー証明書を信頼しないでください。 たとえば、ADO.NET ドライバーを使用する場合は、接続文字列で Encrypt=True と TrustServerCertificate=False を使用してこれを行います。 Azure portal から取得する接続文字列は、既にこれらの値で構成されています。
運用環境でパラメーター TrustServerCertificate を True に設定しないでください。
TrustServerCertificate=True は許容されすぎ、中間者攻撃から保護されません。 代わりに、クライアントでサーバー証明書に別のドメイン名が必要な場合は、 HostNameInCertificate パラメーターを使用して検証用の正しいドメイン名を指定します。
Important
Microsoft 以外のドライバーの中には、既定で TLS を使用しない場合や、以前のバージョンの TLS (1.2 より前) を使用して機能する場合があります。 この場合も、サーバーはデータベースに接続できます。 ただし、特に機密データを保存する場合、ドライバーやアプリケーションを接続させることのセキュリティリスクを評価してください。
次のステップ
さまざまなプロトコルを使用してウェアハウスに接続する方法の詳細と例については、 専用 SQL プール (旧称 SQL DW) への接続に関するページを参照してください。