- 2010-04-08 Thu 23:08:58
- db2
前回はこちら（http://hitai.blog72.fc2.com/blog-entry-54.html）
昨日は気圧が低かったせいか、頭の頭痛が痛くて寝てしまいました。
今日はセキュリティの分野です。
db2の認証方式は、OracleでいうとOS認証のみ（Radiusとかはあるけど一旦おいといて）で、データベース側での認証はありません。
OS認証といっても、DBサーバが入っているマシンでのOS認証と、db2クライアントがインストールされているマシンでのOS認証がある。
正確には、認証タイプ（AUTHENTICATION）には以下のパラメータが設定できる。らしい。
SERVER
→全てサーバOS側で認証
SERVER_ENCRYPT
→SERVERの設定＋送信されたユーザ名／パスワードが暗号化される
KERBEROS
→サーバ/クライアント双方にケルベロスがセットアップされていればケルベロスで認証。
どちらかにセットアップされていなければエラーで認証失敗。
KRB_SERVER_ENCRYPT
→クライアントがケルベロスならケルベロスで認証。そうでないならSERVER_ENCRYPTで。
CLIENT
→クライアントOSで認証を”許可”。
TRUST_ALLCLNTSとTRUST_CLNTAUTによって挙動が変化。
DATA_ENCRYPT
→データを暗号化する。（通信データの暗号化のこと？それともユーザ名/パスワード？）
V8.1以前のクライアントからは接続不可能。
DATA_ENCRYPT_CMP
→上と何がちがうかよくわからん。
基本的には一緒で、下位レベルクライアントの場合、ユーザデータを暗号化しないらしい。
GSSPLUGIN
GSS_SERVER_ENCRYPT
めんどくさいので省略。
というかここみて。（http://www.ibm.com/developerworks/jp/data/library/dataserver/j-d_db2security01/）
で、ここで疑問に思ったのが、認証タイプがCLIENTの動作。
例えば、
サーバOS：SV_USERユーザを作成済み
クライアントOS：CL_USERユーザを作成済み
AUTHENTICATIONをCLIENTに変更
TRUST_ALLCLNTSをYesに変更
この状態で、どのユーザでどんな認証が受けられ、どんな操作ができるのか。
ということで実験してみた。
ケース１：
クライアントOSにはCL_USERでログオン済み。
> db2 connect to sample
→成功。
list applicationsをすると、CL_USERでセッションがあることがわかる。
つまり、connectで明示的にユーザ名/パスワードを指定しなければ、現在ログオン中のユーザが使用される。
そして、サーバにはCL_USERなんてものはいないが、クライント側で認証されているので接続要求は通ってしまう。
ケース２：
クライアントOSにはCL_USERでログオン済み。
> db2 connect to sample user cl_user using xxxx
→成功。
理由はケース１と同じ。
そして、ケース１、２ともにカタログ表は参照可能。
例えば、select * from syscat.tablesなどができてしまう。
そしてcreate tableも通ってしまった。
ただし、sampleのemp表などは見れない。
これはどんな権限、特権があるのか小一時間悩んだのだけど、なんてことはない。
publicがcreate table特権を持っているのと、デフォルトではカタログの参照もできる状態だっただけ。
publicからcreate table権限を剥奪すれば、CL_USERはまったくなにも出来ない子になった。
そこでもう一つの疑問。
サーバで認証しないということは、どんな名前のユーザがアクセスしてくるかわからないということ。
ということは、事前に特権を与えておきたくても、与えられないとい。
使いどころとしては、複数のAPサーバからdb2へ接続する場合、各APサーバごとにOSユーザを割当、そのユーザ権限においてAPを起動し、そこからdb2に接続するような場合です。とあるドキュメントに書いてあったけど実運用としては考えにくいかも。
普通はSERVER認証でいいはず。
試験対策として、どこまで覚えておけばいいかなー。といったところが悩ましい。
参考書があればいいんだけど。（IBMさんまだ出さないんですか？）
とりあえずここまでが認証タイプの確認。
ついでにコマンド周りをめもめも。
接続
connect to [user [using ]]
インスタンスパラメータ（データベースマネージャ構成パラメータ）の参照
get dbm cfg [show detail]
インスタンスパラメータ（データベースマネージャ構成パラメータ）の変更
update dbm cfg using
パラメータによっては再起動が必要。
db2stop
db2start
明日は権限まわりの予定。
昨日は気圧が低かったせいか、頭の頭痛が痛くて寝てしまいました。
今日はセキュリティの分野です。
db2の認証方式は、OracleでいうとOS認証のみ（Radiusとかはあるけど一旦おいといて）で、データベース側での認証はありません。
OS認証といっても、DBサーバが入っているマシンでのOS認証と、db2クライアントがインストールされているマシンでのOS認証がある。
正確には、認証タイプ（AUTHENTICATION）には以下のパラメータが設定できる。らしい。
SERVER
→全てサーバOS側で認証
SERVER_ENCRYPT
→SERVERの設定＋送信されたユーザ名／パスワードが暗号化される
KERBEROS
→サーバ/クライアント双方にケルベロスがセットアップされていればケルベロスで認証。
どちらかにセットアップされていなければエラーで認証失敗。
KRB_SERVER_ENCRYPT
→クライアントがケルベロスならケルベロスで認証。そうでないならSERVER_ENCRYPTで。
CLIENT
→クライアントOSで認証を”許可”。
TRUST_ALLCLNTSとTRUST_CLNTAUTによって挙動が変化。
DATA_ENCRYPT
→データを暗号化する。（通信データの暗号化のこと？それともユーザ名/パスワード？）
V8.1以前のクライアントからは接続不可能。
DATA_ENCRYPT_CMP
→上と何がちがうかよくわからん。
基本的には一緒で、下位レベルクライアントの場合、ユーザデータを暗号化しないらしい。
GSSPLUGIN
GSS_SERVER_ENCRYPT
めんどくさいので省略。
というかここみて。（http://www.ibm.com/developerworks/jp/data/library/dataserver/j-d_db2security01/）
で、ここで疑問に思ったのが、認証タイプがCLIENTの動作。
例えば、
サーバOS：SV_USERユーザを作成済み
クライアントOS：CL_USERユーザを作成済み
AUTHENTICATIONをCLIENTに変更
TRUST_ALLCLNTSをYesに変更
この状態で、どのユーザでどんな認証が受けられ、どんな操作ができるのか。
ということで実験してみた。
ケース１：
クライアントOSにはCL_USERでログオン済み。
> db2 connect to sample
→成功。
list applicationsをすると、CL_USERでセッションがあることがわかる。
つまり、connectで明示的にユーザ名/パスワードを指定しなければ、現在ログオン中のユーザが使用される。
そして、サーバにはCL_USERなんてものはいないが、クライント側で認証されているので接続要求は通ってしまう。
ケース２：
クライアントOSにはCL_USERでログオン済み。
> db2 connect to sample user cl_user using xxxx
→成功。
理由はケース１と同じ。
そして、ケース１、２ともにカタログ表は参照可能。
例えば、select * from syscat.tablesなどができてしまう。
そしてcreate tableも通ってしまった。
ただし、sampleのemp表などは見れない。
これはどんな権限、特権があるのか小一時間悩んだのだけど、なんてことはない。
publicがcreate table特権を持っているのと、デフォルトではカタログの参照もできる状態だっただけ。
publicからcreate table権限を剥奪すれば、CL_USERはまったくなにも出来ない子になった。
そこでもう一つの疑問。
サーバで認証しないということは、どんな名前のユーザがアクセスしてくるかわからないということ。
ということは、事前に特権を与えておきたくても、与えられないとい。
使いどころとしては、複数のAPサーバからdb2へ接続する場合、各APサーバごとにOSユーザを割当、そのユーザ権限においてAPを起動し、そこからdb2に接続するような場合です。とあるドキュメントに書いてあったけど実運用としては考えにくいかも。
普通はSERVER認証でいいはず。
試験対策として、どこまで覚えておけばいいかなー。といったところが悩ましい。
参考書があればいいんだけど。（IBMさんまだ出さないんですか？）
とりあえずここまでが認証タイプの確認。
ついでにコマンド周りをめもめも。
接続
connect to
インスタンスパラメータ（データベースマネージャ構成パラメータ）の参照
get dbm cfg [show detail]
インスタンスパラメータ（データベースマネージャ構成パラメータ）の変更
update dbm cfg using
パラメータによっては再起動が必要。
db2stop
db2start
明日は権限まわりの予定。
スポンサーサイト
- Newer: DB2 9 エンジニア試験準備 ３：セキュリティ その２
- Older: DB2 9 エンジニア試験準備 １：プランニング
Comments: 0
Trackback+Pingback: 0
- TrackBack URL for this entry
- http://hitai.blog72.fc2.com/tb.php/55-f25e8be7
- Listed below are links to weblogs that reference
- DB2 9 エンジニア試験準備 ２：セキュリティ from ヒビコレショウジン
