今回は、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) 左端に表示される「ツリー」で、以下を順に展開する
- Microsoft SQL Servers
- SQL Server グループ
- サーバー名
- セキュリティ
- ログイン
(3) 表示される結果は以下のとおり
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ログインを右クリックし、「プロパティ」を選択すると表示される画面で確認できます。
「認証」が「SQL Server認証」に設定されているのが確認できますね。
2つ目の種類が、WindowsNTやWindows2000のアカウントを利用する「Windows認証のログイン」です。BUILTIN\Administratorsは、Windows認証のログインです。プロパティで確認してみましょう。
「認証」が「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」をクリックして完了する
(6) パスワードの確認画面が表示されるので、「rensai」と再度入力する
(7) Enterprise Managerのログインのリストに、rensaiが表示されるのを確認する
「規定値」のデータベース設定は、SQL Serverに接続した際にデフォルトでアクセスするデータベースを指定します。こうすることにより、ログインした後に毎回データベースを選択する手間を省けます。
では早速、作成したSQL ServerログインでSQL Serverに接続し、KeppinListビューを参照してみましょう。
例題3：「新規作成したSQL Serverログインで既存のビューを表示」
(1) クエリアナライザを起動し、作成したSQL Serverログインでログインする
(2) 「SELECT * FROM KeppinList」と入力し、実行する
ログインは正常にできたものの、KeppinListビューの参照はエラーが表示されて失敗してしまいましたね。これは、新規に作成したSQL Serverログインには、どのデータベースオブジェクトに対しても権限が設定されていないために起こります。
権限の割り当て
では次に、rensaiログインに対して、KeppinListビューに対する権限の割り当てを実施しましょう。まずは、データベースに対する権限を設定します。
例題4：「SQL Serverログイン『rensai』に権限を与える」
(1) SQL Server Enterprise Managerでrensaiログインを右クリックし、「プロパティ」を選択する
(2) 「データベース アクセス」タブを選択する
(3) データベースのリストにおいて、「Northwind」データベースをチェックする
(4) 「OK」ボタンをクリックし、プロパティ画面を閉じる
続いて、データベースのユーザーを確認します。まずは、ユーザーリストを表示させてみましょう。
例題5：「データベースのユーザーリストを表示」
(1) SQL Server Enterprise Managerで左端に表示される「ツリー」で、以下を順に展開する
- Microsoft SQL Server
- SQL Server グループ
- サーバー名
- データベース
- Northwind
- ユーザー
(2) 表示される結果は以下のとおり
先ほど作成した「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で左端に表示される「ツリー」で、以下を順に展開する
7. Microsoft SQL Servers
8. SQL Server グループ
9. サーバー名
10. データベース
11. Northwind
12. ビュー
(2) ビューリストの中から、「KeppinList」を右クリックし、「プロパティ」を選択する
(3) 「権限」ボタンをクリックする
(4) 表示される画面で、「rensai」ユーザーの「SELECT」をチェックする
(5) 「OK」をクリックし完了する
では、権限が無事設定されたことを確認するために、クエリアナライザで再度、例題3を実行してみましょう。問題なく結果リストが表示されたでしょうか？
データベースのテーブルやビューに対しては、SELECT、INSERT、UPDATE、DELETEの権限がそれぞれ設定できます。例題6で最初に権限の設定画面を開いたときは、すべてのチェックボックスが空白の状態でしたね。この状態では、System Administrator権限のあるユーザーしか、オブジェクトにアクセスすることはできません。
例題6で、KeppinListに対してSELECTをチェックしましたが、これによりユーザーに対してSELECT権限が付与されます。逆に、明示的に権限を拒否することも可能です。この場合は、SELECTのチェックボックスにチェックが入った状態で、もう一度クリックし、×印の状態に設定することで拒否できます。
チェックが付いていない初期状態でもアクセスが許可されないのに、わざわざ明示的に拒否を指定する必要があるのか、と思いませんでしたか？ これは、次回説明する「権限の継承」に大きく関係しますので、覚えておいてください。
次回の予定
今回は、Enterprise Managerを使用した権限の設定について解説しました。次回は「ロール」という権限のグループについて紹介する予定です
- SQL Serverで「デッドロック」を回避する
- トランザクションの一貫性を保証するロック
- トランザクションを用いて注文登録をする
- トランザクションでデータの不整合を防ぐ
- テーブルで複数の処理を実行させるトリガー
- ユーザー定義関数を作成するストアドファンクション
- ストアドプロシージャによる繰り返し処理
- 条件分岐のあるストアドプロシージャ
- ストアドプロシージャの作成
- システム・ストアドプロシージャを用いたロールの詳細設定
- ロールを利用したグループ単位での権限設定
- SQL Serverのオブジェクトに権限を設定する
- Enterprise Managerによるビューの作成
- 作成したSELECT文をDBに登録する「ビュー」
- データの更新と主キーの重要性
- テーブル中のデータ識別に必要な主キーを定義する
- データの登録を行うINSERT文
- CREATE文をさらに使いこなそう
- CREATE文でテーブルを作成する
- SELECT文を統合する「UNION」
- サブクエリーの応用「相関サブクエリー」
- SELECT文の結果を抽出条件に使う
- テーブル結合のバリエーションを増やす
- テーブル結合の仕組みを理解する
- 異なるテーブル同士を結合する「JOIN」句
- 集計を行う「GROUP BY」句
- SELECT文で並べ替えを行うには？
- SQLの基礎 「SELECT」文を覚えよう
Copyright © ITmedia, Inc. All Rights Reserved.