DBMS

SQL Server で blocking されている resource を特定する方法

ちゃっぴ (tyappi@wankuma.com) — Sun, 13 Jun 2010 18:48:00 GMT

DB を扱っている時、各 resource がどのように lock されているか、すなわち blocking の状況を把握することが重要です。SQL Server 2005 以降で blocking の状態を調査するには [master].[sys].[dm_tran_locks] を SELECT してやることで取得できます。

まあ、実際には [master].[sys].[dm_tran_locks] だけでは必要な情報が足りない場合が多く、[master].[sys].[dm_exec_sessions] や [master].[sys].[dm_exec_connections] と結合したりしますがこちらについては下記の Figure 3 Capturing locking stats を参考にしてください。

SQL Server のブロッキングを最小限に抑える

[master].[sys].[dm_tran_locks] を SELECT してやることで取得できた lock 情報ですが、このままではわかりずらいのでまずは [resource_associated_entity_id] を object name に変換します。その変換 script が Figure 4 Learning more about blocked data です。環境によっては大文字小文字の統一や @resource_associated_entity_id を bigint に修正してから実行する必要がありますのでご注意を。

で table name が取れたらいよいよ lock されている resource を特定します。これには undocumented な %%lockres%% を利用します。

SELECT * FROM [table name] WHERE %%lockres%% = @resource_description

@resource_description に [master].[sys].[dm_tran_locks] で取得した値を設定して上記 SQL を実行してください。Lock されている行が取得できます。

%%lockres%% は非常に使えるので、ぜひ document に載せて欲しいなぁと思うのですが、過去にその feedback をされていた方がいました。

Make %%lockres%% a documented feature

結果は検証する時間が無いので行わないとのことです。残念です。

SQL Server で Kerberos 認証を有効にする

ちゃっぴ (tyappi@wankuma.com) — Mon, 03 May 2010 19:22:00 GMT

SQL Server で Windows 認証を利用する場合、認証に利用される protocol は Kerberos と NTLM から選択されます。いわゆる Negotiate というやつです。

既定の設定では Kerberos が利用可能な状態なら Kerberos が優先され、Kerberos が利用できない場合に NTLM が利用されます。

現在の接続がどちらの protocol を利用しているか調査するには下記 query を実行します。

SELECT [auth_scheme]
  FROM [master].[sys].[dm_exec_connections]
  WHERE [session_id] = @@SPID

[auth_scheme] は 'public' server role の member では選択できませんので上記は 'sysadmin' server role の member で実施してください。

意外に NTLM になっていること多いんじゃないでしょうか？

Kerberos が利用できない原因はいろいろ存在しますが、もっとも多いのが SPN (Service Principal Name) が登録されていないという状況です。

Remote から Kerberos を利用して接続を行うためには SPN の登録が必要です。SQL Server では service の起動時に SPN を登録しに行きます。Service account に Network Service account を利用している場合には、この自動登録で SPN が登録されます。しかし、domain account を利用している場合には失敗します。

というのは domain account の場合その domain account 自身の Service-Principal-Name attribute への書き込みが既定で許可されていないからです。

これを解消するためには SQL Server の service acount に指定した domain account の ACL で "Self" に対し "servicePrincipalName" への書き込みを許可します。Windows Server 2008 以降では「Active Directory ユーザーとコンピューター」からでも ACL の設定が可能ですが、"servicePrincipalName" は設定できません。そのため、作業は "ADSI エディター" から行ってください。

「ファイル名を指定して実行」から "adsiedit.msc"
「ADSI エディター」で SQL Server の service account を探し出し、[プロパティ]
[セキュリティ] tab で <詳細設定>
"SELF" (複数存在していてもどちらか一つで OK) を選択し、<編集>
[適用先] に「このオブジェクトのみ」で「servicePrincipalName の書き込み」を付与

上記設定が完了したら、SQL Server を再起動します。その後、下記 command を実行して SPN を確認します。

>setspn.exe -l Domain\Account

Domain, Account には SQL Server の service acount を入力してください。結果に下記が含まれれば OK です。

MSSQLSvc/DbServerName.FQDN:1433 MSSQLSvc/DbServerName

ここまで書きましたが、account の ACL を変更せずに setspn.exe を使って SPN を直接登録してしまってももちろん構いません。

これが完了したら、もう一度 query を投げて protocol を確認してみましょう。Kerberos になっていない場合には、firewall 等他の原因です。

なお、ここまでは SQL Server が Kerberos 認証を受け入れるための準備作業であり、Kerberos 委任を利用した multi-hop 許可の設定については説明していません。続きは次回。

SQL injection による Web page 改竄

ちゃっぴ (tyappi@wankuma.com) — Sat, 31 Jan 2009 23:04:00 GMT

昨年はまさしく SQL injection 祭りな一年でしたね。が、SQL injection による Web page の改竄が特に目立っていましたね。

とある情報によると特に 12 月の攻撃は一年通してもものすごい量に跳ね上がっていたとか。

で、今回話題にするのは SQL injection による Web 改竄です。

SQL injection の対策として第一に叫ばれるのは parametrized queries を利用しろ！とか、問題のある入力文字列を無効化しろ! といった coding 面ですね。

これは非常に正しい指摘です。SQL injection による問題は Web 改竄に限った話ではないので、絶対に必要なことですね。

ですが、Web 改竄に限るとどうなるでしょう？

Web 改竄で問題になるのは、本来管理者のみが変更を許可されるような Web page を変更されることです。掲示板や blog のような不特定多数が書き込みを許可されるものに対して悪意のある Web page への link を張ったからといっても問題になりませんね。

実際改竄が行われた Web page を参照してみると、管理者のみ変更を許可されるべき Web page がほとんどです。これって、そもそもおかしくないですか？

多くの DBMS では access control 機能を有しています。管理者のみ変更を許可する必要があるのであれば、DBMS 側の access control 機能で原則制御すべきでしょう。

それすらできていないところが攻撃を受けて深刻な問題を起こしているのが現状です。ぶっちゃけ、ありえね～！

このようなどうしようもない system を release したところは退場してもらうような制度が必要なんかじゃないかと思ったり。

DB への接続 user を共用する場合でも少しでも脅威を軽減できるように設計しよう

ちゃっぴ (tyappi@wankuma.com) — Sun, 11 May 2008 21:03:00 GMT

SQL injection を防ぐもうひとつの方法

DB への接続 user を共用した場合の client-server 構成での問題点

上記で SQL injection の根本的原因は DBMS で access control を行っていないことだと述べました。

DB への接続 user を個人単位で割り当て DBMS の acess control で制御してやりたいが、要求される performance と resource のため、どうしても利用することが難しい。そんな場合もあると思います。でも、DB への接続 user を共用化した場合は DBMS の access control を全く利用できないんでしょうか？

違いますよね。DB への接続 user を共用化するといっても、user は一つしか使ってはいけないということはないでしょう。処理の内容によって user を使い分けることはできるはずです。

たとえば、SELECT と UPDATE する user を分ける。Logon に利用する user も分離する。重要な data を扱う user も分離する。そして、それぞれ必要な最小限の権限のみ割り当てれる。

こうゆうことをやれば多少なりとも驚異を軽減することにつながるでしょう。Performance に関しても高々数 user を追加したところでさして変わるとは思えませんし。

多層で防御すればするほど security level は向上します。Stored procedure なり、parameterized query なり、sanitizing なりで SQL injection 対策を行うとともに、このような方法も検討してみてはいかがでしょうか？

DB への接続 user を共用した場合の client-server 構成での問題点

ちゃっぴ (tyappi@wankuma.com) — Sun, 11 May 2008 04:37:00 GMT

随分前の話ですが、SQL injection は Web application に限った話ではない。Client-server systemでも深刻な事態をもたらすといった意見が上がっていましたね。

SQL injection を防ぐもうひとつの方法で簡単に説明しましたが、 SQL injection が深刻な事態をもたらす根本的原因は、扱う data に十分な access control がなされていないことにあります。DB への接続 user を共用していれば、その user ですべての data を扱うことができるので、当然 SQL injection 攻撃を受けると大問題ですね。

でも、client-server system では構成によりもっと問題がある場合があるんです。では、ちょっと client-server system について考えてみましょう。

Client-server 構成は基本的に intranet で利用されているので network 構成はこんな感じが多いと思います。

もしくは、Application server もなく client から直接 DB 叩いているかもしれません。

さて、今回は DB への接続 user を共用した場合の話です。DB に接続する場合の認証情報はどこに保存されているか考えてみましょう。

Application server を利用している場合には application server に、application server を利用していない場合には client に保存されていると思います。

Application server を利用している場合では、Web application の場合と同様に application server に対する攻撃を封じてやるよう対策を行えばいいです。Web application を host する secure な network 構成で書いたような直接 DB server へ全く access できないような network 構成にして、cient 側には必要な service しか提供できないように firewall を構成する。もちろん application は全く脆弱性が存在しないように作成する必要があります。

ところが、application server が無い状態ではどうなるでしょうか？

認証情報は client に保存されます。こちらの場合、基本的に DB 接続用の認証情報が漏えいすると考えたほうがよいでしょう。Application に暗号化して埋め込んでもその暗号化 logic まで client に存在するため、一定の skill を持っている人であれば解析されます。

このような構成は基本的に取るべきではないでしょう。どうしても application server を利用できない場合には、共通の user など用意せず DBMS 側の access control を利用すべきです。この構成では must といっても問題ないでしょう。

なお、application server を利用しない場合でも、DB へ access する application を通常利用している OS account とは別のaccount で起動した process で扱うことにより一応保護することはできます。原理としては Windows Service にみる別の資格情報で process を起動する安全な方法な感じです。ただ、この方法をとったとしても application server を利用する場合ほどの security を確保することはできません。また、user の account が "BUILTIN\Administrators" なんかに所属している場合には当然全く意味をなしません。

SQL injection を防ぐもうひとつの方法

ちゃっぴ (tyappi@wankuma.com) — Sun, 11 May 2008 01:01:00 GMT

ちょいと前からですが、断続的に大規模な SQL injection 攻撃が続いています。

よくある対策としては、stored procedure 利用しろ！とか、parameterized query 利用しろ！とか ad-hoc query 利用する場合は sanitizing しろ！とか。望ましい順番は stored procedure > parameterized query > ad-hoc query with sanitizing になるわけですが、stored procedure 以上により望ましい方法があります。

SQL injection って何が問題なんでしょう？

そう、本来は許可されるべきでない user が不正に data へ access できてしまうことが問題なんです。あれ？これってもろに access control の話ですよね？大抵の DBMS には当然 DBMS の access control 機能があります。そう、これを厳密に適用している状態であれば、SQL injection されたところで data に access する段階で確実にはじかれます。また、application 側で対策するよりも遥かに容易に制限を課すことができるのも利点ですね。

でも、一般に DBMS の access control 機能ってそれほど利用されていないじゃないの？と思われる方も多いと思います。これはなぜでしょう？

一つ目の要因として、DB に access する user を分けると resource 消費が増えるというのがあります。利用する DBMS によって異なりますが、connection pooling ができなくなるとか多くの場合 performance 面で不利になる点は否めないでしょう。これが一番の要因になっているようですね。

二つ目は user 管理の問題です。DB に access する user を分けるわけですから、DB もしくは DB で利用する認証 server に user account を作成する必要があります。これを嫌っている人も多いみたいですね。でも、これ自動化するのはそんなに難しくないと思うんだけどなぁ。独自の認証利用している場合が多いと思いますが、その強度・管理面まで考えると正直逆転するんじゃないかと思います。

まあ、そういうこともあって現状では DBMS の access control を利用していることが多いとは言えませんが、より確実な access control 以外にも DB への接続 user を分ける利点があります。

それは、traceability の確保です。DB へ接続する user を共有している場合、当然ですが DB 側ではどの user が行った操作なのかわかりません。これでは監査できているとは言えませんよね。ちゃんとした監査を要求される system では、どの user (個人) が行った操作か？というのが識別できないといけません。User を共有した場合、これを application 側で DB に書き込む処理を追加しなければなりません。これは正直負担が大きいです。では user を分離した場合ではどうなるでしょう？ DBMS 側の機能で要求される監査を実施できることが多いです。いちいちゴリゴリ coding する必要がないので楽になりますね。

まあ、どの方法を選択するかは perfomance, security は当然として、開発費用、運用管理費用等まで考慮する必要があります。DB というととかく perfomance のみに目が行きがちですが、他の要因も検討対象に加え再評価してはいかがでしょうか。

SQL Server 各 edition の CPU 数制限

ちゃっぴ (tyappi@wankuma.com) — Thu, 17 Apr 2008 20:11:00 GMT

SQL Server の processor license は誰もがご存知のように物理 CPU (石) 数で決定しますが、Standard Edition, Express Edition には support する CPU の数が制限されています。

Support される processor 数はどうなるんでしょう？

その回答は下記。

SQL に関する Q&A Best Practices Analyzer、マルチコアプロセッサなど

質問 – ハイパースレッドやデュアルコアテクノロジだけでなく、さらに多くのコア (4 コア、8 コアなど) を搭載したプロセッサのリリースが始まっています。現在、SQL Server 2005 Standard Edition の展開を行うために、マルチコアプロセッサを搭載した新しいサーバーの購入を検討していますが、4 コアのプロセッサを使用する場合、実際に使用できるのは 1 基の物理 CPU のみになるのでしょうか (Standard Edition でサポートされるのは最高で 4 CPU のため)。

回答 – ライセンスやエディションでの CPU のサポート数について、SQL Server ではプロセッサのコア数とは無関係に、物理ソケット (CPU) 数のみが考慮されます。したがって、たとえば SQL Server 2005 Standard Edition が最高で 4 CPU をサポートするという場合、CPU のコア数とは無関係に、4 つの物理 CPU ソケットをサポートすることになります (つまり、4 コアの物理 CPU が 4 基ある場合、展開した Standard Edition が使用できる論理 CPU 数は 16 になります)。また、コア (論理 CPU) 数は 16 でも、必要になるライセンス費用は 16 コア分ではなく、4 物理 CPU 分のみです。SQL Server およびマルチコアの詳細については、microsoft.com/sql/howtobuy/multicore.mspx を参照してください。

ということで、license の count と全く同じが正解です。

NUMA

ちゃっぴ (tyappi@wankuma.com) — Sun, 06 Apr 2008 13:33:00 GMT

最近ようやく Windows 系に復帰する感じです。

で、ちと問題になっているのが dual core Itanium × 4 で構成された SQL server。

数年前、ES7000 とかは扱ったことあるんですが、現在は NUMA というのがありこれが厄介な悪寒。

勉強せねば。

[追記]

[/追記]

なんでも並列化することが高速化につながるわけではない

ちゃっぴ (tyappi@wankuma.com) — Sat, 22 Mar 2008 18:49:00 GMT

ネタ元キングギドラvsやまたのおろち

こちらでは原因が並列化処理に限定されたわけではないですが、一般的な話として並列化を行うことによって高速化することも多いですけど、逆の場合もまた多いです。

並列化して大幅な高速化が望めるのは下記に限定されると思っています。

扱う対象の?resource も並列処理可能
扱う resource 自体に余裕がある

たとえば、CPU が並列処理可能でも一つの resource を共有する場合、結局その resourece 空き待ちが発生するわけで、大して効果がないことも多いです。Physical memory のように random access に強いものならそれなりに効果がありますが、HDD のような sequential access と random access で明らかに処理速度が違うようなものを扱うときには注意が必要だと思っています。下手に並列化することによって、遅くなる可能性が非常に高いと思っています。

小規模な場合には問題になること少ないですが、大規模な場合にはここら辺が問題になることが非常に多いです。

なお、SQL server に関しては consulting service が行っている query tuning の講義が参考になりますね。予算に余裕があったら是非受講してみてください。

Web ではこんなのがあるようですね。

あと、PASSJ?の講義でここら辺やってくれたりしないんですかね？
今度行ってみるか

並列化で最大限の効果を挙げるためには扱う resource を含めた並列化が必要になるので、そこら辺を意識する必要があるでしょう。

DBMS

SQL Server で blocking されている resource を特定する方法

SQL Server で Kerberos 認証を有効にする

SQL injection による Web page 改竄

DB への接続 user を共用する場合でも少しでも脅威を軽減できるように設計しよう

DB への接続 user を共用した場合の client-server 構成での 問題点

SQL injection を防ぐもうひとつの方法

SQL Server 各 edition の CPU 数制限

NUMA

なんでも並列化することが高速化につながるわけではない

DB への接続 user を共用した場合の client-server 構成での問題点