2006年04月
2006年04月30日すでに誰かが絶対に書いているはずとは思ったのですが、 探すよりも書いた方が早そうだったので、 livedoor ブログの生ログを取得する perl スクリプトを 書いてみました。 ついでに、デザインをカスタマイズしたときの、 スタイルシート（CSS）やHTMLのテンプレートも取得できます。 例えば、
livedoor.pl gcd raw_log 10 log.csv
などと実行すれば、10 ページ分 (200行) の生ログを、 CSV 形式でファイル「log.csv」に保存できます。 また、
livedoor.pl gcd index_tmpl index.html
などと実行すれば、インデックスページのHTMLテンプレートを、 ファイル「index.html」に保存できます。 第一引数「gcd」の部分には、 ブログのアカウント名 (スクリプトの先頭部分で定義しています) を 指定してください。 私の場合、 「GCD 日記」と 「仙石浩明CTO の日記」の 二つのブログアカウントがあるので、 それぞれ「gcd」と「klab」という名前で定義しています。
余談ですが、二つのブログを書いているのは、 個人用と会社用とを区別しようというわけではありません。 もともと私のなかでは趣味と仕事の境界線が曖昧なので、 個人と会社でブログを区別しようとしても混ざってしまうでしょうから、 区別することに意味があるとは思えません。 じゃ、なぜ二つのブログなのかと言えば、 「GCD 日記」のほうが よりメモ的でネタを蓄えておき、ある程度考えがまとまったものを 「仙石浩明CTO の日記」へ 書こう、というのが そもそもの意図でした。
やっつけ仕事なので、突っ込みどころ満載(^^;) のスクリプトだとは思いますが、 livedoorブログをお使いの方はご利用頂ければ幸いです。 もちろん、ご利用の際は先頭部分のユーザID & パスワード等を 適宜修正してください。 また、スクリプト中で日本語を使っているので、 このスクリプトは EUC-JP で保存する必要があります。
livedoor.pl (livedoor blog 生ログ & CSS/テンプレート 取得スクリプト)
#!/usr/bin/perl
use LWP::UserAgent;
use HTTP::Request::Common;
use CGI qw/unescapeHTML/;
%blogs = (
"gcd" => {
"User" => "hiroaki_sengoku",
"Pass" => "xxxxxxxx",
"BlogID" => 1600549,
"ID" => 11111,
"PageID" => 22222,
},
"klab" => {
"User" => "klab_sengoku",
"Pass" => "yyyyyyyy",
"BlogID" => 1631449,
"ID" => 33333,
"PageID" => 44444,
},
);
&help unless $_ = shift;
if (my $blog = $blogs{$_}) {
$User = $$blog{"User"};
$Pass = $$blog{"Pass"};
$BlogID = $$blog{"BlogID"};
$ID = $$blog{"ID"};
$PageID = $$blog{"PageID"};
} else {
&help;
}
$ua = new LWP::UserAgent;
$ua->agent("Mozilla/5.0 (Windows; U; Windows NT 5.1; ja)");
$ua->env_proxy();
$ua->cookie_jar( {} );
my $res = $ua->request(POST "http://member.livedoor.com/login/index",
[ "livedoor_id" => $User, "PASSWORD" => $Pass,
".next" => "", ".sv" => "" ]);
while (my $type = shift) {
if ($type eq "css" || $type eq "index_tmpl" || $type eq "article_tmpl" ||
$type eq "category_tmpl" || $type eq "monthly_tmpl") {
my $file = shift;
open(OUT, ">$file") || die;
my $url = "http://cms.blog.livedoor.com/cms/design/edit"
. "?tmpl=$type&blog_id=$BlogID&id=$ID";
my $req = new HTTP::Request GET => $url;
my $res = $ua->request($req);
if ($res->content =~
/\<textarea .*name=\"content\" [^\>]*\>([^\<]+)\<\/textarea\>/) {
my $content = unescapeHTML($1);
$content =~ s/\r\n/\n/g;
print OUT $content, "\n";
}
close(OUT);
} elsif ($type eq "raw_log") {
my $npage = shift;
($npage =~ m/^\d+$/ && $npage >= 1) || &help;
my $file = shift;
open(OUT, ">$file") || die;
my $url = "http://analyzer.livedoor.com/log/raw?page_id=$PageID";
my $prepat = '\<td\b[^\>]*\>\<strong\>\<small\>';
my $postpat = '\<\/small\>\<\/strong\>\<\/td\b[^\>]*\>';
for (my $i=1; $i <= $npage; $i++) {
my $req = new HTTP::Request GET => "$url&p=$i";
my $res = $ua->request($req);
my $datepat = '\d\d\d\d\-\d\d\-\d\d \d\d\:\d\d\:\d\d';
my $date;
for (split(/(\<small\>$datepat\<\/small\>)/, $res->content)) {
if (/^\<small\>($datepat)\<\/small\>$/) {
$date = $1;
} elsif (/^\<\/th\>\s*\<\/tr\>\s*/) {
my @record;
for (split(/\<\/tr\>\s*/, $')) {
my $column;
if (/$prepat(.*)$postpat/o) {
if ($1 eq 'URL') {
$column = 0;
} elsif ($1 eq 'リファラ') {
$column = 1;
} elsif ($1 eq 'ブラウザ') {
$column = 2;
} elsif ($1 eq 'リモートホスト') {
$column = 3;
} else {
die "Unknown column: $_\n";
}
}
if (/\<td\b[^\>]*\>\<small\>(.*)\<\/small\>\<\/td\b[^\>]*\>/){
$_ = $1;
s/\<\/?a\b[^\>]*\>//g;
if (/,/) {
s/\"/\"\"/g;
$_ = "\"$_\"";
}
$record[$column] = $_;
} elsif (/^\<\/table\>/) {
last;
} elsif (! /^\<tr\>\s*\<th\b[^\>]*\>/) {
die "Unknown format: $_\n";
}
}
print OUT $date, ",", join(',', @record), "\r\n";
}
}
}
close(OUT);
} else {
&help;
}
}
exit 0;
sub help {
print "Usage livedoor <blog> <opt>...\nblog: ",
join("\n ", keys %blogs), "\n",
'opt: css <file>
index_tmpl <file>
article_tmpl <file>
category_tmpl <file>
monthly_tmpl <file>
raw_log <n> <file>
';
exit 1;
}
2006年04月29日弊社の面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法。 今までお話ししてきたことをいったんまとめてみます。
- (1) 高い技術力って例えばどんなことですか？
- 志望動機が「技術を学びたい」なのに、 肝心のその技術がどういうものかイメージできていない、 言い換えれば自分が何をしたいのか実は分かっていない、 これはかなり問題ですよね？
- (2) 何か質問はありませんか？
- 面接を受けに来て、なにも質問しようとしない人がいます。 分かっていないのに分かったつもりになってしまう、 これは技術者にとって致命的なことです。 どこまでも自分が分かっていないことを自覚し、 探求し続ける習慣が無ければ、スキルアップは覚束ないでしょう。
- (3) 前職でいくらもらっていましたか？
- 前職給に基づいて給与を決めるため、というわけでは決してなく、 KLab の給与体系にスムーズに移行できるか判断するためです。
今回の質問は、
生活するために働かねばならない、ということが仮になかったとしたら、
仮に、一週間何をしてもいい、と言われたら、何をしますか？
なぜこんな質問をするかと言えば、自分は本当は何をしたいのか 考えてもらいたいからです。
自分が何をしたいか？ そんなことは分かっているに決まっているじゃないか、 お金に困らないなら好きなことをするさ、と多くの人は言うでしょう。
じゃ、好きなことって何ですか？
仕事しなくてもいいのなら、あれもしたい、これもしたい、...
その中で一番やりたいのは何ですか？
一日中、寝続けたい。
浴びるほど酒を飲みたい。
何も考えずにぼーっとしていたい。
...
まあ好きにやっててください。(^^;)
もちろん気分転換は必要なので、
時にはハメを外すことも必要でしょう。
でも、何かをやっているからこその気分転換ですよね。
年がら年中、気分転換し続けるわけにはいきませんよね。
だから〜、普段は嫌な仕事をやってて、 おまけに残業続きで忙しくて忙しくて、 たまに休日があっても疲れているから何もする気が起きず、 あ〜 仕事しなくてもいいなら好きなことができるのに〜
いえ、だからその「好きなこと」ってなんでしょう？
というのが質問なのですが... (-_-;)
一生の時間のうちのかなりの時間を仕事に費やすのですから、 一生かけて取り組みたいと思うようなことをすべきだと思うのです。 好きなことをやっててお金がもらえれば苦労はしない、と多くの人は言うでしょう。 でも、本当に一生かけてもやりたいほど好きなことってありますか？
もしあるなら、その「好きなこと」をやってても生活できない と判断するのはなぜでしょう？ 一生かける覚悟があるなら、大抵のことは成し遂げられるでしょう。 嫌々仕事をしたって、好きでやってる人に勝てるはずはありません。 鶏口となるも牛後となるなかれ、 好きなことをしよう。
もしそれほど「好きなこと」がないのなら、なぜ探さないのでしょう？
一生かけて嫌々仕事をするのでしょうか。何のために？
生活のため、というのは自分自身への いいわけ なのでは？
今日から五月連休ですね。
会社によっては 9 連休のところもあるとか。
あなたは何をしますか？
2006年04月28日遅ればせながら Haskell で遊んでいます。 KLab の技術者の中にも、手続き型言語の世界に どっぷりつかっていて他の世界を知らない人は いるので、 tech ML (技術者向の KLab 社内メーリングリスト) で Haskell の紹介をしてみました。
Subject: [tech:8480] Haskell 仙石です。 唐突ですが、Haskell って知ってますか？ 私は面接した人に教えてもらった ;) のですが、最近流行りの関数型言語です。 ブログを見てると、あちこちで話題になっていますね。 入門用のページ: やさしい Haskell 入門 (バージョン98) http://www.sampou.org/haskell/tutorial-j/index.html 「やさしい」と書いてますが、関数型言語を初めて学ぼうとする人には敷居が 高いかも知れません。まずは簡単な Haskell プログラムを見てみましょう。 ------------------------------------------------------------------------ guusuu x | x `mod` 2 == 0 = True | otherwise = False ------------------------------------------------------------------------ これは guusuu(x) という関数の定義です。 x を 2 で割った余りが 0 ならば、guusuu(x) = True それ以外ならば、 guusuu(x) = False と読みます。簡単ですね？ ;) 早速実行してみましょう。 上記プログラムを test.hs というファイル名で保存しておいて、 Haskell 処理系である ghci コマンドを実行します。 ------------------------------------------------------------------------ senri:/home/sengoku/tmp % ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Prelude> :load test.hs Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main> guusuu 2 True *Main> guusuu 7 False *Main> ------------------------------------------------------------------------ 「:load test.hs」というのが「test.hs」を読み込むためのコマンドです。 「guusuu 2」を実行すると、guusuu(2) の値である True が出力されていますね。 これだけだと、あまり能がないので、偶数列を表示させてみましょうか。 ------------------------------------------------------------------------ *Main> take 10 [1,2..] [1,2,3,4,5,6,7,8,9,10] *Main> take 10 [x|x <- [1,2..], guusuu x] [2,4,6,8,10,12,14,16,18,20] ------------------------------------------------------------------------ 「take 10」というのはその後ろのリストの先頭 10 個の要素を取り出す関数で す。「[1,2..]」というのは自然数列のリストですね。take を使わずに [1,2..] を表示させようとすると、無限に自然数列を表示します。 ------------------------------------------------------------------------ *Main> [1,2..] [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, ...無限に続く... ------------------------------------------------------------------------ 途中で止めるには control-C を押します。 さて、 [x|x <- [1,2..], guusuu x] という書き方は、グラフ理論の輪講に参加している人や、述語論理を学んだこと のある人にはおなじみの書き方じゃないでしょうか。自然数列の中で、 述語 guusuu(x) が True であるような x のみ取り出したリスト、という意味です。 じゃ、このプログラムはどうでしょう？ ------------------------------------------------------------------------ hurui [] = [] hurui (top:rest) = top:(hurui [x|x <- rest, x `mod` top /= 0]) ------------------------------------------------------------------------ 関数 hurui は引数としてリストをとります。「[]」は空リストです。つまり要 素が何もないリストですね。引数が空リストならば hurui [] の値も [] です。 引数が [] でない場合は、引数のリストを、先頭 top と残り rest に分解します。 例えば hurui [3,5,9,11,13] の場合、top が 3 で rest が [5,9,11,13] です。 # このあたり、lisp を知っている人にはおなじみの概念ですね 次に top と (hurui [x|x <- rest, x `mod` top /= 0]) をつなげたリストを、 hurui の値として返します。「:」がリストを作るための演算子です。 # lisp で言うところの cons と言えば lisp を知っている人には簡単ですね では (hurui [x|x <- rest, x `mod` top /= 0]) とは何でしょう？ 「/=」というのは等しくない、という演算子です。C で言うところの「!=」です ね。つまり、rest の中で「x `mod` top /= 0」が True になるものを取り出し たリストを求め、これを引数として hurui を再帰呼出しして求めたリスト、と いうことになります。 top が 3 で rest が [5,9,11,13] でしたから、3 で割って余りが 0 でない (つまり 3 で割り切れない) もののリスト、ということになります。9 以外は 3 で割り切れないので [5,11,13] ですね。これを引数として hurui に与えます。 つまり、3 (top の値) と hurui [5,11,13] の値をつなげたリストが答になりま す。 同様に hurui [5,11,13] の値は、5 と hurui [11,13] (11 も 13 も 5 では割 り切れないから) の値をつなげたリストですね。というのをどんどん再帰的に繰 り返すと、hurui [3,5,9,11,13] の値は [3,5,11,13] になります。実際に試し てみましょう: ------------------------------------------------------------------------ *Main> hurui [3,5,9,11,13] [3,5,11,13] ------------------------------------------------------------------------ スルドイ人はすでに分かっていると思いますが、 この関数は「エラトステネスの篩」です。したがって、 ------------------------------------------------------------------------ *Main> take 20 (2:hurui [3,5..]) [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71] ------------------------------------------------------------------------ などと実行することにより、20個の素数を列挙することができました。 どうです？ 面白いでしょう？ 関数型言語を知っている人は、たぶん Haskell もすぐ使いこなすことができる と思いますし、関数型言語を知らない人は、ぜひこの機会に知ることをオススメ します。なぜなら関数型言語を知らないプログラマってプログラミング言語の世 界の半分しか知らないわけで、Haskell を学ぶことにより世界が大きく広がると 思うからです。 関数型言語を初めて学ぶ人は、まずは 入門Haskell―はじめて学ぶ関数型言語 向井 淳 (著) あたりを読むのがいいかも知れません。私の机の上に置いておくので、興味ある かたはどーぞ (先着一名様限定)。 この本は、副題にもあるように関数型言語を初めて学ぶ人向けに書かれているの で、イマイチ本質を外しているんですよねぇ... だから本音ではオススメな本で はない ;-) のですが、関数型言語へのとっかかりとしてはよいのかも知れません。 #13425 仙石 浩明 http://www.gcd.org/sengoku/ Hiroaki Sengoku <sengoku@gcd.org>
このメールに一番早く反応したのは、KLab の開発に参加いただいている 協力会社 H 社の CTO の T さんでした。 T さんとはご無沙汰していたのですが、 彼も私と同様に Haskell で遊んでいたことが分かって、 さすがと思った次第。
# 協力会社さんに負けずに頑張ってね ＞ KLab 社員
ご無沙汰しております。 H 社の T です。 Hiroaki Sengoku wrote: > 唐突ですが、Haskell って知ってますか？ なぜか私も、今月の頭ぐらいにとあるブログで知って（YAPC::Asia 2006のPugs関連 のエントリだったような…） > 入門Haskell―はじめて学ぶ関数型言語 > 向井 淳 (著) を購入して、ひそやかに楽しんでおりました。 そして、いやあ、これは、自分だけ楽しんでいるには余りにももったいないので、 （H社内の）勉強会のネタにしようと宣言していた矢先に、投稿を拝見しまして、 つい反応してしまいました。
KLab でも Haskell 勉強会やりましょう!
2006年04月27日弊社の面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法の三回目。
多くの企業同様、KLab の面接でも「前職でいくらもらっていたか」は 当然のように質問します。 が、それは前職給に基づいて給与を決めるため、というわけでは決してなく、 KLab の給与体系にスムーズに移行できるか判断するためです。
世間一般的には、まだまだ年功序列の給与体系のようで、 年齢が高くなるとどうしても給料が高くなる傾向にあります。 例えば先日面接した人は、 5年前から成長が止まっているように見受けられました。 5年間さしたる進歩もないのに、 給料のみが上がってしまっている、 いまさら 5年前の給料で雇うのも無理な話ですし、 5年間成長が止まっていた人が転職で突然伸び始める可能性は 低いと判断せざるを得なかったので 不採用となりました。
もちろん「成長が止まっていた」というのは私から見た主観であって、 当人からすれば 5年間の間にいろいろ経験を積んできたと思っているのでしょう。 実際、職務経歴書にはいろいろなプロジェクトが列挙してありました。 しかし、どのプロジェクトについても別段思い入れがあったわけでもないようで、 「印象深かったプロジェクトを、一つだけでいいので事細かに詳しく説明して下さい」と お願いしても、どういう製品を開発したのか説明するだけだったのです。 私としては、どう言う点を困難と感じ、どのように工夫し、何を学んだか等々を 聞きたかったのですが、 ついにそういう話は聞けずじまいでした。
「給与の経路依存性と二極化」から引用:
キャリアって「何をやったことがあるか」もあるけど 「前職でいくらもらっていたか」というのも大きいんだよね． 誰も絶対的な給与水準の感覚なんてないから， どうしても「前職でいくらもらってましたか？」というのが重要な基準となる．
そうでしょうか？ KLab には KLab の「絶対的な給与水準の感覚」があります。 もちろん面接の短い時間で、 どのくらいの能力を持っている人か正確に把握することは困難ですが、 実際に 3ヶ月〜半年も一緒に働けば、 同じ職種の誰より上で誰より下の実力、 なんてのは誰の目にも明らかになるものだと思います。 だから KLab で前職給を聞くのは、 給与を決める際の基準にしようというわけでは決してなく、 KLab の給与体系にソフトランディングさせることが可能か判断するためです。
同ページから再度引用:
人事がまともなら移行期間は前職の給与だけど， だんだんと企業内部の給与水準に収束させる訳だけど， 誰かの給与を下げるためには結構まじめに説明可能な管理をする必要があって， なかなか大変だったりする． そうやって経路依存的な問題で所得が二極化しているのに， それを実力主義だとか抜かしたら大きな間違いだ．
給与を下げるのは実際大変です。しかし、 実力主義を標榜する以上、 成長にともなって給料が大幅に上がる人が出てくる一方で、 変化に適応できずに給料が下がる人が出てくることは避けられないことです。 「結構まじめに」どころか大変な労力をかけて話し合い、 お互い納得した上で降格を実施しています。
確かに面接では把握し切れなかった能力の低さが入社後に発覚し、 実力と給与のミスマッチが生じるケースも無いわけではありませんが、 不幸にもそういうケースが起きてしまったときは誠心誠意全力で対応し 是正するよう努めています。 お互い納得しあうまで何時間も話し込むこともあるわけですが、 それは実力主義を維持するために当然払うべきコストだと思っています。
2006年04月26日前回は、リレーサーバへのアクセスは https なので、 stone 以外のソフトウェアも使えるというお話をしました。 一例として OpenSSL 付属の s_client を使ってみたわけですが、 https を扱うクライアントソフトウェアといえば普通は WWW ブラウザですね。 というわけで今回は WWW ブラウザでアクセスする方法を紹介します。
ブラウザで https://relay.klab.org/ をアクセスすると、 次のようなリクエストヘッダが SSL で暗号化されて、 リレーサーバ relay.klab.org へ送信されます。
GET / HTTP/1.1 Host: relay.klab.org User-Agent: Mozilla/5.0 ... （空行）
リレーサーバは SSL クライアント認証を要求するので、 ブラウザは証明書ストアにある SSL クライアント証明書を使用して 認証を行ないます。 利用できる SSL クライアント証明書が複数ある場合は、 ブラウザが証明書の選択画面をユーザに提示し、ユーザが選ぶことになります。
リクエストヘッダを受け取ったリレーサーバは、 同じ証明書を持つ relayagent からの接続が存在すれば、 その relayagent との通信を確立させるのでした (VPN-Warp 入門編 (3)を参照してください)。
つまりリクエストヘッダに続いて送られるデータがポートフォワード先に送信され、 ポートフォワード先から返されたデータが、ブラウザに届きます。
が、ちょっと待ってください。 前回までに説明してきたポートフォワードの場合、 リクエストヘッダ (のようなもの) は stone が挿入した、 いわばダミーのリクエストヘッダでした。 ダミーですから、リクエストヘッダ (のようなもの) は ポートフォワード先に送信する必要がなかったのですが、 ブラウザを使う場合は、リクエストヘッダはホンモノです。 リクエストヘッダも込みでポートフォワード先の WWW サーバに送る必要があります。
VPN-Warp 入門編 (3)で 説明した relayagent の設定では、 「-n」オプション (relayagent をポートフォワーダとして使う、という意味) を 指定したことを覚えていますでしょうか？ 実は、この「-n」オプションというのが、 relayagent にリクエストヘッダ (のようなもの) を取り除くことを指示する オプションなのです。 だから「-n」オプションを指定しなければ、 リクエストヘッダも含めてポートフォワード先 (つまり WWW サーバ) に送られます。
例えば relayagent の設定ファイルは次のような感じになります:
-k private.pem -c cert.pem relay.klab.org:443 intra:80
intra:80 がポートフォワード先の WWW サーバですね。 このような設定で relayagent を実行しておくことにより、 ブラウザが https://relay.klab.org/ へアクセスすると、 リクエストヘッダ込みで intra:80 へアクセスが行なわれます。
これで問題なくブラウザで intra:80 へアクセスできる...
場合もあるとは思いますが、
二点ほど注意すべき点があります。
- 「https」と「http」の違い
- ホスト名の違い
少々ややこしい問題ですので、次回まわしにしましょう。
2006年04月25日弊社の面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法の二回目。
面接を受けに来て、なにも質問しようとしない人がいます。 面接を受けに来た人(応募者)にとっては、 初めての会社であるわけで、 その会社については知らないことだらけなはずです。 それなのに一度も応募者の側から質問しようとしない場合は、 面接を終了する前に、 「何か質問はありませんか？」という質問をすることになります。 それでも何も質問してもらえないのは、 応募者の関心度の順に
- その会社に興味がない
- 興味はあるのだけど、当座知りたいことは分かったので満足
- 知りたいことはまだあるのだけど、質問できない
という理由が考えられるでしょう。 (1) は、面接官が応募者に対して会社の魅力を充分に説明できなかった、 ということなので、反省すべきは応募者ではなくて面接官(つまり私)のほうですね。 なので、ここでは (2) と (3) についてのみ考えます。
まず (2) ですが、面接はせいぜい 1時間、長くても 2時間程度なわけで、 そんな短い時間でどれだけのことが分かるというのでしょう？
蛇足ですが、私がケイ・ラボラトリー (KLab の旧社名) の立ち上げに 参加するときに受けた面接 (つまり私が応募者の立場だった最後の面接) は、 話が盛り上がって話し込み、気付いたときには 6 時間が経過していました。 ここまで長いと、非常識かも知れませんね。(^^;)
分かっていないのに分かったつもりになってしまう、 これは技術者にとって致命的なことです。 どこまでも自分が分かっていないことを自覚し、 探求し続ける習慣が無ければ、スキルアップは覚束ないでしょう。
したがって面接官としては、この応募者には「伸びしろ」がもうあまりない、 つまり現状のスキル以上のものは期待しにくいと判断せざるを得ません。 現在のスキルのままで活躍して頂けると判断する場合は採用しますし、 そうでない場合は不採用となります。
一方 (3) は、技術者としては可能性があるが、コミュニケーション能力が低い、 という場合です。 もちろんコミュニケーションというのは双方向のものなので、 質問しにくい雰囲気にしてしまった 面接官の側に非がある可能性も否めないのですが、 質問しやすい環境でないと質問できないというのも困りものです。
とはいえ、技術と違ってコミュニケーション力は歳をとってからでも習得できます。 コミュニケーション能力が皆無でも、技術者としての素質があるかたには 是非入社して頂きたいですし、 実際面接時にコミュニケーション能力がゼロだった人 (面接の時、ほとんど話すことができなかった) が 入社後大活躍している例もあります。 もちろん仕事を円滑に進めるにはコミュニケーション力が高い方が いいに決まってますので、 例えば
質問力―話し上手はここがちがう
齋藤 孝 (著)
筑摩書房 ; ISBN: 4480816267 ; (2003/03)
などを読んで「質問する力」を伸ばしていって欲しいと思っています。
2006年04月23日創業から 6年、KLab は大きく発展しました。5人で始めた会社がもうすぐ200人に達する勢いです。 昨年 9月には 子会社 KLabセキュリティを設立し、 セキュリティ分野への本格進出を開始しました。 でも私にとって会社の発展以上に重要なのは、 KLabグループの発展にあわせて 私自身も大きく変わることができたということであり、 また一緒に働く技術者たちも大きく成長したという点です。
もちろん、技術者が成長すればそれだけでいい、 というほど会社は単純なものではありませんが、 会社というものは、役員が3人いたら3人、5人いたら5人が皆違うタイプで、 それぞれの立場から会社のあるべき姿を提案し、 それらをミックスして一番いい会社を創るべきだと思います。 私は技術者だから技術者サイドから会社のあるべき姿をいつも考えています。
私は KLabグループを、これからももっと 「技術者の成長にとって一番役に立つ会社」 「技術者が自ら伸びていくことができる会社」にしたいと思っています。 そして、技術者達が KLabグループを踏み台にして次のステップに進むのもいいし、 KLabグループに残って、KLabグループの将来に貢献してくれてもいい。
そこに一番重きをおきたい。
その為にこだわっていることを3つご紹介します。
面白いことは許可します
「コスト的にどうかな？」と思うことでも、 新しいことであれば積極的にやっていきたいと考えています。 「トップの理解がない」「上司の説得が大変」という技術者の話をよく耳にしますが、 KLabグループでは そんなことはありえません。それは、私が上司だからです。 実際に言い出しっぺは私自身が一番多くて、 メンバーから「こんな無茶しないで下さい」と言われますが・・・。 上司を止めることはあっても、止められることはない。 技術者にとって、積極的にやりたいことがやれる、 挑戦できる環境です。
さらに、現在の業務とは直接関係ないことにもどんどん挑戦してもらうため、 勤務時間の10%以内であれば上司の許可を得ずに何をやってもいいという 「どぶろく制度」を作りました。 ある程度メドがつくまでは「こっそり」技術を仕込んでもらって、 もしうまくいったら発表してもらってみんなで事業化を考える。 モノにならなかったとしても構わない、 失敗を恐れず挑戦する意欲を大切にしたいと思います。
いかに高負荷に耐えうるサーバを作ることができるか、 いかに経済的に運用することができるか、 というクラスタリングサーバの研究開発は、 今でこそ KLab の事業の柱の一つとなっていますが、 最初はケータイJavaアプリを作る合間に「こっそり」仕込んだ技術だったのです。 業務とは直接関係ないことだったが好きだからとやってるうちに、 いつのまにか KLab のコアコンピタンスになってしまったわけで、 「どぶろく」精神の典型例と言えるでしょう。
また、セキュリティ分野への進出も、 最初のきっかけは趣味で作ったプログラムでした。 このあたりの経緯は、 「なぜケータイ・コンテンツ開発から、セキュリティへ転身したのか？」に書いています。
今までの事業領域は無視してもらってもかまいません。 IT 以外は微妙ですが、「技術」という名がつけば何でも OK です。 「そこはお前のやることじゃない」と言われることはありません。 私が CTO である以上、 やる気があるなら次々に新しい研究開発ができます。 そして、そこで積み重ねた技術力次第で CTO も目指せます。 それが KLab という会社なのです。
技術者の上司は技術者であるべきです
これは私のこだわりで、ずっと言い続けていることです。 技術者が「技術だけでどこまでも上っていける会社」 「自分のキャリアパスを明確に描ける会社」それが理想。 出世すると技術がなくなったり、上司がいつの間にか技術者でなくなると、 「いずれは技術を捨てなければならない」と思ってしまう。それはありえない。
事業分野の広がりにともない現在は事業部制をしいていますが、 本当に技術が好き、という人のためには、 研究部門である Kラボラトリー (旧社名を引き継いでいます) があり、 私が直轄しています。 また、KLabセキュリティは今のところセキュリティ分野に特化しているので 機能組織となっており、技術部門は私が統括しています。
さらに、上司が単に技術者であるというだけでなく、 上司が部下を技術者としての実力で評価できるということを重視しています。 これは、「彼は、このあたりの分野が優れている」などという概要評価ではなく、 例えばソースコードまで見て、優れている点を具体的に評価でき、 さらに改善ポイントもアドバイスできるということです。
一般の会社では、過去の功労者が上にいる企業が多いようですが、 でも彼らは、過去の技術に関しては優れていても、 必ずしも今の技術に関して精通しているとは言えません。 KLabグループの場合は、 これからの技術で部下を引っ張っていける人でないと上司にはしません。 上司でも、新しい考え方や新しいパラダイムに適応できない人は、 だんだん退いてもらうことになります。
世の中的には、上流工程を重要な仕事、 下流工程を単純労働と捉える見方があります。 下流は新人がやる仕事と見なされ、 プログラミングをほとんど経験していない人がプログラマーの上司だったりする。 これではマトモな評価ができるはずはありません。 下流には下流なりの難しさがあり、 下流の得意な人たちも、上流と同様に評価されるべきです。 KLabグループには、上流が得意な上長と下流が得意な上長の両方がいますので、 下流だから上流より地位が下、ということは全くありません。
KLabグループは真の実力主義・能力主義の会社です
成果主義じゃなくて実力主義・能力主義。 どれだけ能力を持っているか、ポテンシャルも含めたところで評価します。 そして能力がある人はドンドン抜擢。能力が開花した時点で、 いきなり倍の給与にしてもいい。 後から来た人が上司を追い抜くのは日常茶飯事です。
多くの会社は成果主義に走りがちです。 それは上司が技術をわかっておらず、技術者をきちんと評価出来ないからです。 部下のやっていることが技術的にどこまで凄いのかを、 評価できないから数字で出るものを信じるしかなく、 「より利益(率)の高いものをやったか？」 ということがメインの指標になってしまいます。 技術というより「いかにコストダウンするか？」 「いかに外注をいじめて安く作るか」 が注力ポイントになってしまい、 技術以外の方向にベクトルが向いてしまう。 そんな会社にはなりたくないし、したくない。
直接成果に結びつかないかもしれないが、新しい知識を貪欲に吸収し、 新しいことをドンドン考え、 自分の考えていることを積極的に発表して皆の役に立つ。 それを重視したいと考えています。 研究開発は会社の中ではコストセンター。 どのみちコストなんだから、お金で換算したくない。 その人の能力・実力で評価したい。 だからトップに技術者がいなければならないし、 技術者の立場から、他の役員と闘うことこそが CTO (最高技術責任者) の役割だと思っています。
取締役 CTO
Kラボラトリー 所長
仙石浩明
KLabセキュリティ株式会社
取締役 CTO
技術本部 本部長
仙石浩明
2006年04月22日この時期、KLab と KLabセキュリティは 上半期 (9月〜2月) の評価面談の季節です。 私は KLab の研究部門である Kラボラトリー (旧社名をとって名付けました) と、 KLabセキュリティの技術本部を担当しています。 昨日は、私の直接の部下の中で一番若い H さんの面談を行ないました。
H さんは昨年の新卒入社なので、まだまだ学ぶべきことはたくさんあるわけですが、 人一倍技術が好きなので、私としても大変期待しています。 いまは、いろんなこと (気配りとか、会社の業績とか) を気にするより、 好きなことを自由に学び、伸び伸びと育って欲しい、と思っています。
彼に話したのはこんなことです:
一点注意してほしい点をあげるとすれば、 様々な技術に関心を持つ際に、強弱のメリハリをつけることを意識する、 という点です。 WWWで公開される情報がどんどん充実していく昨今、 どのような技術でもかなり奥深いところまで WWW で手軽に入手できるように なっています。 このこと自体は素晴らしいことなのですが、 入手が手軽に可能ということが、 分かったつもりに陥るリスクを増やしているわけで、 この罠に陥らないよう注意してください。
特に関心を持った分野、たとえばベイズ理論やオートマトン理論などは、 通りいっぺんの理解にとどまらず、とことんまで勉強してやる、 くらいの意気込みで挑戦してほしいと思っています。
WWW の普及によって、広く浅く学ぶことは格段に容易になりました。 広い視野を持つことはとても大切なことなのですが、 各分野それぞれについて自身がどのくらいのレベルまで学べたか把握していないと、 ほんの表層をかすっただけで満足してしまいかねません。
だから、どんな分野でも、どんなに狭いピンポイントでもいいから 深く深く学ぶ経験が重要だと思うのです。 深く学べば学ぶほど、その深さが基準となって、 その他の分野への理解がどのレベルまで到達したか、 より正確に把握できるものでしょう。
浅くしか学んだことがなければ、その浅さがその人の限界になります。 なにを学んだとしても、自身がどのレベルまで理解できているのか、 自身が理解できていない深淵がどれだけ深いものなのか、 永遠に知ることはないでしょう。
だから、特に若いうちは、とことんまで学んでみて欲しいのです。 H さんには短期的な目標設定として、 古典的な教科書一冊を完全理解することを勧めました:
なにかひとつでいいので、半期かけてとことん学んでみてください。 ひとつの分野をどこまでも深掘りする、ということを一度でも経験した人は、 興味の対象がいろいろ移り変わっても、 分かったつもり状態に陥りにくいものです。 WWW上での学習だと、深堀する以前に興味が発散してしまうリスクがあるので、 評価が確立した古典的な教科書を一冊、完全理解に達するまで読み込む、 といった勉強方法のほうがいいかもしれません。
どんな分野の教科書でもいいと思いますが、 一例として私が学生時代に学んだ「古典的な教科書」を紹介しました:
Switching and Finite Automata Theory
Zvi Kohavi
McGraw-Hill Education ; ISBN: 0070993874 ; (1979/03/01)
27年前の本です！ 秒進分歩ともいわれる技術革新のスピードの中で、 1/4世紀以上昔の本が今でも通用するのですから、愉快じゃありませんか。
追記:
「やめるまではがんばりまっせ」から引用:
なんでかというと、結局わしは、会社のためとか、自分の給料を上げるためだけに仕事しているつもりはないからなのです。自分の実力のために、今吸収できるべきことは全て吸収し、機が熟したら、どこにでも飛び出せるようにしておこう、と思っているからです。だから、今は評価がなかろうがなんだろうが、とにかくやるべきことをバシバシこなさなきゃイカンと思っているのです。
その通りですね。 若いときは若いときしかできないことをすべきだと思うのです。 会社がどうなろうと、 スキルさえ身につければ技術者は勝ち残れるのですから。
2006年04月21日前回は、VPN-Warp をポートフォワーダとして使う場合の、 基本的な設定方法について説明しました。 ローカルホストの 8080番ポートを、 リモートの intra:10080 へフォワードする場合に、 ローカルホストで stone を走らせる方法について説明したわけですが、 stone はもともと VPN-Warp 専用のソフトウェアというわけでは決してなく、 stone は汎用リピータです。
つまり stone を使わなくても、 https リクエストをリレーサーバに送信することができるソフトウェアなら なんでも使うことができます。
試しに OpenSSL 付属の s_client コマンドを使ってみましょう:
% s_client -cert relay,10020-cert.pem -key relay,10020-priv.pem -connect relay.klab.org:443 CONNECTED(00000003) ... subject=/C=JP/postalCode=106-6122/ST=Tokyo/L=Minato-ku/streetAddress=6-10-1 Roppongi/streetAddress=Roppongi-Hills Mori-Tower 22F/O=K Laboratory Co.,Ltd/OU=HTTP/OU=InstantSSL/CN=relay.klab.org ... --- GET / HTTP/1.1 HTTP/1.1 200 OK :irc.klab.org NOTICE AUTH :*** Looking up your hostname... :irc.klab.org NOTICE AUTH :*** Found your hostname
最初の行の s_client コマンドの実行と、 後ろの方の「GET / HTTP/1.1」および続く改行二回が手で入力した部分で、 あとは s_client コマンドの実行結果です。 クライアント認証を行なうため、s_client の引数に証明書の
- 公開鍵 (-cert オプション)
- relay,10020-cert.pem
- 秘密鍵 (-key オプション)
- relay,10020-priv.pem
を指定しています。s_client は SSL 接続した後、サーバ証明書の内容などが、 どばっと出力されますが、その後「---」を表示してセッションが確立します。
そして、リクエストヘッダ (のようなもの)
GET / HTTP/1.1 （空行）
を送ると、レスポンスヘッダ (のようなもの)
HTTP/1.1 200 OK （空行）
が送られてきて、ポートフォワード先とのセッションが確立します。 この例の場合では、確立した直後にデータが送られてきていますね:
:irc.klab.org NOTICE AUTH :*** Looking up your hostname... :irc.klab.org NOTICE AUTH :*** Found your hostname
これは、KLab 社内の IRC サーバから送られてきたデータです。 KLab では技術的な打ち合わせは IRC で済ませてしまうことも多く、 隣の席にいる人との打ち合わせでさえ、IRC で行なうケースがあります。 IRC で話しておけば文字で残りますし、 リモートにいる人も議論に参加できるので、とても便利です。
KLab 社内 IRC はあまりに常用されているので、 いつでもどこでも IRC に参加しておきたいわけで、 そういうとき VPN-Warp はとても便利です。 つまり、stone をノートPC 上で NT サービスとして走らせておくだけで、 ノートPC がインターネットにつながってさえいれば、 ダイアルアップでつながっていようと無線LAN でつながっていようと関係なく、 6667番ポートを常に社内IRC サーバへポートフォワードすることができて、 ノートPC 上の IRC クライアントで localhost:6667 へ接続して 常にチャット状態にしておける、というわけです。
2006年04月20日2000年に (株)ケイ・ラボラトリー (KLab の当時の社名) を創業してから 6 年、 当然ながら数限りなく採用面接を行ないました。 最近でこそ私の面接なしで採用された人達も増えてきたのですが、 一時は技術部門のほぼ全員が私の面接を経て入社した という人達だった時期もあります。
最終の役員面接というと、多くの人が通りいっぺんの面接だと思うらしく、 役員面接で技術的な突っ込みを受けて、応募者が戸惑うケースが多々ありました。 私としては、応募者に合わせてその都度、どういう面接方法が適しているか考えて、 質問する内容を変えてはいるのですが、 そうはいっても 100人以上も面接すればある程度パターンのようなものもでてきます。
比較的頻度が高い質問パターンを紹介し、 どう答えることができていたら採用になっていたか、 振り返ってみようと思います。 名付けて「面接FAQ」、面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法。
KLab にあまり興味を持っていなかったけど (転職斡旋エージェントに勧められて) とりあえず面接を受けに来ました、 という応募者に、 なんとか KLab の魅力を伝えて、入社しようという気にさせるのが 面接官の腕の見せどころだと思うのですが、 それでもやっぱり面接での話の成り行き上、 志望動機について質問することはよくあります。
すると、「KLab の高い技術力が魅力的」、とか 「そういう高い技術を学び、身につけたい」、とかおっしゃるかたが 少なからずいます。 そういうことを言われてしまうと、 私はつい (^^;)、 「高い技術力って例えばどんなことですか？」と 聞いてしまうのです。 意地悪な質問ですね (_O_)。
多くの方は、そういう質問が返ってくるとは全く予期していなかったらしく、 ここで言葉に詰まってしまいます。 志望動機が「技術を学びたい」なのに、 肝心のその技術がどういうものかイメージできていないのです。 言い換えれば自分が何をしたいのか実は分かっていない、 これはかなり問題ですよね？
「技術ってなんだろう…」 ふとそんなことを考えたことが一度でもあるような人ならば、 「技術を学びたい」なんて抽象的な言い方ではなく、 もっと具体的なことが言えると思うのです。 そして自分が何をしたいか、きちんとイメージできている人は、 KLab に入社したあと、ほぼ例外無く大活躍しています。
2006年04月19日KLab の開発に参加いただいている協力会社の A 社の S 社長が、 tech ML に投げた問いかけに対し、 同じく協力会社の H 社の役員である K さんが応えました。
# KLab 社内の ML なのに、KLab 社員以外で話が盛り上がる
# こともあるのが、tech ML の大きな特長です (^^;)。
> ＃どなたが「専門教育」を受けられた方なのかわかりませんが^^;
> ＃＃ぜひ土日で古い教科書などを掘り出していただきたく:-)
今でもコンピュータでの処理（方法の）限界に関してはとても興味があり
オートマトンと計算可能性 情報処理シリーズ
有川 節夫 (著), 宮野 悟 (著)
あたりはおもしろいかなと。私は特に後半の計算可能性が好きです。
で、私も話に加わってみました:
仙石です。おお、ついに tech ML で計算可能性の話題が...
K さん曰く:
> 「オートマトンと計算可能性」
このあたりの、一通り学べる本を読んでみると、 大学の専門課程で何をやってるのか知る事は、できそうですね。
# でも、知る事と理解する事は全く別物 ;-)
> あたりはおもしろいかなと。私は特に後半の計算可能性が好きです。
本当に重要なのは、この「おもしろい」という感覚かもしれませんねぇ...
計算可能性に関する「おもしろい」本としては、
決定不能の論理パズル―ゲーデルの定理と様相論理
レイモンド スマリヤン (著), 長尾 確 (翻訳), 田中 朋之 (翻訳)
あたりがおすすめ。いきなりこの本を読むと挫折するかも知れない ;) ので、
入門用としてはホフスタッターの不朽の名作:
ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版
ダグラス・R. ホフスタッター (著), Douglas R. Hofstadter (原著),
野崎 昭弘 (翻訳), 柳瀬 尚紀 (翻訳), はやし はじめ (翻訳)
があまりにも有名ですね。
# 20周年記念版が出たのか〜
# ということはつまり、私が初めてこの本を読んでから 20年たった、という
# ことなのですね。う〜ん歳をとったものだ...
2006年04月18日前回は、ssh のポートフォワーダと比較して、 VPN-Warp には次の特長があることを説明しました。
- ログインアカウントが不要
- アクセス対象はリレーサーバのみ
例えばローカルホストの 8080番ポートを、 リモートの intra:10080 へフォワードする場合、 次のように、ローカルホストで stone を、リモートホストで relayagent を、 それぞれ走らせます。
ローカルホスト リレー リモートホスト
stone ─────→ サーバ ←──── relayagent─→ intra
8080番ポート …………………………………………………→ 10080番ポート
stone も、relayagent も、リレーサーバに対しては 「クライアント」であることに注意してください。 また、ローカルホスト、リモートホスト、リレーサーバ、 いずれにおいても、ssh の場合のようなログインは必要ありません。
必要なのは、SSL クライアント認証だけで、 stone/relayagent はクライアント証明書を使って リレーサーバへアクセスする、というわけです。 実際、リレーサーバは stone/relayagent にとって、 普通の https サーバのように見えます。 リレーサーバは、stone/relayagent 双方から SSL 接続を受付け、 もし同一のクライアント証明書を持っている組があれば、 それらを結び付ける役割を果たします。
具体的な設定方法
stone/relayagent それぞれの具体的な設定方法を見ていきましょう。
stone の設定
stone の設定ファイルは次のような感じになります:
-q key=private.pem -q cert=cert.pem relay.klab.org:443/ssl,http localhost:8080 "GET / HTTP/1.1" --
- -q key= から始まる行は、SSL 証明書の秘密鍵ファイル、
- -q cert= から始まる行は、SSL 証明書の公開鍵ファイルの指定です。
- relay.klab.org:443 はリレーサーバの指定、
- 最後の localhost:8080 がローカルホストで listen するポートの指定です。
このような設定を行なうと、 stone は 8080番ポートで受けた接続を、 「https リクエストに乗せて」リレーサーバへ転送します。
「https リクエストに乗せて」というのはどういうことかというと、 例えば 8080番ポートに接続して「abcdefg」というデータを送信したとすると、 stone は以下のようなデータを、SSL で暗号化してリレーサーバへ送ります:
GET / HTTP/1.1 abcdefg
あまり「https リクエスト」のようには見えませんが (^^;)、 最初の一行がリクエストヘッダで、 空行をあけて、リクエストボディが続いている、と見なすこともできます。
実をいうとリクエストヘッダ (のようなもの) を送り終わった時点で、 任意のデータの送受信が可能で、 送信したデータデータはそのまま relayagent へ伝わります。 つまり、 8080番ポートが、relayagent へフォワードされる、というわけです。
relayagent の設定
relayagent の設定ファイルは次のような感じになります:
-n -k private.pem -c cert.pem relay.klab.org:443 intra:10080
- -n は、relayagent をポートフォワーダとして使う、という意味です。
- -k から始まる行は、SSL 証明書の秘密鍵ファイル、
- -c から始まる行は、SSL 証明書の公開鍵ファイルの指定です。
- relay.klab.org:443 はリレーサーバの指定です。
- 最後の intra:10080 がポートフォワード先の指定です。
このような設定で relayagent を実行すると、 relayagent は、リレーサーバに対して以下のような「ポーリング」を https を装って行ないます。
GET /KLAB/poll HTTP/1.1 X-Ver: 2 relayagent.cpp,v 1.32 W (TAKUMI)
「X-Ver:」の次の数字「2」で、relayagent - リレーサーバ間の プロトコルのバージョン番号を伝えています。 続く「relayagent.cpp,v 1.32 W (TAKUMI)」は単に relayagent のバージョンを (トラブル時の解析用として) 伝えているだけで、通常は参照されません。
このリクエストヘッダ (のようなもの) を送り終わると、 リレーサーバは次のようなレスポンスを返します:
HTTP/1.1 200 OK X-Customer: nusers=10&type=3&expire=1262271599&digest=0123456789abcdef0123456789abcdef
この、https レスポンスヘッダ (のようなもの) を受信した後、 relayagent はレスポンスボディ待ち状態 (ポーリング状態) になります。 この状態の時、 同じ証明書を持つ stone からの接続があると、 その情報がレスポンスボディとして送られてきて、 relayagent はそれを受けて intra:10080 へ接続を行ない、 stone と intra:10080 との間の通信が確立する、というわけです。
2006年04月17日多くの会社と同様、KLab (および KLabセキュリティ) でも、 出来る限りオープンソースを利用するようにしています。 我々がDSASと呼んでいる システムインフラは、完全にオープンソースベースとなっており、例えば 「ファイアウォール兼負荷分散器兼ルータマシン」も Linux ベースとなっております。
なぜオープンソースにこだわるのか？
佐野氏のコラムに、 オープンソースにこだわる人の理由って正しい？:
> オープンソースにこだわる人に理由を聞くと普通
>
> １．無料だから
> ２．大勢の人が使っているからバグが少ないと思われる
> ３．ソースコードが公開されているから安心
>
> という答えが返ってきます。１と２はまあその通りだと思います。
> しかし３は個人的にちょっと疑問です。
> オープンソースにこだわっている人で、オープンソースソフトウェアの
> ソースコードを実際に分析したことがある人って
> どのくらいいるのでしょうか。
……
> なのでオープンソースにこだわる理由を聞かれたらかっこいいこと
> 言わずに素直に「無料だし機能に不満もないから」くらいにしておくのが
> よいのではないでしょうか。
という問いかけがありました。さすが佐野さん、的を射た厳しいご意見ですね。 正直な話、KLab もオープンソースを利用しているといっても、 スミからスミまで分析しているわけではありませんし、 「無料だし機能に不満もないから」という面もあることは否定しません。 しかし、お客様にサービスを提供するという立場としては、 もう少し積極的な理由も持ちたいところです。
責任あるシステム運用を実現するためのオープンソース
システムにベンダ任せのブラックスボックスな部分があると、 その部分が原因の障害への対応は遅くなりがちですし、 原因究明を完全に行なうことができなければ、 再発防止策も対症療法的なものになりがちです。 これでは自信を持ってお客様にサービスを提供することができません。
KLab も以前は箱モノの負荷分散機を利用していたのですが、 クリティカルなバグに散々悩まされました。 この箱モノは L2処理に問題があり、 通信不良が発生するケースがあったのです。 もちろんベンダへは症状を報告していたのですが、 完全な対策には至らず、なんとか運用でカバーしていました。
これでは、いつ症状が再発するか分からず 精神衛生上もよろしくありません。 そこで、LVS (Linux Virtual Server) を使って Linux ベースの負荷分散機を 構築することにしました。 むろん、LVS のソースコードの全てを完全に把握しつくし、 LVS プロジェクトに貢献できるようになるまでには、 まだまだ道程が遠いのですが、 再現可能な障害であれば問題の所在を見つけ出せる程度の レベルには達することができていると思っています。 しかも、実はこうやって自前で構築した負荷分散機の方が、 それまで使っていた箱モノよりずっと安定して運用できてしまったのです。
ベンダの都合に振り回されないためのオープンソース
プロプライエタリなソフトウェアを使っている場合は、 ベンダがサポートを停止するリスクというのも考えておかねばなりません。 ベンダがサポートを止めたことを理由に、 弊社のお客様に対するサービス提供を止める、というやり方も 無いわけではありませんが、 技術会社を標榜する KLab としては、 あまりそういう言い訳はしたくありません。
すると、 ベンダがサポートを止めたときのことまで考えておく必要がありますが、 あいにくソフトウェアの使用許諾というのは一般に不平等契約で、 ソフトウェアを使用する側には打つ手がないことが多いようです。 ベンダの都合に振り回されるよりは、 いざとなったら自前で解決できるよう、 ソースがオープンになっているソフトウェアを選ぶ方が 結果的に楽といえるのではないでしょうか。
「なんかプロプライエタリって馬鹿みたいだな」 (ここギコ！) で、
> プロプライエタリなソフトの方がよっぽどリスクだらけちゃうの？
> わざわざクソ高い金払うのに、と思えてくる。
という意見も出ているように、 ベンダのサポートがアテになるケースばかりとは限りません。
自由なシステム構築を実現するためのオープンソース
どんなに柔軟性が高いソフトウェアでも、 カスタマイズで可能な範囲というのはタカが知れています。 ソースを改変することによって得られる自由とは雲泥の差でしょう。
KLab としては、 他社では行なっていないような方法で、 耐故障性を向上させたり、 性能を向上させたり、 より低コストな運用を実現したり することによって、 差別化をはかっていきたいわけで、 そうなるとベンダの製品を使うよりは、 オープンソースを使うべき、という選択になります。
実際にどのようにオープンソースを活用しているかは、 DSAS開発者の部屋などで 紹介していきたいと思っておりますし、 オープンソースを活用していく過程で我々のレベルが上がって、 オープンソース界に貢献できるようになれれば、 それは我々にとって望外の幸であり、 それを目指して研鑽を積んでいく所存です。
2006年04月16日KLabセキュリティの主力製品である、 個人情報スキャナ 「P-Pointer」 の広告を、4/14 から一ヶ月間、地下鉄に出すことにしてみました。 インターネット広告が伸びつつある今、 時代に逆行しているようですが、 交通広告という従来型の広告がどれだけ効果があるか楽しみです。
東京メトロ 地下鉄 半蔵門線 に掲載した、
P-Pointer の
窓上広告:
一般的には、窓の上の広告なんて (見上げないと見えないから) 誰も見ないだろうということで、 吊り広告などに比べると安価な窓上広告なのですが、
我々がリーチしたい人達はラッシュの時間帯に乗る通勤客
↓
ラッシュ時間帯の田園都市線は死ぬほど混む
↓
とても新聞とかを読めるような状態ではない
↓
地下鉄だから景色を見るわけにもいかない
↓
仕方ないんで窓の上の広告でも見るか
となるので、 混雑する通勤路線であればあるほど窓上広告は効果的だと想像した次第です。 私自身、毎朝毎晩、ラッシュの田園都市線 (渋谷から西へ伸びる東急路線です。地下鉄半蔵門線と相互乗り入れしています) で通勤していて、 窓上広告を見る機会が多かったりしますし、 沿線にはいわゆる「IT業界」の会社が多く、 「個人情報」にセンシティブな人が多いだろう、 ということで半蔵門線を選びました。
2006年04月15日前回は、ssh のポートフォワーダには次の二点の欠点がある、 というお話をしました。
- リモートホストにログインアカウントが必要
- リモートホストへアクセスできることが必要
すなわち、ssh でポートフォワードを行なう場合、例えば
ssh -L 8080:intra:10080 remote "sleep 1d"
といった感じで実行しますが、ssh ログイン先である remote の セキュリティレベルを下げる要因となってしまう、という欠点です。
欠点 (1) を VPN-Warp ではどのように解決しているか
VPN-Warpでは、リモートマシンにログインアカウントは必要ありません。 リモートマシンに必要なのは、リレーエージェントと呼ばれるプログラムを 走らせることだけで、Linux 上でも Windows 上でも走らせることができますし、 Windows 版は、NT サービスとして実行することも可能です。
VPN-Warp ではユーザ管理をリレーサーバ上の DB で行なっていますので、 100万人規模のユーザに対しても余裕でサービスできます。 リモートマシンではユーザ管理を行なう必要がないので、 リレーエージェントを走らせるために必要な設定は、 ポートフォワード先 (上述の例だと intra:10080) の設定だけです。
リレーエージェントが行なうのは、 ポートフォワードに限定されているので、 セキュリティリスクを最小限に抑えることができます。
欠点 (2) を VPN-Warp ではどのように解決しているか
VPN-Warpでは、リモートマシンに直接アクセスする代わりに、 中継専門のリレーサーバを用います。 リモートマシン上で走らせるリレーエージェントが、 リレーサーバへアクセスしてリレーサーバと連係動作することによって、 ローカルホストがアクセスする対象はリモートマシンではなく リレーサーバになります。 ssh と VPN-Warpの違いを図で書くと次のような感じになります:
ssh のポートフォワードの場合:
ローカルホスト リモートホスト
ssh ─────────────────→ sshd ─→ intra
8080番ポート …………………………………………………→ 10080番ポート
VPN-Warpの場合:
ローカルホスト リレー リモートホスト
stone ─────→ サーバ ←──── relayagent─→ intra
8080番ポート …………………………………………………→ 10080番ポート
図中 relayagent というのがリレーエージェントです。 VPN-Warpの場合、リモートホストへは外部からアクセスする必要が ないことに注意して下さい。 代わりに外部からのアクセスを受け付けるのは「リレーサーバ」です。
ssh の場合はリモートホストが外部からの攻撃に晒されるリスクがあるわけですが、 VPN-Warpの場合は、外部からの攻撃に晒されるのはリレーサーバだけです。
そしてリレーサーバは、KLab など VPN-Warp 提供側が運営するので、 VPN-Warp ユーザは外部からの攻撃を気にする必要がありません。
また、リレーサーバ自体は単にデータを右から左へデータを流すだけで、 ssh ログインアカウントのような侵入の足掛かりになるようなものは 何もありません。 もちろんリレーサーバは、専用のディレクトリへ chroot してから、 リレーサーバ専用のユーザ権限で実行するようにしています。
2006年04月14日「DB サーバのセキュリティ向上策 (3)」では、 どのユーザが UNIX ドメインソケットにアクセスしたか特定するために、 ユーザごとにソケットを作成しました。 しかし Linux などの OS では、UNIX ドメインソケットに限り アクセス元のユーザを getsockopt(2) で調べることができるので、 ソケット一つだけでどのユーザからのアクセスか区別することができます。
例えば以下のように getsockopt の引数に SO_PEERCRED を指定することにより、 ucred 構造体にアクセス元のユーザの情報が格納されます:
struct ucred cr;
int len = sizeof(cr);
int ret = getsockopt(sd, SOL_SOCKET, SO_PEERCRED, &cr, &len);
if (ret == 0) {
struct passwd *passwd = getpwuid(cr.uid);
...
}
したがって、UNIX ドメインソケットを listen し、 そのソケットへ接続があったら、 それを DB サーバへ通信を監視しつつ中継するプログラム dbrelay において、 上記のように getsockopt(2) を使ってアクセス元ユーザを特定し、 通信の監視によって得られた DB ユーザ名と一致したら中継を継続し、 一致しなかったら通信を遮断する、ということが可能になります。
もちろん、各ユーザが直接 DB サーバへアクセスしないよう、 dbrelay からのアクセス以外は OUTPUT チェインで通信を却下します。
このような仕掛けを、ラック内の全サーバに仕込むことにより、 各ユーザは同名の DB ユーザでのみ DB サーバへ、 UNIX ドメインソケット経由でアクセスできます。
通信の監視をクライアント側でなく、 DB サーバ側で行ないたい場合は、 クライアント側の dbrelay では アクセス元のユーザ名をサーバ側へ伝えるだけにして、 通信の監視および通信の遮断はサーバ側で行なわせることもできます。
最新版 の stone には アクセス元のユーザ名をサーバ側へ伝える機能があるので、 例えばクライアント側で次のように stone を実行します。
stone dbserver:12345/http /tmp/db.sock '\U'
「/http」の指定と「'\U'」が、ユーザ名をサーバ (dbserver:12345) へ 伝える設定です。例えばユーザ sengoku が UNIX ドメインソケット /tmp/db.sock にアクセスすると、stone はまず
Apr 14 07:54:36.809789 16384 3 5>6 73 65 6e 67 6f 6b 75 0d sengoku. Apr 14 07:54:36.809828 16384 3 5>6 0a 0d 0a ...
を dbserver:12345 へ送信し、その後は /tmp/db.sock から dbserver:12345 への 中継が行なわれます。 したがってサーバ側ではまず最初に送られてきたユーザ名を受け取り、 その後は通信を監視しつつ 12345 番ポートから DB サーバへの中継を行なえばよいわけです。
2006年04月13日KLabセキュリティ(株)の製品に VPN-Warp という SSL VPN ソリューションがあります。 この製品は、最初のプロトタイプを私が開発し、 社内インフラ構築で長年 (といっても KLab(株) が設立からまだ 6年なので、 せいぜいそのくらいですが) 使い倒すことによって信頼性があがってきたものを、 商品化したものです。 私自身が最初に開発した、という愛着もあるので、 「仙石浩明CTO の日記」という場を利用して、 VPN-Warp を内部構造も含めて解説していきたいと思います。
VPN-Warp は、ふつうの SSL VPN に比べ、以下の特徴があります:
- サーバ側の設定が簡単
特殊な設定の必要がありません。 イントラネット上の Web サーバに専用ソフトウェアをインストールするだけです。 - 既存のイントラネット環境を利用
ファイアウォールの設定を変える必要がありません。 - PC、携帯電話、PDA などから利用可能
主要端末に対応しています。 - ファイアウォール内部の情報を完璧に保護
SSL により暗号化・認証 (クライアント・サーバ間の相互認証) で 高度なセキュリティを実現します。 - クライアント側への簡単な導入
特別なソフトが必要なく SSL 証明書のインポートだけで使えます。 - 安定したシステム
定評ある KLab のデータセンタを利用するため安心です。
VPN-Warp って何？
一言で言うと、ポートフォワーダです。 ssh のポートフォワードを使ったことがある人は多いと思うのですが、 基本はアレと同じです。 ssh だと、ローカルホスト (例えば自分の PC) 上で
ssh -L 8080:intra:10080 remote "sleep 1d"
などと実行することにより、 ローカルホストの 8080 番ポートを (remote から見て) intra:10080 番ポートへフォワードできます。 intra:10080 に、イントラへアクセス可能な http proxy が動いていれば、 ローカルホストの 8080 番ポートをイントラの http proxy として 使うことができるわけですね。
じゃ、ssh でいいんじゃない？ なんで VPN-Warp を使うの？
ssh のポートフォワーダには大きく分けて二つの欠点があります:
- リモートホスト (この例では remote) にログインアカウントが必要
ポートフォワードするためだけに、 ssh でログインできる権限を与える というのは、いかにも牛刀ですよね？ また、サーバのアカウントというのは滅多矢鱈に増やせるものでもないので、 例えば数千人を超えるユーザにサービスする方法としては現実的ではありません。 - 外部からリモートホストへアクセスできることが必要
この例の remote はイントラ内へアクセスできることが必要です。 イントラ内へアクセスできるサーバを 外部からアクセスできるセグメント (例えば DMZ) に置くのは 現実的ではありませんから、普通はいったん外部からアクセス可能な サーバ (例えばファイアウォール) の 適当なポート (例えば 10022 番ポート) で受けて、 それをイントラ内へフォワードするように設定しておくことになります。 DMZ に置くよりはマシであるものの、 外部から直接ログインできてしまうことにかわりはありません。
この二つの欠点は、どちらも「リモートホスト」の セキュリティレベルを下げる要因になります。 単刀直入に言えば、外部の第三者が「リモートホスト」にログインして フルコントロール権限を奪うリスクが高まっている、ということです。
次回は、VPN-Warp が上記欠点をどのように解決しているか説明します。
2006年04月11日KLab の開発に参加いただいている協力会社の A 社の S 社長が、
私自身は情報処理のキホンをちゃんと「教わったり習ったり」した ことはなく、その点で、至る所で「やっぱりキホンがしっかりして いる人には適わないなぁ」と感じるシーンも経験します。
で、大学や専門学校で情報処理を学んで来た人に教えて欲しいの ですが・・・・・・
| Q1） | 学校でどんなコース(講義/単位)がありましたか。
○○学 とか ○○技法 とかそんな感じの。 |
| Q2） | その中で、印象深かったものや、今こうやって開発の現場で仕事を
していて「学んでよかったなぁ」と思ったものを教えてください。 |
| Q3） | 今この会社の、学校でそういうことを学んでこなかった人に対して
「俺が解るように教えてやる！」というのがあるとしたら どんな事ですか。 |
という質問を tech ML にしました。
みなさんならどう答えますか？
- A1)
- 私は情報工学科だったので、論理回路からコンパイラ、ソフトウェア工学まで一 通り学びました。ついでにいうと実践的なプログラミングは、某ソフトウェアハ ウスでバイトして覚え、ネットワークは、最初の就職先のイントラ構築の手伝い をして覚えました。
- A2)
-
専門課程で学ぶ事で一番大事なのは、「大海」を知る事ですね、きっと。
「大海」を知らない「井の中の蛙」は、決して「井」から出る事はできません。
大事なのは知識や経験を身につける事ではなくて、自分が何を知らないかを 知る事です。
大学は「開発の現場で」役にたつことを教えてくれない、と多くの人が言います が、そういうことを言う人って、ほぼ確実に自分が何を知らないか分かってない と思います。 - A3)
-
なんでもいいです。自分では到底作り出す事ができないものについて、
完全に理解するよう努力する経験をすることができるのであれば。
言い替えれば、何か (What) を学ぶ事が重要なのではなくて、
まして、どうやって (How) を覚える事なんて重要であるはずがなく、
体得すべきは、なぜ (Why) を問い続ける習慣そのものです。
「トランザクション輪読会」(社内輪読会です) の本を、 「分かったつもり」レベルではなく、 完全に理解できるまで頑張るとかでも、もちろんいいですね。 どこまで完全に理解できたか自体は、実はあまり重要ではなくて、 理解しようと努力して、自身の限界まで力を出し切ってみることが事が 大事なのではないかと。
「輪読会」に参加した人は実感していると思いますが、何が分からないか 分からない人は、質問さえできないわけです。自分が本当に理解できているか、 常に反省する習慣を身に付けたいものです。
ちなみに私は大学生の時、隣の理学部の数学科へ出かけていって、 なんとか理解しようとさんざん苦しんだ挙げ句、 どーしても「分かったつもり」レベルから脱することができずに 自身の理解力の限界を知る経験をしました。
いちおーその単位は取ったのですが、数学者になることはあきらめて 情報工学に専念しようと思ったのでした。
2006年04月08日先日、KLab のエンジニアの T さんが、 KLab 社内 ML でマーケティングの本を紹介しました。
今週のマーケティング本：「マーケティング / 恩蔵直人」
私がマーケティングを学んだときの師から紹介された本。 入門書として読むのも良いですが、網羅的かつ体系的に纏められており、 マーケ脳を整理・刺激するのにも適していると思います。 電車の中でも読みやすい文庫サイズ。
さっそく買って読んでみました。 網羅的に分かりやすく説明してあるので、 マーケティングを専門としない人にもいい本ですね。 そこで、私も推薦文を tech ML (KLab 技術者 ML) に書きました:
T さんオススメのマーケ本を買いました。 この本に書いてある事くらいは、 きちんと押えておくと、 技術者以外の人と話す時に役立つのではないかと思います。
つまり、技術者、企画者、マーケター、セールス、 会社ではいろんな人が業務を分担して仕事を進めるわけですが、 共通言語を持っていないと意思疎通がうまく いかなくて仕事がスムーズに進みませんよね？
で、共通言語というかバックグラウンドを少しでも共有するために、 お互いの分野の基礎的な部分くらいは、網羅的に押えておく事が重要ですね。
なので、技術者こそ、こういうマーケティングの基礎を網羅的に解説した本を 読むべきだと思います。 後ほど本棚に置いておきますので、是非読んで下さい。
# 真っ先に読みたい、という人は私が本棚に置く前に取りに来てね。
というメールを tech ML に流した直後、 KLabセキュリティの Windows プログラミングが得意な S さんが取りに来ました。 彼は日頃、マーケティングな人達から無理難題 ;) を押しつけられて 困っているので、 マーケティングの基礎を学ぶことはきっと役にたつことでしょう。
こういう本を読んで、 マーケティングとはそもそもどんなことなのか知っておかないと、 同じプロジェクトで一緒に働いているマーケ担当な人が、 マーケタとしてどのくらい優秀な人なのか、 あるいはダメな人か分かりませんよね？
同僚が優秀なマーケタなら、 その人の言う事を信じて開発方針を決めてかまわないのですが、 そうでないマーケタの場合は、 言う事を鵜呑みにするのは危険ですよね？ 信じる者は足をすくわれてしまうでしょう。 そういう場合は、鵜呑みにせずに、 他の人の意見を聞くなり、自分で考えるなりしなくてはなりません。
あるいは立場を逆にして考えてみると分かりやすいかも知れません。
例えば、技術の事が全く分からない人が、 技術者に開発を依頼をするとき、 その技術者がどのくらい優秀な人か分からないと、 その人が○週間で開発できる、 という言葉を信じていいのか良くないのか判断できませんよね？ できる、と言ったから信じたのに〜、と言っても後の祭です。
だから技術者でない人も、 相手がどのくらい優秀な技術者か判断できる程度には、 技術の基本を網羅的に押えている必要がありますし、 その逆に、マーケティングの専門家でない人も、 相手がどのくらい優秀なマーケターか判断できる程度には、 マーケティングの基本を網羅的に押えている必要がある、 ってことだと思います。
2006年04月07日前々回(3)、 前回(4) と、 他人の DB パスワードを知ったユーザが、 その人になりすまして DB にログインしようとしても DBサーバへの通信を遮断する仕掛けについて説明しました。 (3) はクライアント側で、(4) はサーバ側で、 それぞれ DBサーバへの通信を監視し、 UNIX ユーザ名と、DB ユーザ名が一致しない場合は通信を遮断します。
DB サーバへの通信から DB ユーザ名を抽出する方法は、 DB サーバの種類によって異なるので、 専用のものを実装することになるのですが、 今回はその一例として MySQL 4.0.x の場合について説明しましょう。
MySQL の場合は、ソースが公開されていますし、 開発者向けにはプロトコル仕様書もあるようなので、 クライアント−サーバ間通信を完全に解析することも可能なのですが、 DBユーザ名を取り出す程度なら通信内容をダンプするだけでも 取り出し方が推測できます。
まずは手始めに通信内容をダンプしてみましょう。 どんなツールを使ってもよいのですが、 ここでは拙作 stone を使ってみます。 適当なポートで listen し、 それを MySQL サーバへ中継しつつ、 通信内容をダンプするように stone を実行します。 例えば、12345番ポートで listen し、 「-ppp」オプションを指定することによって通信内容をダンプさせ、 ホスト「dbserver」の 3306番ポートへ中継させるためには、 次のように stone を実行します。
stone -ppp dbserver:3306 12345
そして、MySQL のクライアントである mysql コマンドを実行します。 MySQL サーバに接続する代わりに、 stone が listen する 12345番ポートに接続させましょう。
mysql -P12345 -h127.0.0.1 -usengoku -pabcdefg
DB ユーザ名「sengoku」、パスワード「abcdefg」で接続します。 この時、stone の出力は次のようになります:
% stone -ppp dbserver:3306 12345 Apr 7 07:04:45.525293 16384 start (2.3a) [19635] Apr 7 07:04:45.530733 16384 stone 3: senri.gcd.org:3306 <- 0.0.0.0:12345 Apr 7 07:05:03.405877 16384 stone 3: accepted TCP 5 from 127.0.0.1:37758 mode=3 Apr 7 07:05:03.417693 16384 3 5<6 34 00 00 00 0a 34 2e 30 4....4.0 Apr 7 07:05:03.417785 16384 3 5<6 2e 32 35 2d 73 74 61 6e .xx-stan Apr 7 07:05:03.417802 16384 3 5<6 64 61 72 64 2d 6c 6f 67 dard-log Apr 7 07:05:03.417813 16384 3 5<6 00 e8 7e 00 00 2d 3a 79 ..~..-:y Apr 7 07:05:03.417823 16384 3 5<6 75 5e 58 7e 31 00 2c 20 u^X~1., Apr 7 07:05:03.417833 16384 3 5<6 0c 02 00 00 00 00 00 00 ........ Apr 7 07:05:03.417844 16384 3 5<6 00 00 00 00 00 00 00 00 ........ Apr 7 07:05:03.418337 16384 3 5>6 15 00 00 01 85 24 00 00 .....$.. Apr 7 07:05:03.418374 16384 3 5>6 00 73 65 6e 67 6f 6b 75 .sengoku Apr 7 07:05:03.418385 16384 3 5>6 00 53 4d 5c 4a 55 53 49 .SM\JUSI Apr 7 07:05:03.418393 16384 3 5>6 57 W Apr 7 07:05:03.418643 16384 3 5<6 05 00 00 02 00 00 00 02 ........ Apr 7 07:05:03.418671 16384 3 5<6 00 .
各行始めの「Apr 7 07:04:45.525293」は時刻で、マイクロ秒単位で表示しています (マイクロ秒単位まで表示するようになったのは stone 2.3a からです)。 次の「16384」はスレッドID ですが、今回は無視してもらって構いません。 最初の三行は stone のログなので無視するとして、 次の部分が MySQL サーバからクライアントへ送られた通信内容です。 「5<6」が、サーバ→クライアント方向の通信であることを示します。
Apr 7 07:05:03.417693 16384 3 5<6 34 00 00 00 0a 34 2e 30 4....4.0 Apr 7 07:05:03.417785 16384 3 5<6 2e 32 35 2d 73 74 61 6e .xx-stan Apr 7 07:05:03.417802 16384 3 5<6 64 61 72 64 2d 6c 6f 67 dard-log Apr 7 07:05:03.417813 16384 3 5<6 00 e8 7e 00 00 2d 3a 79 ..~..-:y Apr 7 07:05:03.417823 16384 3 5<6 75 5e 58 7e 31 00 2c 20 u^X~1., Apr 7 07:05:03.417833 16384 3 5<6 0c 02 00 00 00 00 00 00 ........ Apr 7 07:05:03.417844 16384 3 5<6 00 00 00 00 00 00 00 00 ........
MySQL のバージョン番号らしきものが送られている様子が分かります。 ここでの目的は DB ユーザ名を抽出することであり、 DB ユーザ名は、クライアント→サーバ方向に送られるはずなので、 サーバ→クライアント方向の通信は無視してしまっても構わないのですが、 先頭の「34 00」には注目しておいた方がよいでしょう。 この手のクライアント−サーバ間プロトコルでは、 先頭にこれから送るデータの長さを送信することが一般的だからです。 実際、「34 00」は十進数で言うと 52 ですが、 クライアントへ送られたデータは 56 バイトなので、 先頭 2 バイトがデータ長、次の 2 バイト「00 00」がデータの種別、 残りの 52 バイトがデータだろう、と推測できます。
続く部分が、クライアントからサーバへ送られた通信内容です。 「5>6」が、クライアント→サーバ方向の通信であることを示します。
Apr 7 07:05:03.418337 16384 3 5>6 15 00 00 01 85 24 00 00 .....$.. Apr 7 07:05:03.418374 16384 3 5>6 00 73 65 6e 67 6f 6b 75 .sengoku Apr 7 07:05:03.418385 16384 3 5>6 00 53 4d 5c 4a 55 53 49 .SM\JUSI Apr 7 07:05:03.418393 16384 3 5>6 57 W
先頭 2 バイト「15 00」がデータ長であると仮定してみます。 十進数で言うと 21 で、 データ種別と推測される 2 バイトデータ「00 01」の後に 21 バイトのデータが続いています。 そして、データの中に明らかに DB ユーザ名と思われる文字列「sengoku」と そのデリミタと思われる「00」があります。 続く 8 バイトはパスワードと推測できます。 DB ユーザ名の前の 5 バイトのデータ「85 24 00 00 00」は、 固定長のデータと推測できるので、 DBユーザ名を抽出するには、 クライアント→サーバ方向のデータのうち、 最初から 10 バイト目から「00」までを取り出せば良さそうです。
もちろん実際に運用する際は、MySQL のソースないしプロトコル仕様書を 参照して確実を期するべきですが、 プロトコル仕様が公式には公開されていない DB サーバの場合でも、
- DB ユーザ名が取り出せなかった場合は、ログに出力した上で通信を容認
- DB ユーザ名が取り出せたが、その DB ユーザ名が DB に存在しない場合は、 ログに出力した上で通信を容認
- DB ユーザ名が取り出せて、かつその DB ユーザ名が存在する場合は、 取り出した DB ユーザ名が正しいものとして扱い、通信の許可/遮断を行なう
などと、DB ユーザ名を正しく取り出せなかったと思われるときは とりあえず通信を容認しておいて、 後ほど DB ユーザ名の抽出方法を改訂する、という運用が可能でしょう。
なお、MySQL の場合は前述したように公式なプロトコル仕様書もありますし、 Ian Redfern 氏がソースを解析して作成したプロトコルの解説が 以下のページで公開されています。
- MySQL Protocol (MySQL 3.22 〜 4.0)
- http://www.redferni.uklinux.net/mysql/MySQL-323.html
- MySQL Protocol (MySQL 4.1)
- http://www.redferni.uklinux.net/mysql/MySQL-Protocol.html
2006年04月06日前回は、 DB サーバへの通信を監視して、 UNIX でのユーザ権限と DB ユーザ名が一致する時に限り 通信を許可する方法について説明しました。
アクセス元となるクライアント側のマシンならば、 どのユーザがアクセスしているか容易に調べられるので、 通信の監視もアクセス元で行なった方が簡単です。
しかしながらこの方法では、 データセンタ内の全てのサーバで通信の監視を行わなければならず、 やや繁雑です。 また、UNIX でのユーザ権限ごとのアクセスコントロールを 実現する方法として、 前回は各ユーザごとに専用の UNIX ドメインソケットを用意し、 そのパーミッション設定でコントロールする方法を紹介しましたが、 当然のことながら DB アクセスを行うクライアントプログラムが UNIX ドメインソケットをサポートしていなければなりません。
DB サーバへの通信の監視をアクセス先、 つまり DB サーバー側で行うことができれば、 クライアント側は監視が行われていることを意識する必要がなくなります。 つまり前回説明した「入口規制」によるアクセス制限ですね。 クライアント側から見れば、 普通に DBサーバへ TCP 接続するだけなので、 どのようなクライアントプログラムでも利用可能でしょう。
この入口規制を実現するには、 どのユーザ権限でクライアントプログラムが動いているのか、 DB サーバ側から調べる必要があります。 しかしながら、TCP 接続ではサーバ側は送られてきた パケットを受け取るだけなので、 そのパケットを誰が送信したかまでは関知しません。 そこで、通信相手が誰なのか調べる方法を定めたのが、 RFC1413 で提案された IDENT プロトコルです。 IDENT プロトコルは、 受け取った TCP パケットに記録されている 送信元の IP アドレスとポート番号を手がかりに、 相手が誰かクライアント側へ問い合わせます。
IDENT プロトコルは、あまり使われなくなって久しいので、 まず簡単に紹介しましょう。
ホスト CLIENT からホスト SERVER の 12345番ポートへアクセスした 場合について考えます。 その接続状況は次のように netstat コマンドなどで確認できて、
SERVER % netstat Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 SERVER:12345 CLIENT:45486 ESTABLISHED
この場合だと、CLIENT の 45486番ポートから SERVER の 12345番ポートへの TCP 接続が確立している (ESTABLISHED) ことが分かります。
このとき、SERVER は CLIENT に IDENT 問合せをすることによって、 CLIENT のどのユーザが TCP 接続の相手か調べることができます。
SERVER % telnet CLIENT 113 Connected to CLIENT. 45486,12345 … (1) 45486 , 12345 : USERID : OTHER :sengoku … (2) Connection closed by foreign host.
(1) が SERVER から CLIENT への問合せで、 送受信双方のポート番号の対を送信しています。 これに対し、(2) が CLIENT から SERVER への応答で、 TCP 接続の相手が「sengoku」であることが分かりました。
このように、通信相手が誰か手軽に確認できる便利なプロトコルなのですが、 相手ホストが信用できなければ当然 IDENT 応答も信じることはできません。 不特定多数のホストからの通信を受け付ける場合は、 IDENT 問合せを行なっても「正直な」応答が返ってくるとは期待できないわけで、 少なくともインターネット上ではあまり使われなくなったようです。
しかし データセンタのラック内のサーバであれば、 当然管理者が決まっているでしょうから、 全てのサーバで正しく IDENT 応答を返すように徹底することは容易です。 したがって、 IDENT プロトコルを使った入口規制を実施することができます。
まず DB サーバを、UNIX ドメインソケットでのみアクセスを受け付ける ように設定します。 このソケットは、local ユーザが勝手にアクセスしたりしないよう、 DB サーバを実行するユーザ権限でのみ読み書きできるように 設定しておくとよいでしょう。
次に、特定のポートで listen し、接続を受け付けたら この UNIX ドメインソケットへ中継するプログラムを、 DB サーバを実行するユーザと同じユーザ権限で走らせます。 この中継プログラムは、 中継する際に接続元ホストに対して IDENT 問合せを行ない、 IDENT 応答で得たユーザ名と、 通信を監視することによって得られた DB ユーザ名が 一致しない場合は通信を遮断するというわけです。
このような仕掛けにより、 クライアント側のユーザは、 仕掛けを意識することなく DB サーバにアクセスすることができます。 そして、 何かのはずみに別の DBユーザのパスワードを知り、 その DBユーザになりすましてアクセスしようとしても 通信は遮断されます。
2006年04月05日一般に、マシン C からマシン S へのアクセスを制限するには、
(IN) マシン S でアクセスを受け付けるところで制限する「入口規制」
(OUT) マシン C でアクセスを出すところで制限する「出口規制」
の2通りの方法があります。一般にアクセス制限というと (IN) の入口規制を用いることが多いのですが、 これはアクセスを出すマシンが特定できないか、 あるいは特定はできるのだけどマシンの数ないし種類が多過ぎるためです。
例えば、マシン S へのログインを制限したい場合を考えてみましょう。 一般的にはアクセス元となりうるマシンは特定できないか、 特定できたとしても数が多いでしょうし、 そのマシンで動く OS の種類も多種多様でしょう。 アクセス元となりうるマシンの全てで、 アクセスを出すことを制限しようとするのは非現実的です。 なので普通はアクセスを受け付ける側のマシン S で クライアントの認証を行なってアクセス制限をします。
例えば ssh の場合ならどこのマシンからのアクセスであっても、 秘密鍵を持っていることを証明できるならアクセスを許可し、 そうでなければ却下します。 アクセスを出す側のマシンでは何の出口規制もなく、 アクセスを受け付ける側のマシンでの入口規制だけですね。
ところが、データセンタのラック内のマシンに限定すれば、 事情は変わってきます。 ラック内に入れてあるマシンの数は高々有限 ;) ですし、 多くの場合全てのマシンで同じ OS が動いているでしょうし、 管理の都合からいえば全てのマシンを同じチームが管理すべきでしょう。
このような特殊な環境下では、 (OUT) の出口規制も現実的な方法となります。 例えば DB サーバへのアクセスを考えると、 DB サーバは通常のサーバ認証のみであっても、 クライアント側でアクセスを出すのを制限する出口規制を設けることによって、 セキュリティを向上させることができます。
クライアント側の OS が Linux であれば、 出口規制の方法として iptables の OUTPUT チェインを使うことができます。 例えば DB サーバが 12345番ポートでアクセスを受け付けているならば、 ラック内の全マシンにおいて
iptables -N dbaccess 2>/dev/null || iptables -F dbaccess iptables -A dbaccess -j ACCEPT -m owner --uid-owner dbuser …(2) iptables -A dbaccess -j DROP …(3) iptables -A OUTPUT -j dbaccess -p tcp --dport 12345 --syn …(1)
を実行しておきます。
DB サーバへアクセスを出そうとして、 DB サーバが動いているマシンの 12345番ポートへの接続しようとすると、 まず OUTPUT チェインの (1) のルールによって dbaccess チェインへジャンプします。 アクセスを出そうとしたユーザが dbuser であれば、 dbaccess チェインの (2) のルールによって通信が許可されますが、 dbuser 以外のユーザであれば、 (3) のルールによって通信が却下されます。
つまり、dbuser 以外のユーザは、たとえ DB のパスワードを知っていても、 DB にアクセスできない、というわけです。
DB にアクセスしたいユーザが増えてくると、 そのたびに iptables の設定を変更するのは面倒ですので、 DB サーバへ接続できるユーザは一つだけ (例えば dbuser) にしておいて、 そのユーザ権限で中継プログラムを動かすようにすると便利でしょう。
例えば、DB にアクセスしたいユーザ user1, user2, user3, user4 が あるとします。 まず、DB 上に同名のユーザアカウントを作ります。 次に、ラック内の全サーバにおいて、 ユーザ毎に UNIX ドメインソケットを listen し、 そのソケットへ接続があったら、 それを DB サーバへ中継するプログラム (ここでは dbrelay と呼ぶことにしましょう) を動かします。 例えば次のようなソケットをオープンすることになるでしょう。
/home/user1/socket /home/user2/socket /home/user3/socket /home/user4/socket
各ソケット (あるいはソケットを置いてあるディレクトリ) は、 自分以外のユーザは読み書きできないように パーミッションを設定します。 つまり dbrelay は root 権限で起動する必要があります。 さらに、前述したように DB サーバへアクセスするには dbuser ユーザ権限で実行する必要がありますから、 各ソケットをオープンした後は、 dbuser ユーザ権限に setuid する必要があります。
そして、ここが肝なのですが、 dbrelay は DB サーバへの通信を監視し、 接続を受け付けたソケットのユーザ名と、 DB へのアクセスを行なう DB ユーザ名が一致しない場合は 通信を遮断し�