WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

ユーザー権限の設定

by WebSurfer 2010年9月12日 20:55

開発環境でユーザーインスタンスを使って DB に接続するのではなく、DB ファイル(mdf ファイル)を SQL Server データーベースエンジンにアタッチして、それにアクセスして使えるようにするには、いろいろ面倒なことがいっぱいあります。

今回は、DB のアタッチとか、ログインユーザーの作成は済んでいるとして、ログインユーザーへの権限の与え方について備忘録を書いておきます。

ログインユーザーのサーバーロール設定

まず左の画像ですが、BGLB\SQLUser というログインユーザーへサーバーロールを与えているところです。クリックすると拡大画像が表示されます。

サーバーロールを与えるというより、デフォルトで public 権限が与えられていて、自分では何も設定していないのですが。(画像のように public にはデフォルトでチェックが入っていて、それを外そうとしても外せません)

public のサーバーレベルでの権限は、デフォルトで VIEW ANY DATABASE 権限と、既定のエンドポイント(TSQL Local Machine、TSQL Named Pipes、TSQL Default TCP、TSQL Default VIA)に対する CONNECT 権限のみです。権限は変更できるのですが、よほどの事情がない限り変更する必要はなさそうです。権限を追加したりすると、ログインユーザー全員にサーバーレベルでその権限を与えてしまうことになるので、注意が必要です。

ログインユーザーには、public の他に、dbcreator など 固定サーバーロール の権限を与えることができますが、データベースの更新、削除、実行、接続、選択、挿入をするだけの一般ユーザーに対しては、与えるサーバーロールは public のみで不足はないと思います。

ときどき、ADO.NET を使ったアプリケーションが出す "dbcreator 権限がありません" というようなエラーメッセージに惑わされ(?)て、ログインユーザーに dbcreator のセキュリティ特権を与えて(上の画像で言うと[サーバーロール (S):]下の一覧の中の dbcreator にチェックを入れて)解決したという記事を Web で目にしますが、それはやりすぎです。そのユーザーにサーバー全体で dbcreator 権限を与えてしまうことになりますので。

ログインユーザーの作り方は割愛しますが、何故 BGLB\SQLUser というドメインユーザーアカウントを使っているかについて、ちょっと説明します。

自分の試験環境ではドメインコントローラに SQL Server をインストールしていますが(サーバーを 1 台しか持っていないので、苦肉の手段です)、その場合、NETWORK SERVICE マシンアカウントを SQL Server の実行アカウントに使用できないそうです(やってみましたが、実際できませんでした)。

そういうわけで、BGLB\SQLUser というドメインユーザーアカウントを設けて、それを SQL Server の実行アカウントにしています。

また、NETWORK SERVICE は何故かログインアカウントに設定できなかったので、BGLB\SQLUser をログインアカウントにしています。Web アプリケーション(IIS のワーカープロセス)から SQL Server にアクセスするために、BGLB\SQLUser を偽装しています。

ユーザーマッピング

次にユーザーマッピングの設定です。「このログインにマップされたユーザー(D)」でアクセスする DB を指定します。

アクセスする DB にチェックをつけるだけで、その他はデフォルトで OK です。「UserDatabase のデータベースロールメンバーシップ(R)」もデフォルトの public のみとしておきます。

アクセス権限の細かい設定は、それぞれの DB で行います。もちろん、それぞれの DB で行うより上位のレベル(即ち、ログインアカウントでの設定)でも可能ですが、それでは権限の与えすぎになってしまうようです。

その設定は、当該 DB を右クリックして表示される「データベースのプロパティ」ダイアログで行います。次の画像を見てください。

ユーザーマッピング

「ユーザーまたはロール(U)」でアカウントを選んで(画像では BGLB\SQLUser のみですが)、「BGLB\SQLUser の権限(P)」で「明示的」タブを選択します。

そこで、更新、削除、実行、接続、選択、挿入にチェックを入れれば、ほとんどの場合 OK だと思います。

この画面は、「明示的」タブでの選択結果を「有効」タブで確認しているところです。

本当は、データを操作するのに必要なストアドを作って、ストアドに権限を設定するのがよいのだそうです(DB 全体に対する権限を与えるのではなくて)。

でも、そこまではとてもできないので、特定のアカウントに対して、特定の DB 全体を CONNECT, EXECUTE, SELECT, INSERT, DELETE, UPDATE できる 6 つの権限を与えてみました。それでは権限の与えすぎかもしれませんが。

以上、特定のデーターベースユーザーに権限を与える方法を書きましたが、データベースロールを使う方法もあります。

例えば、データベースロールの中にも public ロールがあり、これに権限を与えると当該データベースのデータベースユーザー(ログインユーザーではなくて当該データベースにマップされた特定のユーザーのみである点に注意)全員にその権限が適用されます。

それではあるユーザーに対しては権限の与えすぎになってしまう場合は、そのユーザーの権限を「拒否」して調整することができます。

その方法については、SQL Server 2012 自習書の記事 3.8 オブジェクト権限の状態(GRANT/DENY/REVOKE)が参考になると思います。

Tags:

SQL Server

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年3月  >>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar