データベース アクセスの制御と許可

ファイアウォール規則の構成後、ユーザーは、いずれかの管理者アカウント、データベース所有者、またはデータベースのデータベース ユーザーとして SQL データベースに接続できます。

注意

このトピックは Azure SQL サーバーのほか、その Azure SQL サーバーに作成される SQL Database と SQL Data Warehouse の両方に当てはまります。 わかりやすいように、SQL Database という言葉で SQL Database と SQL Data Warehouse の両方を言い表します。

ヒント

チュートリアルについては、「Azure SQL データベースのセキュリティ保護」を参照してください。

制限なしの管理者アカウント

管理者の機能を果たす 2 つの管理者アカウント (サーバー管理者Active Directory 管理者) があります。 SQL サーバー用にこれらの管理者アカウントを特定するには、Azure Portal を開き、SQL サーバーのプロパティに移動します。

SQL サーバーの管理者

  • サーバー管理者
    Azure SQL サーバーを作成する際に、サーバー管理者ログインを指定する必要があります。 このアカウントは SQL サーバーによって master データベースへのログインとして作成されます。 このアカウントは、SQL Server 認証 (ユーザー名とパスワード) を使用して接続します。 これらのアカウントのうち、存在できるのは 1 つだけです。
  • Azure Active Directory の管理者
    1 つの Azure Active Directory アカウント (個人またはセキュリティ グループ アカウント) も、管理者として構成できます。 Azure AD 管理者の構成は任意ですが、SQL Database への接続に Azure AD アカウントを使用する場合は、Azure AD 管理者を構成する必要があります。 Azure Active Directory アクセスの構成の詳細については、「Azure Active Directory 認証を使用して SQL Database または SQL Data Warehouse に接続する」と「SSMS support for Azure AD MFA with SQL Database and SQL Data Warehouse」 (SQL Database と SQL Data Warehouse での Azure AD MFA のための SSMS のサポート) をご覧ください。

サーバー管理者アカウントと Azure AD 管理者アカウントには次の特性があります。

  • これらは、サーバー上の任意の SQL Database に自動的に接続できる唯一のアカウントです (それ以外のアカウントでユーザー データベースに接続するには、そのデータベースの所有者であるか、そのユーザー データベースのユーザー アカウントを持っている必要があります)。
  • これらのアカウントは、dbo ユーザーとしてユーザー データベースにアクセスし、ユーザー データベースに対するすべてのアクセス許可を持ちます (ユーザー データベースの所有者も、dbo ユーザーとしてデータベースにアクセスします)。
  • これらのアカウントは dbo ユーザーとして master データベースにアクセスせず、master に対するアクセス許可は限られています。
  • これらのアカウントは、SQL データベースでは使用できない標準の SQL Server sysadmin 固定サーバー ロールのメンバーではありません。
  • これらのアカウントは、データベース、ログイン、master のユーザー、サーバーレベルのファイアウォール規則を作成、変更、削除できます。
  • これらのアカウントは、dbmanager および loginmanager ロールのメンバーを追加および削除できます。
  • これらのアカウントは sys.sql_logins システム テーブルを表示できます。

ファイアウォールの構成

個々の IP アドレスまたは範囲に対してサーバーレベルのファイアウォールを構成すると、SQL サーバー管理者Azure Active Directory 管理者は、master データベースとすべてのユーザー データベースに接続できます。 初期状態のサーバー レベルのファイアウォールは、PowerShell または REST API を使用して、Azure Portal で構成できます。 接続が確立されると、Transact-SQL を使用して、サーバー レベルのファイアウォール規則を追加で構成することもできます。

Administrator access path

サーバーレベルのファイアウォールが正しく構成されている場合、SQL サーバー管理者Azure Active Directory 管理者は、SQL Server Management Studio や SQL Server Data Tools などのクライアント ツールを使用して接続できます。 すべての機能を提供しているのは、最新のツールだけです。 次の図は、2 つの管理者アカウントの標準的な構成を示しています。

Administrator access path

サーバー レベルのファイアウォールで開かれているポートを使用する場合、管理者はどの SQL データベースにも接続できます。

SQL Server Management Studio を使用したデータベースへの接続

サーバー、データベース、サーバー レベルのファイアウォール規則の作成や、SQL Server Management Studio を使用したデータベースの照会に関するチュートリアルについては、Azure Portal と SQL Server Management Studio を通じた Azure SQL Database のサーバー、データベース、ファイアウォール規則の使用に関するページを参照してください。

重要

常に最新バージョンの Management Studio を使用して、Microsoft Azure と SQL Database の更新プログラムとの同期を維持することをお勧めします。 SQL Server Management Studio を更新します

追加のサーバー レベルの管理者ロール

前に説明したサーバーレベルの管理者ロールのほかに、SQL Database には master データベースに 2 つの制限付き管理者ロールが用意されています。それにユーザー アカウントを追加して、データベースの作成またはログインの管理のためのアクセス許可を付与することができます。

データベース作成者

これらの管理者ロールの 1 つは、dbmanager ロールです。 このロールのメンバーは、新しいデータベースを作成できます。 このロールを使用するには、master データベースにユーザーを作成し、そのユーザーを dbmanager データベース ロールに追加します。 データベースを作成するユーザーは、master データベースの SQL Server ログインに基づくユーザーであるか、Azure Active Directory ユーザーに基づく包含データベース ユーザーである必要があります。

  1. 管理者アカウントを使用して、master データベースに接続します。
  2. 省略可能な手順: CREATE LOGIN ステートメントを使用して、SQL Server 認証ログインを作成します。 サンプル ステートメントは、次のとおりです。

    CREATE LOGIN Mary WITH PASSWORD = '<strong_password>';
    

    注意

    ログイン ユーザーまたは包含データベース ユーザーを作成するときは、強力なパスワードを使用します。 詳細については、「 強力なパスワード」を参照してください。

    パフォーマンスを向上させるため、ログイン (サーバー レベルのプリンシパル) はデータベース レベルで一時的にキャッシュされます。 認証キャッシュを更新する方法については、「 DBCC FLUSHAUTHCACHE」をご覧ください。

  3. master データベースで、 CREATE USER ステートメントを使用してユーザーを作成します。 このユーザーは、Azure Active Directory 認証の包含データベース ユーザー (Azure AD 認証用の環境を構成した場合)、SQL Server 認証の包含データベース ユーザー、または SQL Server 認証ログインに基づく SQL Server 認証ユーザー (前の手順で作成したもの) にすることができます。サンプル ステートメントは、次のとおりです。

    CREATE USER [mike@contoso.com] FROM EXTERNAL PROVIDER;
    CREATE USER Tran WITH PASSWORD = '<strong_password>';
    CREATE USER Mary FROM LOGIN Mary; 
    
  4. ALTER ROLE ステートメントを使用して、新しいユーザーを dbmanager データベース ロールに追加します。 サンプル ステートメントは、次のとおりです。

    ALTER ROLE dbmanager ADD MEMBER Mary; 
    ALTER ROLE dbmanager ADD MEMBER [mike@contoso.com];
    

    注意

    dbmanager は master データベースのデータベース ロールであるため、dbmanager ロールにはデータベース ユーザーのみを追加できます。 データベース レベルのロールにサーバー レベルのログインを追加することはできません。

  5. 必要に応じて、新しいユーザーに接続を許可するようにファイアウォール規則を構成します (新しいユーザーは、既存のファイアウォール規則でカバーされる可能性があります)。

これで、ユーザーは master データベースに接続し、新しいデータベースを作成できるようになりました。 データベースを作成したアカウントは、そのデータベースの所有者になります。

ログイン マネージャー

もう 1 つの管理者ロールは、ログイン マネージャー ロールです。 このロールのメンバーは、master データベースに新しいログインを作成することができます。 必要であれば、同じ手順を実行して (ログインとユーザーを作成し、ユーザーを loginmanager ロールに追加して)、ユーザーが master に新しいログインを作成できるようにすることができます。 通常、ログインは必要ありません。Microsoft は、ログインに基づくユーザーを使用する代わりに、データベース レベルで認証される包含データベース ユーザーを使用することを推奨しているからです。 詳細については、「 包含データベース ユーザー - データベースの可搬性を確保する」を参照してください。

管理者以外のユーザー

一般に、管理者以外のアカウントは、master データベースへのアクセスを必要としません。 CREATE USER (Transact-SQL) ステートメントを使用して、データベース レベルの包含データベース ユーザーを作成してください。 このユーザーは、Azure Active Directory 認証の包含データベース ユーザー (Azure AD 認証用の環境を構成した場合)、SQL Server 認証の包含データベース ユーザー、または SQL Server 認証ログインに基づく SQL Server 認証ユーザー (前の手順で作成したもの) にすることができます。詳細については、「 包含データベース ユーザー - データベースの可搬性を確保する」を参照してください。

ユーザーを作成するには、データベースに接続し、次の例のようなステートメントを実行します。

CREATE USER Mary FROM LOGIN Mary; 
CREATE USER [mike@contoso.com] FROM EXTERNAL PROVIDER;

最初、ユーザーを作成できるのは、データベースの管理者の 1 人か所有者だけです。 新しいユーザーの作成を他のユーザーに許可するには、次のようなステートメントを使用して、選択したユーザーに ALTER ANY USER アクセス許可を付与します。

GRANT ALTER ANY USER TO Mary;

データベースのフル コントロールを他のユーザーに与えるには、ALTER ROLE ステートメントを使用して、そのユーザーを db_owner 固定データベース ロールのメンバーにします。

注意

ログインに基づくデータベース ユーザーを作成するのは、一般に、複数のデータベースへのアクセスを必要とする SQL Server 認証ユーザーがいる場合があるためです。 ログインに基づくユーザーは、ログインと、そのログインのために保持されている 1 つのパスワードのみに関連付けられています。 個々のデータベース内の包含データベース ユーザーは、それぞれが個別のエンティティであり、それぞれが独自のパスワードを保持します。 このため、包含データベース ユーザーは、同じパスワードを保持しない場合に混乱することがあります。

データベース レベルのファイアウォールの構成

ベスト プラクティスとして、管理者以外のユーザーは、使用するデータベースにファイアウォール経由でのみアクセスできるようにすることをお勧めします。 サーバー レベルのファイアウォール経由で IP アドレスを承認し、すべてのデータベースへのアクセスを許可するのではなく、sp_set_database_firewall_rule ステートメントを使用して、データベース レベルのファイアウォールを構成してください。 データベース レベルのファイアウォールは、ポータルを使用して構成することはできません。

Non-administrator access path

データベース レベルのファイアウォールが正しく構成されると、データベース ユーザーは SQL Server Management Studio や SQL Server Data Tools などのクライアント ツールを使用して接続できます。 すべての機能を提供しているのは、最新のツールだけです。 次の図は、管理者以外の標準的なアクセス パスを示しています。

Non-administrator access path

グループとロール

効率的なアクセス管理では、個々のユーザーではなく、グループとロールに割り当てられたアクセス許可を使用します。

  • Azure Active Directory 認証を使用する場合は、Azure Active Directory ユーザーを Azure Active Directory グループに入れます。 そのグループ用に包含データベース ユーザーを作成します。 1 人または複数のデータベース ユーザーをデータベース ロールに追加し、データベース ロールにアクセス許可を割り当てます。

  • SQL Server 認証を使用する場合は、データベースに包含データベース ユーザーを作成します。 1 人または複数のデータベース ユーザーをデータベース ロールに追加し、データベース ロールにアクセス許可を割り当てます。

データベース ロールは、db_ownerdb_ddladmindb_datawriterdb_datareaderdb_denydatawriterdb_denydatareader などの組み込みロールを指定できます。 db_owner は、少数のユーザーのみに完全なアクセス許可を付与する際によく使用されます。 他の固定データベース ロールは、開発段階の単純なデータベースをすばやく取得するには便利ですが、運用段階のほとんどのデータベースには推奨されません。 たとえば、db_datareader 固定データベース ロールは、データベース内のすべてのテーブルへの読み取りアクセスを許可しますが、これは、通常、必要以上のことです。 CREATE ROLE ステートメントを使用して独自のユーザー定義データベース ロールを作成し、各ロールに対してビジネスのニーズに応じて必要な最小限のアクセス許可を慎重に付与することをお勧めします。 ユーザーが複数のロールのメンバーである場合は、それらのアクセス許可すべてが集約されます。

アクセス許可

SQL Database では、個別に許可または拒否できるアクセス許可が 100 個を超えています。 これらのアクセス許可の多くは、入れ子になっています。 たとえば、スキーマに対する UPDATE アクセス許可には、そのスキーマ内の各テーブルに対する UPDATE アクセス許可が含まれています。 ほとんどのアクセス許可システムと同様に、アクセス許可の拒否は許可より優先されます。 入れ子になっている性質と、アクセス許可の数により、データベースを正しく保護するのに適切なアクセス許可システムを設計するには、慎重な調査を行う場合があります。 まず「権限 (データベース エンジン)」でアクセス許可の一覧を確認してから、アクセス許可のポスター サイズの図も確認してください。

考慮事項と制限

SQL Database のログインとユーザーの管理では、以下の点を考慮してください。

  • CREATE/ALTER/DROP DATABASE ステートメントを実行する場合は、master データベースに接続する必要があります。
  • サーバー管理者ログインに対応するデータベース ユーザーは、変更または削除できません。
  • サーバー管理者ログインの既定の言語は英語 (米国) です。
  • 管理者 (サーバー管理者ログインまたは Azure AD 管理者) と、master データベースの dbmanager データベース ロールのメンバーにのみ、CREATE DATABASE および DROP DATABASE ステートメントを実行するアクセス許可があります。
  • CREATE/ALTER/DROP LOGIN ステートメントを実行する場合は、master データベースに接続する必要があります。 ただし、ログインの使用はお勧めできません。 代わりに、包含データベース ユーザーを使用してください。
  • ユーザー データベースに接続するには、接続文字列にそのデータベースの名前を指定する必要があります。
  • サーバーレベル プリンシパル ログインと、master データベースの loginmanager データベース ロールのメンバーにのみ、CREATE LOGINALTER LOGINDROP LOGIN ステートメントを実行する権限があります。
  • ADO.NET アプリケーションで CREATE/ALTER/DROP LOGINCREATE/ALTER/DROP DATABASE ステートメントを実行する場合、パラメーター化コマンドは使用できません。 詳細については、「 コマンドとパラメーター」をご覧ください。
  • CREATE/ALTER/DROP DATABASECREATE/ALTER/DROP LOGIN ステートメントを実行する場合、これらの各ステートメントは、Transact-SQL バッチ内の唯一のステートメントである必要があります。 一致しないと、エラーが発生します。 たとえば、以下の Transact-SQL は、データベースが存在するかどうかを確認します。 存在する場合は、 DROP DATABASE ステートメントが呼び出され、データベースが削除されます。 DROP DATABASE ステートメントはバッチ内の唯一のステートメントではないので、これを実行すると Transact-SQL はエラーになります。

    IF EXISTS (SELECT [name]
             FROM   [sys].[databases]
             WHERE  [name] = N'database_name')
    DROP DATABASE [database_name];
    GO
    
  • CREATE USER ステートメントを FOR/FROM LOGIN オプションと共に実行する場合、これが Transact-SQL バッチ内の唯一のステートメントである必要があります。

  • ALTER USER ステートメントを WITH LOGIN オプションと共に実行する場合、これが Transact-SQL バッチ内の唯一のステートメントである必要があります。
  • ユーザーに対して CREATE/ALTER/DROP を実行するには、データベースに対する ALTER ANY USER 権限が必要です。
  • データベース ロールの所有者が、そのデータベース ロールに対して他のデータベース ユーザーの追加または削除を行おうとすると、「User or role 'Name' does not exist in this database.」というエラーが発生する場合があります。 このエラーは、所有者からはユーザーが見えないために発生します。 この問題を解決するには、そのユーザーに対する VIEW DEFINITION 権限をロールの所有者に許可します。

次のステップ