某有名な殿のところて思わず突っ込んでしまったが、Security人材の不足とか今更言われてもな〜と思うわけで。

Securityってのは、根本的には、保護する対象が存在し、その価値が判定できることが前提のはずなんだよね。 なのに、最近のSecurityに関する報道だのを見ると、そういう根本はどこかに置き忘れ、ハンパな議論になっている感が凄い。

よく考えて欲しいんだけど、保護する対象があるとするなら、なぜそれが存在する(もしくは顕在化する)か？ということが本当の問題なのです。だから、「持たなければいいじゃないか」的な議論も起こるわけで。(わかりにくいかな〜)

殿も言うように、セキュリティって単純に「セキュリティという技術」があったり、「セキュリティという実装」があるわけではない。 「対象を保護する技術」なり、「対象を保護する実装」があるのであって、「セキュリティ」という独立した何かがあるわけではないんだよ、ということが本当に理解されてないと思う。

セキュリティ技術者がいないんじなくて、専門「家」として何かを「総合的に考えられる技術者」がいないんだということに気づくべきだと思う。 その意味では、専門家が足りないんだろうね。専門技術屋はたくさんいるけど。

Twitterでつぶやいたんだけど、こっちにも。こっちに書くのはそれはそれで怖いんだけど。

今日のJANOGで「なぜ、IPv6 対応したくないのか」というセッションがあって、そのツダリを見てて思った事。

IPv6にしたくない理由なんて、おそらく星の数ほどある。で、僕の観測範囲に限定すれば、「面倒臭い」と言えないから理由をつけてやらないと云うのが多い。(全てではない)

IPv6の最大の弱点はおそらくこの「面倒臭さ」を解消できなかった事じゃないかと。

で、面倒臭い理由が

• 「既にv4が広がってしまい、始めるためには結局v4もやらなければならない」
• 「v4でやれるなら両方ヤルのは工数からも運用からもコスティ」
• 「もういいよv4だけで」と多くの「Contents作成者」が思う

じゃないかと。(全てではない)

僕らインフラ側は、もう、IPv4だろうがv6だろうがなんとかなると思うわけですよ。それだけの期間IPv6を触ってきたし、そういうインフラも作ってきたし、ここからやることは恐らくほとんどデバッグ。

でも、コンテンツ側って、恐らく僕らがIPv6ネットワークを作り始めた頃はIPv6なんて関係なかったし、IPv6って言われ始めた頃は「対応が面倒」な上に、利用者も少なかった。しかも、今よく考えてみれば、v4 or v6なんて、本質的にどうでもよくて、作成したコンテンツが「最も消費してもらえる」プラットフォームを利用したいだけでしょう。Social Game作る人ですら、ほとんどの場合HTTPプロトコルのPayloadを利用するだけで別にSocket Programmingしているわけじゃないし。

(まぁ、log分析だの何だのを考えれば色々やることはあるだろうけど、そこはコンテンツ提供という当初の目的からすれば二次的な範囲なわけで)

その上で、IPv6は実質的に「アドレス空間が広いという事」以外にIPv4に対する優位点はないわけで、それも、「今のサービスモデル」を前提にするなら、NATだのLBだのである程度逃げられるから、Protocol的な優位点はないと思うわけです。

(新しいサービスモデルを考えるという「銀の弾丸」による解決は、コンテンツ提供側から出てこない限りインフラがいくら物申しても実装されない現状を考えれば、不可能という結論に落ちざるを得ない)

そういう状況だという僕の認識の上で、「僕が」今からIPv6「も」使ってもらおうとするなら、

1. 「ミドルウェアまで面倒見るから、そこにアプリを乗せてくれれば大丈夫」と云える(一種のPaaSのようなBaaSのような)サービス基盤作る
2. コンテンツ制作者側に「本当に」アプリに注力してもらい、上記インフラを使ってもらう
3. インフラの運用はコンテンツ製作者側と連動しながら自前で行う

と云う作戦を取るような気がする。

この作戦がうまく行くとは言えない(時間かかるし、そもそもそういうニーズがあるか、コストが回収できるかなどの問題がある)が、もう「銀の弾丸はない」と骨身に沁みてる人が、「小さなことからコツコツと」時間かけてゆっくりやるしかないのかな、と思っている。

僕の結論は、よほど「新規性があっ」て「今までのインフラ上ではできない」ものでない限り、インフラの根本に関する巨大な変化を要求する技術のdeploymentは「結局面倒臭い」ものだということ。

それでも、僕は、「僕の出来ることはやり続ける」つもりだけどね。

まぁ、20年近くIPv6と付き合ってきて、今だから言えることなんだけどね。

相変わらずグダグダな、整理できてないことを書いてみる。

インターネットのインフラに絡んで、はや25年になる。 この間の技術の進歩の話は置いておいて、今は運用のことを。セキュリティのコンテクストの中で、今日運用の話を幾つか見かけたので、も少し全体的な運用について書きたくなったから。

インターネットに接続されているシステムにおいて、運用は常に「後回し」にされ、顧みられることは少ない、しかしながら非常に大切な機能であると思う。

この「運用」ってやつは、利用者から見えない事が最も重要な事であって、「運用が見える=何らかの問題がある」事態であるわけです。これが意味することは、「利用者のみならず、システムを保持している者」にとっても、運用が見えなくなるということです。 また、「運用」という行為は、非常にチマチマした、わからない人が見たら「何の意味があるのかわからない」作業の集合体であるということです。 なので、運用経験のない人から見ると「無駄の塊」に見えるし、個々の作業が細いから「全体の行為内容にかかる作業量」が把握出来ず、むしろ、個々の小さい作業に引きずられて作業量を少なく見積もられがちになります。その結果引き起こされるのが、人員削減や、維持コスト削減というやつですね。いっぱい見てきました。

加えて、システムを作る側は、運用経験がないか、乏しいので、「運用が楽になる」システムを構築してくれることは稀です。考慮してくれたとしても、案外的外れなものが多い。これは、システムを設計するときに、運用視点が足りないことによって引き起こされるものです。その意味で、設計者側に多くの問題があるものです。運用側に相談があることは稀だし、あっても、運用側が何をお願いすべきなのかを適切に伝えられるかという問題も、もちろんある。その上で、少なくとも日本の会社組織で、「運用を正しく理解し適切に評価している」ところは非常に少ない。

このような運用環境の中で、一つのシステムを動かし続けることというのは、並大抵の事ではありません。 だって、動かし続けてもその意味が理解されず、感謝もされず、評価もされないから。

運用というのは健康のようなものであって、病気になってから(障害が起きてから)初めてその存在に気づくものなのです。少なくとも日本の会社組織で、「運用を正しく理解し適切に評価している」ところは非常に少ない。 これは、運用者の側から見れば、本当に悲しい事で、自分がそのシステムを支えているというプライドをモチベーションにするしかない。そうでなければ、普段評価されることもなく、何かあると責められるという仕事を続けられないわけです。

こういう状況が何を産むかといえば、凝り固まった運用、責任回避的反応、その結果としての、新しいことが出来ない環境だと思うのです。

ここまで書いたことは、勿論、ある意味での極論なのですが、なぜか、この極論のような環境をしばしば見かける。 恐らくは、管理側の経験の欠如、想像力の不足、非合理な過度のプレッシャーからくるものだと思うんですね。で、運用側に甘えてしまってそこから目を背ける。 また、運用側も、恐らくは(それまでの経験からくる)恐れ、勉強・訓練不足、整理した上での説明・報告不足、諦めなどがないまぜになって、唯々諾々と従う。 これが、現在のシステム運用環境における状況ではないかと思うわけです。 (勿論、こういうところばかりではないですが)

本来、運用者ってもっと尊敬されていいと思うんですよ。運用者がもっと声をあげてもいいと思うんですよ。それができる環境が本当に必要だと思うのです。

今の日本の運用って、恐らくはオーバークオリティなんだと思う。その原因は、恐らくは世界一厳しいと言われる利用者のプレッシャーなんだと思う。でもね、厳しいのはいいけどモンスターになってはいけない。 今の運用者の置かれてる環境は、「身内の中にいるモンスター」に理不尽な要求をされて、その要求と現状の整合性を取ることができない状態なのではないかと思うのです。 システムってのは箱物ではないのだよ。箱物よりもはるかにたくさんの「維持の為の仕事」があるのだよ。

少しだけ、思ったことを書いてみる。Security関連。 例によって、グダグダで、まとまりは無い。

数年前は、XSSだのCSRFだののようなWebアプリケーション系のセキュリティが花盛りだった。もう少し言うと、Middlewareから上のレイヤーのセキュリティ。 この状況が数年続き、そのエリアのセキュリティがビジネスに繋がってきたことから、Security技術者も、このエリアの人が増えた。知見もBad know-howも溜まった。 これはこれで素晴らしいことだとは思う。

翻ってみると、その間Infra関連技術者はApplication技術者と違ってあんまり増えていない。また、Applicaton側と比べて技術的変化が少なかった。 いまはやりのSDNだって、あれはInfra技術者側の技術ではなくApplication側の技術者向けの技術に近いと思う。
さて、この状況の中で、ShellShockや、Heartbleed、今回のracoon問題をみると、これがなかなか悩ましい。これらの問題は、少なくともApplicaton側の守備範囲からは少し離れている。むしろInfra側の守備範囲。 ところが、これらの実装は、インフラ側で対処することが困難。だって、多くのインフラ技術者って、この領域に関して言えば「提供されたupdate」を適用するしかできないから。 OSのpatch、Server applicationのpatch、FirmwareのPatch、全部根は同じ。 冪等だの青緑だの言うけど、これらは「インフラはちゃんと動く」という担保があって初めて意味を持つことであって、「インフラを動かすための技術ではない (使えないと言っているわけではない。構成管理や冗長を考えたらこの考え方はInfraにも有用)。

Securityの観点でここしばらくのようなこと(shellshock,heartbleed,…)が起こって困る事は、そもそも、インフラ側が提供している機能の根幹であるこの種のソフトウェアは、実はApplication側に比べて、余りにもぬるま湯に浸かってたという事。そして、多様性が足りなく、置き換え困難な事。さらに、一度何かが見つかると、その影響がとんでもない範囲まで広がっていて、かつ、その修正がとんでもないコストになる事。 しかも、インフラは「動いて当たり前」と思われ、かつ、過剰な価格下落を要求されている事。

(ちと脱線) 運用者から見たら、「こんな報われない、旧態依然とした、辛い刺激しかない、激務」なんてやりたくない、と思う方が普通で、だから新しい人だって入ってこないしすぐに抜けてしまう事になると思う。 (元に戻して)

まぁ、まとまりもとりとめもないんだけど、今の状況はかなりまずいところまで来ている気がしている。善意に寄りかかった寄生虫がモンスターになっていろいろ崩壊するまえに、もう一度「Infraの総点検」と、「問題点の洗い出し」を徹底する必要があり、それを一つずつ潰していく必要があると思う。

少なくとも、Applicationエリアの近くまでInfraを引き上げないと、「共倒れ」になると思う。

• etckeeper関係 http://heartbeats.jp/hbblog/2013/09/etckeeper.html https://github.com/joeyh/etckeeper http://blog.inouetakuya.info/entry/20110605/1307261417
• RANCID関係 http://dotwaffle.github.io/rancid-git/
• etckeeper with ansible https://github.com/silpion/ansible-etckeeper
• pure-vi http://ex-vi.sourceforge.net