SQL Serverのオブジェクトに権限を設定する：SQL実践講座（17）

　今回は、SQL Serverにおける権限の設定にチャレンジします。Windows NTやWindows 2000のファイルに対するアクセス権と同様に、SQL Serverでは、テーブルやビューといったSQL Serverのオブジェクトに対して権限を設定することが可能です。権限の設定により、特定のユーザーのみが参照できるビューや、特定のユーザーは参照可能だがデータの追加や更新ができないテーブル、などを作成することが可能になります。

　まずは、デフォルトの設定を確認するところから始めましょう。

SQL Server Enterprise Managerによる権限の確認

　SQL Serverに標準で作成されるSQL Serverログインについて確認します。SQL

Serverログインとは、SQL Serverに接続する際に入力するログイン名のことです。

例題1：「SQL Serverログインを確認する」

(1) Enterprise Managerを起動する

(2) 左端に表示される「ツリー」で、以下を順に展開する

(3) 表示される結果は以下のとおり

画面1　SQL Serverログインを一覧表示させたところ（画面をクリックすると拡大表示します）

　SQL Serverをインストールした段階で作成された「sa」と「BUILTIN\Administrators」という、2つのSQL Serverログインが表示されているのが確認できます。これら2つのSQL Serverログインは、データベースに対するすべての操作が許可されているシステム管理者用のログイン名です。連載ではこれまで、すべてsaというSQL Serverログインで例題を実行してきました。

　ログイン名には、2つの種類があります。1つは、SQL Serverのみで利用する独自のSQL Serverログインです。これを、「SQL Server認証のログイン」と呼びます。標準で作成されるsaは、SQL Server認証のログインです。SQL Server Enterprise Managerで表示されているSQL Serverログインを右クリックし、「プロパティ」を選択すると表示される画面で確認できます。

画面2　SQL Serverログイン名「sa」のプロパティを表示させたところ（画面をクリックすると拡大表示します）

　「認証」が「SQL Server認証」に設定されているのが確認できますね。

　2つ目の種類が、WindowsNTやWindows2000のアカウントを利用する「Windows認証のログイン」です。BUILTIN\Administratorsは、Windows認証のログインです。プロパティで確認してみましょう。

画面3　SQL Serverログイン名「BUILTIN-Administrators」のプロパティを表示させたとこる（画面をクリックすると拡大表示します）

　「認証」が「Windows認証」に設定されているのが確認できますね。Windows認証は、SQL Serverではなく、Windowsによってログイン名とパスワードの認証が実行されます。ドメインが構築されている環境では、ドメインユーザーの指定も可能です。

　Windows認証の便利なところは、ログイン名の一括管理が可能であるため、管理者の作業を減らせることです。もう1つは、Windowsにログオンしていれば、SQL Serverに接続する際にSQL Serverログインとパスワードを入力しなくてよいため、ユーザーも便利であるということです。特に、何日目ごとにパスワード変更を強制する、といったセキュリティポリシー設定に関してはWindowsの方が細かく設定できるので、セキュリティの向上のためにもWindows認証の方がお勧めできます。

SQL Serverログインの作成

　では、新規にSQL Serverログインを作成してみましょう。今回は、SQL Server Enterprise ManagerでSQL Server認証ログインの作成を行います。

例題2：「SQL Serverログインを作成する」

(1) ツリーから「ログイン」を右クリックし、「新規ログイン」を選択する

画面4　SQL Serverログインを新規作成する場合には、Enterprise Managerで「ログイン」アイコンを右クリック、表示されるメニューから「新規ログイン」を選択する（画面をクリックすると全体を表示します）

(2) 表示された画面で、「名前」欄に「rensai」と入力する

(3) 「SQL Server認証」ラジオボタンを選択し、「パスワード」欄に「rensai」と入力する

(4) 「規定値」欄の「データベース」から「Northwind」を選択する

(5) 「OK」をクリックして完了する

画面5　SQL Serverログインの新規作成画面（画面をクリックすると拡大表示します）

(6) パスワードの確認画面が表示されるので、「rensai」と再度入力する

(7) Enterprise Managerのログインのリストに、rensaiが表示されるのを確認する

　「規定値」のデータベース設定は、SQL Serverに接続した際にデフォルトでアクセスするデータベースを指定します。こうすることにより、ログインした後に毎回データベースを選択する手間を省けます。

　では早速、作成したSQL ServerログインでSQL Serverに接続し、KeppinListビューを参照してみましょう。

例題3：「新規作成したSQL Serverログインで既存のビューを表示」

(1) クエリアナライザを起動し、作成したSQL Serverログインでログインする

(2) 「SELECT * FROM KeppinList」と入力し、実行する

画面6　新規作成したSQL ServerログインでKeppinListビューを表示させようとしたところ、「権限がない」旨のエラーが表示されて失敗してしまった（画面をクリックすると拡大表示します）

　ログインは正常にできたものの、KeppinListビューの参照はエラーが表示されて失敗してしまいましたね。これは、新規に作成したSQL Serverログインには、どのデータベースオブジェクトに対しても権限が設定されていないために起こります。

権限の割り当て

　では次に、rensaiログインに対して、KeppinListビューに対する権限の割り当てを実施しましょう。まずは、データベースに対する権限を設定します。

例題4：「SQL Serverログイン『rensai』に権限を与える」

(1) SQL Server Enterprise Managerでrensaiログインを右クリックし、「プロパティ」を選択する

(2) 「データベース アクセス」タブを選択する

(3) データベースのリストにおいて、「Northwind」データベースをチェックする

(4) 「OK」ボタンをクリックし、プロパティ画面を閉じる

画面7　新規作成したSQL Serverログイン「rensai」に、「Northwind」データベースへのアクセス権限を設定する（画面をクリックすると拡大表示します）

　続いて、データベースのユーザーを確認します。まずは、ユーザーリストを表示させてみましょう。

例題5：「データベースのユーザーリストを表示」

(1) SQL Server Enterprise Managerで左端に表示される「ツリー」で、以下を順に展開する

(2) 表示される結果は以下のとおり

画面8　「Northwind」データベースのユーザー一覧を、Enterprise Managerで表示してみたところ（画面をクリックすると全体を表示します）

　先ほど作成した「rensaiログイン」と同名のユーザーが登録されているのが確認できます。SQL Serverでは、SQL Serverへのログインアカウントと、データベースのユーザーを別々に管理しています。例題4の操作でSQL Serverログインに対してデータベースアクセスの設定を行うと、自動的にSQL Serverログインと同名のユーザーがデータベースに対して登録されます。このときユーザーは、1つのSQL Serverログインと自動的に結び付けられます。ここでは「rensai」SQL Serverログインが、「rensai」ユーザーと結び付けされたのが確認できますね。SQL Serverに対して「rensai」でログインしているときは、Northwindデータベースに対しては、「rensai」ユーザーとして認識されます。この後説明するテーブルやビューなど、データベースオブジェクトに対する権限設定は、SQL Serverログインではなく、ユーザーに対して実施されます。

　SQL Serverログインと、ユーザーが別に管理される考え方は若干複雑ですが、デフォルトの操作で同じ名前で登録されるので、混乱は少ないでしょう。

データベースオブジェクトへの権限の割り当て

　では次に、「rensai」ユーザーがKeppinListビューにアクセスできるよう設定しましょう。

例題6：「ユーザーの特定のビューへのアクセス権の設定」

(1) SQL Server Enterprise Managerで左端に表示される「ツリー」で、以下を順に展開する

(2) ビューリストの中から、「KeppinList」を右クリックし、「プロパティ」を選択する

(3) 「権限」ボタンをクリックする

(4) 表示される画面で、「rensai」ユーザーの「SELECT」をチェックする

(5) 「OK」をクリックし完了する

画面9　「rensai」ユーザーに、「KeppinList」ビューへの「SELECT」文でのアクセス許可を与える（画面をクリックすると拡大表示します）

　では、権限が無事設定されたことを確認するために、クエリアナライザで再度、例題3を実行してみましょう。問題なく結果リストが表示されたでしょうか？

　データベースのテーブルやビューに対しては、SELECT、INSERT、UPDATE、DELETEの権限がそれぞれ設定できます。例題6で最初に権限の設定画面を開いたときは、すべてのチェックボックスが空白の状態でしたね。この状態では、System Administrator権限のあるユーザーしか、オブジェクトにアクセスすることはできません。

　例題6で、KeppinListに対してSELECTをチェックしましたが、これによりユーザーに対してSELECT権限が付与されます。逆に、明示的に権限を拒否することも可能です。この場合は、SELECTのチェックボックスにチェックが入った状態で、もう一度クリックし、×印の状態に設定することで拒否できます。

画面10　画面9のチェックが入った状態から、さらにクリックすることで×印になる。こうすることで、明示的に権限を拒否することが可能となる（画面をクリックすると拡大表示します）

　チェックが付いていない初期状態でもアクセスが許可されないのに、わざわざ明示的に拒否を指定する必要があるのか、と思いませんでしたか？ これは、次回説明する「権限の継承」に大きく関係しますので、覚えておいてください。