演習 - データベースにアクセスできるユーザーの制御

完了

ネットワーク経由でデータベースに接続できたとしても、データ自体に実際にアクセスできるとは限りません。 階層化されたアプローチに従って、データにアクセスする必要があるユーザーのみが実際にデータにアクセスできるようにする必要があります。 このアクセスには認証と承認が必要です。

認証

認証は、身元を確認するプロセスです。 この身元は、ユーザーの場合もあれば、システムで実行されているサービスや、システム自体 (仮想マシンなど) である場合もあります。 認証のプロセスを通じて、その人またはシステムが本人であることを確認します。 SQL Database では、次の 2 種類の認証がサポートされています。"SQL 認証" と "Microsoft Entra 認証" です。

SQL 認証

SQL 認証方法では、ユーザー名とパスワードが使用されます。 ユーザー アカウントは、メイン データベースに作成することができ、サーバー上のすべてのデータベースでアクセス許可を付与できます。 また、データベース自体にユーザーを作成して (包含ユーザーと呼ばれます)、そのデータベースへのアクセス権のみを付与することもできます。 データベース用の論理サーバーを作成したときに、ユーザー名とパスワードを使用して "サーバー管理者" サインインを指定しました。 これらの資格情報を使用すると、データベース所有者 (dbo) として、そのサーバー上のすべてのデータベースを認証できます。

Microsoft Entra 認証

この認証方法は、Microsoft Entra ID によって管理されている ID を使用し、マネージドおよび統合ドメインに対してサポートされます。 可能な場合は常に、Microsoft Entra 認証 (統合セキュリティ) を使用してください。 Microsoft Entra 認証を使用すると、データベース ユーザーと他の Microsoft サービスの ID を 1 か所で管理できます。 ID の一元管理では、1 か所でデータベース ユーザーを管理できるようになるため、アクセス許可の管理が容易になります。 Microsoft Entra 認証を使用する場合は、Microsoft Entra のユーザーとグループの管理を許可された "Microsoft Entra 管理者" と呼ばれるサーバー管理者を別に作成する必要があります。 この管理者は、通常のサーバー管理者が実行できるすべての操作も実行できます。

承認

承認とは、ある ID が Azure SQL Database 内で実行できることを指します。 この承認は、ユーザー アカウントやデータベース ロールのメンバーシップに対して直接付与されるアクセス許可によって制御されます。 データベース ロールは、アクセス許可をグループ化して管理を容易にするために使用されます。 ユーザーにロールを追加して、そのロールが持つアクセス許可を付与します。 これらのアクセス許可には、データベースにサインインする機能、テーブルを読み取る機能、データベースの列を追加および削除する機能が含まれます。 ベスト プラクティスとして、ユーザーに付与する特権は必要最低限のものにする必要があります。 承認を付与するプロセスは、SQL と Microsoft Entra のどちらのユーザーでも同じです。

この例では、接続するサーバー管理者アカウントは db_owner ロールのメンバーであり、データベース内ですべての操作を実行できる権限があります。

実際の認証と承認

ベスト プラクティスとして、アプリケーションでは認証に専用アカウントを使用する必要があります。 この方法により、アプリケーションに付与されるアクセス許可を制限でき、アプリケーション コードが SQL インジェクション攻撃に対して脆弱な場合に、悪意のあるアクティビティのリスクを軽減できます。 包含データベース ユーザーを作成する方法をお勧めします。この方法により、アプリはデータベースに対して直接認証を行うことができます。 詳細については、「包含データベース ユーザー - データベースの可搬性を確保する」を参照してください。

Microsoft Entra 認証は、データベース ユーザーの ID を一元管理するために、SQL Server 認証の代替として使用します。

ユーザーを設定して、データベースへのアクセス権を付与する方法を見てみましょう。 この場合は、ユーザーに対して SQL 認証を使用しますが、Microsoft Entra 認証を使用する場合でもプロセスは基本的に同じです。

データベース ユーザーを作成する

アクセス権を付与するために使用できる新しいユーザーを作成します。

  1. appServer VM 上の Cloud Shell で、ADMINUSER として再びデータベースに接続します。

    sqlcmd -S tcp:serverNNNNN.database.windows.net,1433 -d marketplaceDb -U '[username]' -P '[password]' -N -l 30
    
  2. 次のコマンドを実行して、新しいユーザーを作成します。 このユーザーは "包含ユーザー" であり、marketplace データベースへのアクセスのみが許可されます。 パスワードは必要に応じて自由に調整できますが、後の手順で必要になるので必ずメモしてください。

    CREATE USER ApplicationUser WITH PASSWORD = 'YourStrongPassword1';
    GO
    

これらの資格情報により、ユーザーはデータベースに対する認証を行うことができますが、データへのアクセスは許可されていません。 このユーザーにアクセスを許可します。

ユーザーにアクセス許可を付与する

ユーザーを db_datareader ロールと db_datawriter ロールのメンバーにして、それぞれデータベースに対する読み取りと書き込みのアクセスを許可します。 また、このユーザーが、アドレスを含むテーブルにアクセスできないようにする必要もあります。

  1. appServer 上で sqlcmd に接続したまま、次の T-SQL を実行して、作成したユーザーに db_datareader ロールと db_datawriter ロールを付与します。

    ALTER ROLE db_datareader ADD MEMBER ApplicationUser;
    ALTER ROLE db_datawriter ADD MEMBER ApplicationUser;
    GO
    
  2. アクセスの範囲をさらに制限することができます。 DENY 演算子を使用して、データベース内の他の要素へのユーザー アクセスを拒否できます。 次の T-SQL を実行して、ユーザー ApplicationUserSalesLT.Address テーブルからデータを選択できないようにします。

    DENY SELECT ON SalesLT.Address TO ApplicationUser;
    GO
    

では、そのユーザーとしてサインインし、この構成が実際に動作することを確認しましょう。

  1. T-SQL のプロンプトで「exit」と入力してセッションを終了します。

  2. 今度は、作成したユーザーとしてデータベースにもう一度サインインしてみましょう。

    sqlcmd -S tcp:serverNNNNN.database.windows.net,1433 -d marketplaceDb -U 'ApplicationUser' -P '[password]' -N -l 30
    
  3. 次のクエリを実行します。 このクエリは、ユーザーがアクセスを許可されているテーブルからデータをプルします。

    SELECT FirstName, LastName, EmailAddress, Phone FROM SalesLT.Customer;
    GO
    

    顧客の一覧が戻るはずです。

    FirstName      LastName       EmailAddress                    Phone
    -------------- -------------- ------------------------------- ------------
    Orlando        Gee            orlando0@adventure-works.com    245-555-0173
    Keith          Harris         keith0@adventure-works.com      170-555-0127
    Donna          Carreras       donna0@adventure-works.com      279-555-0130
    Janet          Gates          janet1@adventure-works.com      710-555-0173
    ...
    
  4. アクセス権のないテーブルのクエリを実行しようとするとどうなるかを見てみましょう。

    SELECT * FROM SalesLT.Address;
    GO
    

    このテーブルへのアクセス権がないというメッセージが表示されるはずです。

    Msg 229, Level 14, State 5, Server server-22942, Line 1
    The SELECT permission was denied on the object 'Address', database 'marketplace', schema 'SalesLT'.
    

ご覧のように、データベースへの読み取り/書き込みアクセスを許可しても、テーブルへのアクセスを明示的に拒否すると、データへのアクセス保護を強化できます。 同様のアクセスを共有する複数のユーザーがいる場合は、適切なアクセス許可を持つカスタム ロールを作成して、管理を簡素化できます。

データベースを適切に保護し、必要な場合にのみアクセスを許可することが重要です。 Azure SQL Database で提供されている組み込み機能を使用して、データベース内のデータへのアクセスに対する ID の認証と承認を完全に制御することができます。