おっちゃんのエンジニア日記

今までエンジニアとして経験してきたことを書いていくブログ

とあるDBAの日常 ~ここが違うよ!DBA~

ブログとしては、ご無沙汰しております。

すがっとです。

 

皆さん、お元気ですか?

お花見の季節になりましたねぇ。

 

さて、今回はタイトルの通り、私がDBAとしてお仕事をしていたとき、

どんな日常を送っていたのか?という内容です。

DBAになる前に自分が抱いていたDBAに対するイメージとのギャップや、

これからDBAを目指したい・興味はあるけどどんな仕事?というのを

身近な目線でお伝えしていけたらと思いますのでお付き合いくださいませ。

まずはじめに

過去に何度か、こんな事を言われたことがあります。

DBA is GOD(DBAは神である)!!

今だから言いましょう。

正直、全然そんな事無いです。

 なんたらマスターみたいな資格が無くてもできますし、

大変なことを積極的にやってるわけでもないです。

障害を積極的に対応してくれてる?いいえ?

仕方なくやってますよ!!だって自分が担当してるんだもん!

みなさんが自分の担当領域に問題があったら必死に対応してるのと

まったく一緒です。

とある一日の流れ

10:00 出社

 のどかに出社をし、監視ツールのモニターを眺め、前日のDBサーバーのリソース状況をチェック。

この時に見ているポイントはこんな感じ:

 ・CPU使用率の変化

 ・ディスクI/Oアクセスの様子

 ・ディスク使用量の変化

 ・メモリ使用状況

 

 今回は↑の事については端折りますが、要は「いつもと変わりないよね?」という確認をしています。

10:30 ~ 13:00くらいまで

 自分の担当しているサーバーの安全点検が終わったら、もうすぐお昼だな、と思いながらプロジェクトの残タスクを確認したり、問い合わせや相談事が来ていないか確認します。

 だいたいこれくらいの時間になると相談が入ってきたりします。

お昼食べて~18:00くらいまで

 案件の仕事を集中的にやりつつ、問い合わせを引きずっていたらその日のうちに解決できるかどうかを判断。

~定時まで

 明日以降の予定を立てつつ、残タスクをチェックしながら後片付け。

 

みたいな感じで一日が終わっていきます。

 

あれ?イメージと違くない?

ええ。僕も最初はそう思いました。ではでは、そのギャップについて解説していきます。

DBの事、めっちゃ詳しいんでしょ?

いいえ?わからないことはググりますよ。

公式のドキュメント見て、わからない単語があればさらにググって。

実際に動かしてみて。開発しているときとまったく変わらないですよ。

夜中でもいつでも対応してくれてるでしょ?

それは皆さん自分が担当してる物に問題があったら責任持って対応するのと同じです。

僕も夜中に対応なんてしたくないですから、そうならないような仕組み作りをするのも仕事の一つです。

毎日忙しそうじゃない?遅くまで仕事してるでしょ?

僕と一緒に仕事をしたことがある人ならわかると思います。

基本的に定時ダッシュです。

残業なんてトラブルが起きた時くらいです。

だって、早く帰りたいもん。

まとめ

最後に僕が言いたいのは、DBAって大変そうなイメージあるけれど、担当している領域が違うだけで

やってることはそんなに皆さんと変わらないです。

データベースって、今後も必要な領域で、もっともっと需要が広がって欲しい。

そんなに難しく構えないで、新しい言語を触ってみる、みたいなノリで触れてみて欲しい。

そうやって、DBAをやってみたい!って思い始める人が増えてくれるといいな、

なんて事を思いつつ、のんびりと毎日を過ごしているすがっとさんです。

 

ではまた!

たまたま見たWAFのログで震えたお話(MS SQLServer)

はじめまして!

いちおう上場企業などでDBAをやっていた すがっと と申します。

はてなデビューしました。

これからはこちらの方で自分がDBAとして経験したことや、

データベースの技術検証した話などを書いていこうと想います。

 

きっかけ

 先日、元同僚とご飯を食べていた時に、「そういや、こんな事があってな」と

この話をしたところ、「それ、LTで話してくださいよー!」と言われまして…。

人前で話をするのが苦手なすがっとさん、とりあえずブログに逃げました。

 

今回は、過去に経験したWAFのログの中でも震えたSQLインジェクションのログから

セキュリティについて考えたお話です。

こんな構成

兎にも角にも構成が見えないとイメージもつかないと思ったので、

当時運用していたサービスの構成をざっくりと絵にしたものがこちらです。

ちなみに、使用しているRDBMSはMS SQLServer 2008R2でした。

 f:id:tetsuwrx:20180825103836p:plain

見つけた!SQLインジェクション

日々の運用ではSQLインジェクションが飛んでくることはそこまで珍しいものではなく、

WAF(Web Application Firewall)で弾かれたものがメールで通知されてくるので何気なく眺めていたところ…

よく見かけるような「' and 1 = 1;'」 みたいなものではなく、

とてつもなく長いSQLが書かれていてメールのログでは途切れてしまう程のものが通知されてきました。

これは何かあってからではマズいということで調べていったところ…

データの抜き取りとはこういうことだったのか

実際の中身は細かく覚えていないのでダイジェストで書くと…

1. xp_cmdshellを使ってWindowsファイヤウォールを停止

2. xp_cmdshellを使って11433ポート(使われていなさそうなポート番号)を開放

3. select文でサーバー名やIPアドレスを取得した結果を、リモートクエリ(openquery)を使って

 外部のDBサーバー(恐らくデータ収集専用DBサーバ)へデータを保存

イメージ的にはこんな感じですね↓

f:id:tetsuwrx:20180825105717p:plain

何が怖かったか

こんな手の凝ったSQLは見たことなかったし、WEBページにデータを表示させたり

DBサーバをクラッシュさせるという目的ではなく、本気でデータを抜きにかかっている事を目的として実行しようとしていたところが怖かったです。

これがもし通っていたら次は何をされるかわからないですからね。

改めて感じたこと

1. xp_cmdshellは危険

SQLServer界隈では有名な話ではあるのですが、SQLの中でOSに対してコマンドを実行できるというものなので、

WEBサービスとして使用しているDBサーバなどでは当然のことながら無効化しておきましょうというものなのですが、

今回の1件で無効化しておいて良かった、と改めて思いました。

2. アプリケーションから接続するユーザーには適切な権限設定を

アプリケーションを動かす上ではinformation_schemaやシステム管理用DBの情報は必要ないはずですので、

見れないようにしておいても実害は無いと思います。

3. openqueryはいろんな意味でやめてほしい

リモートクエリはデータのフローが複雑になるのでできれば使用してほしくないし、

使用しないなら実行できないようにしたいところですね。

 

まとめ

SQLインジェクションって、実際に見てみると思いもよらないクエリが書いてあったりして、

「これを防ぐためには…」というような考えで見ていくと結構勉強になったりする事もあるので、

「なんかいつもと違う!」という第六感を働かせるためにも、その「いつも」がどういうログが飛んでくるか見ておくと、

あなたもニュータイプなDBAになれるかもしれません ( m9`・ω・´)

 

せっかく記事に起したものでもあるので、どこかでお話できたら良いなー、なんて…(ボソボソ

その時は、震えながら話していると思うので温かい目で見守ってあげてください。