沖縄の暑さに負けない熱戦を繰り広げた「Hardening 10 APAC」：4回目を数えた「守る」技術のコンテスト（1/2 ページ）

2014年6月21日、22日にかけて、「守る」技術を評価することを目的としたセキュリティコンテスト「Hardening 10 APAC」が沖縄・那覇市にて開催された。その模様をお伝えする。

[高橋睦美，＠IT]

　沖縄・那覇市の上空に広がるのは、梅雨の晴れ間の青い空。しかしそれには目もくれず、冷房の効いた会議室の中でひたすらPCに向かい、知恵を絞るエンジニアたち――2014年6月21日、22日にかけて、「守る」技術を評価することを目的としたセキュリティコンテスト「Hardening 10 APAC」が開催された。

Hardening 10 APACの競技会場

　Hardening 10 APACは、Webサイトの堅牢化に必要となる総合力を競うコンテストだ。サーバーの設定、運用に関わる技術力はもちろん、ダメージマネジメントや危機管理能力、実ビジネス上不可欠なコミュニケーションスキルなども含めた「守る」力を、コンペティション形式で磨くことを狙っている。

Hardening Project実行委員長の門林雄基氏

　「世間ではどうしてもマルウェアや脆弱性といった事柄が話題になりがちだけれど、eビジネスの現場で求められるのは“壊す力”ではない。現場ではバックアップのようなベタな技術も含めてシステムを止めないことが求められる。さらに、顧客からのメールにいち早く答えたりと、協調して対策に取り組み、ノウハウを共有するコミュニケーションスキルなども重要だ」（Hardening Project実行委員長の門林雄基氏）。

　これまで「Hardening Zero」「Hardening One」「Hardening One Remix」と回を重ねてきたイベントだが、4回目は会場を沖縄・那覇に移しての開催となった。

　「次は、アジアパシフィックの中心地で開催したい。じゃあ、日本の中でアジアパシフィックに最も近いのはどこだ？ 沖縄だ！ と半分ノリで決まった」（門林氏）そうだが、那覇のIT専門学校、KBC学園 国際電子ビジネス専門学校や琉球大学の学生など地元からの参加者に加え、東京、大阪などから飛行機で駆け付けたエンジニアたちが5〜6人一組で8つのチームを組み、熱戦を繰り広げた。

サーバーの安定運用が利益につながる、独自の評価方式

　Hardening 10 APACは、各チームに与えられたオンラインコマースサイトを含むシステムを6時間運用し、稼働率を競う「Hardening Day」と、どのような対策を講じたかをプレゼンテーションし、互いにノウハウを共有し合う「Softening Day」の2日構成で進められた。

　今回、各チームに与えられたシチュエーションはこうだ。東京オリンピックのプレイベントが沖縄で開催されるのに合わせ、架空の会社、OKADA Holdingsが沖縄の名産品を販売するオンラインショッピングサイト「Hardening watashi SHOP」の運営に当たることになった。各チームは、「土壇場力」を買われてそのシステムの面倒を見ることになったOKADA Holdingsのエンジニアチームという役割だ。

会場と廊下を隔てた隣の部屋では「ITパスポート試験」が行われていた

　各チームには、「情報が漏えいしているらしい、どうなっているんだ」という社長からの怒りのメールに始まり、なりすましによる不正ログインやDoS攻撃など、最近のセキュリティインシデントを参考にしたさまざまな「トラブル」がやってくる。限られた時間の中でシステム構成を読み解き、攻撃や問い合わせに優先順位を付けて対処し、時には先読みして手を打ちながら、Webサーバーの安定運用に努めなければならない。

　サーバーの面倒を見るという本業だけでなく、社長への報告や顧客対応も含めた事故対応などのさまざまなタスクも評価の対象だ。しかもその際、各チームには、事前に配布された「社内システム運用ルール」に従った大人としての振る舞いが求められる。これはHardening Projectの特徴の1つで、「ルールに定められていないことなら何でもあり」ではなく、法令順守が大前提だ。

　サーバーの運用状況は、主催者側が用意したクローラー「Sen Crawler」が巡回してチェックし、それに比例する「売り上げ」が各チームの得点になる。また、事故に対して適切に対処したといった「ファインプレー」も売り上げに加算される。逆に、社内システム運用ルールに反した行為を行ったり、脆弱性を指摘されたりした場合は減点される仕組みだ。

クローラーの情報に基づいて各チームのオンラインショップの稼働状況を可視化するレゴ。LEDが消えているチームのサーバーは「ダウン中」だ

　この評価方式の裏には、セキュリティ対策も含めきちんとシステムを運用し続けることが、売り上げ増という形で企業のメリットにつながることを訴えたい、という意図もある。

　Webサーバーをはじめ、データベースやメールサーバー、ファイアウォールや操作のためのサポート端末など、Hardening watashi SHOPを構成するシステムは全て、情報通信研究機構（NICT）のエミュレーション基盤「StarBED」上に構築されている。

　現実のシステムでこのようなトラブルに遭遇すると修羅場になることは間違いない。しかし「こうした（閉じた）環境で痛い目を見ることによって、いい経験が得られる。インシデントを予見する能力や脆弱性を直す能力、調整力、それにトラブルに負けない精神力など、さまざまな能力が磨かれる」（門林氏）。

競技開始〜初めチョロチョロ、中パッパで襲い来るトラブル

いよいよ競技開始。残り時間はこの画面に表示される

　競技は6月21日11時6分にスタートした。まずは各チームとも比較的余裕の表情を浮かべながら、情報共有の方法などについて確認し合う。ほとんどのチームは事前に情報交換やミーティングを行い、役割分担や会場に持ち込むツールなどを決めていたようで、出だしはスムーズに始まったように見えた。

　「この付せんを渡しておくから、いつ、誰が、何をしたかこれに書いて生ログとして取っておいてね」「じゃあ、とりあえずパスワードは変えておこうか」「こっちのバックアップはやっておくから、そっちお願い」「すごく怪しいユーザーいるんだけど……消していいのかな？」「もうちょっと精査してからの方がいいんじゃない？」……という具合だ。

沖縄へ向かう飛行機の中でもエクストリームプログラミングしていたというチームA「ティーダ」（左）、参加できなくなったメンバーに代わり、KBC学園の学生が緊急参戦したチームB「GTGT Ver2」（右）

「ECCubeならば得意」と乗り込んできたはずが……Zen Cartに泣いたチームC「シーサー」。約30分に一回のペースで情報共有を行っていた（左）、1カ月前から準備を重ね、知見をWikiで共有してきたというチームD「day1」（右）

　また、「シェル大事ですよねー」「うん、大事大事」「cronも大事ですよねー」「うん、大事大事」と会話を交わしながらログ監視に取り組む参加者もあった。普段とは異なる環境のためうまく自動化できず、力技、いわゆる目grepでログを監視していた参加者もいたという。

「普段学んでいたことが役に立ち、時間があるときは冷静に対応できていた」というチームE「echo」（左）、プリンターに複数のディスプレイなど、さまざまな機材を持ち込んで競技に臨んだチームF「Hana」（右）

付せんを巧みに使いこなしていたチームG「ちゃんぷるーず」（左）、こちらも地元の利を生かしてディスプレイなどを準備し情報共有したが、机が狭かった……というチームH「ティンベー＆ローチン」。確かに机の上はぎゅうぎゅうだ（右）

　しかし、そうこうするうちに主催者側チーム「kuromame6」からの攻撃がやってくる。翌日のSoftening Dayで「はじめチョロチョロ、中パッパ」と表現したチームがあったように、SQLインジェクションを手始めにインシデントが次々発生し、時間が経つにつれて激しさを増す。時には全チームのサーバーがダウンする事態まで発生し、各チームとも交わす言葉が減り、表情が真剣になっていった。

サーバーがダウンすると、売り上げ推移を可視化している画面の右下にあるアイコンが変化する

レゴショップのLEDも全て消灯

　Hardening 10 APACでは、「行き詰まったときに見てほしい」と、過去の経験を踏まえて格言形式でヒントを記したカードを用意した。「準備」「戦術」「報告」「対策」「確認」という5つの分野に分けて、「リラックスしよう」「ポンチ絵を描いてみよう」といったアドバイスを記したものだ。だがどうやら、目の前の出来事にどう対処するかで精一杯で、カードどころではなかったチームが多かったようだ。

競技環境と通常のインターネット接続環境の同居が難しかったため、アダプターを抜いたり刺したり、あるいはiPhoneなどで検索するシーンも（左）、携帯可能なホワイトボードや付せんをフル活用（右）

付せんは伸びる。最終的にはこの倍以上に（左）、目の前のタスクで頭がいっぱいになったのか、あまり活用されなかったカードだが、実は有用なヒントがちりばめられていた（右）

自社サーバーに加え、協議会システムの面倒まで？

　Hardening 10 APACには、これまでのHardening Projectにない取り組みもあった。その1つが、参加各ショップで構成する「オキンピック協議会」のシステム、「シーサーシステム」を交代制で運営するタスクが加わったことだ。

ビジネスの現場では、忙しいときに限って会議やヘルプといった割り込みが発生することは少なくない。交代で運用しなければならないシーサーシステムはそれを体感できる試み、といえるかもしれない

　また、各チームの情報共有や連携に役立ててもらう目的で、Twitterライクな「NECOMAtter」という情報共有ツールも提供された。一部のインシデントはこれを用いて他チームにも告知されていた。

「NECOMAtter」には幾つかのチームが注意喚起を書き込んでいた

　シーサーシステムの運用は、複数のチームから一人ずつ担当者が派遣されて作るアドホックなチームで、30分交代で行う。だが、自チームのサーバーの面倒を見ながら協議会サーバーにも気を配るというのはなかなか難しそうだった。

競技終了後、シーサーシステム用コンソールのあった机に残された引き継ぎメモ。苦闘の跡がうかがえる

　傍目に見ていただけでも痛感したのは、「引き継ぎ」の難しさだ。当番の時間は30分。だが最初の10分弱は自己紹介と前の担当からの引き継ぎに取られ、実質的な作業時間はさらに削られる。その中で、手探りでシステム構成や設定を把握し、少しずつ手書きで資料を作成しながらhostsファイルやiptablesの設定を調整し、次の当番に引き継いでいった。

　ちなみに、シーサーシステムのメンテナンス作業を行えるコンソールは1台きり。時にはDNS設定をめぐってメンバーがああだ、こうだと発言し、キーボードの前に座った参加者が「ちょっと待って、一斉にあれこれ言わないで！」と悲鳴を上げるシーンもあった。さらに競技が佳境に入った後半には、シフトが全員一通り回ってしまったこともあって、「交代の人が来なくて引き継げないんです……」という事態まで発生。やむなく有志（“ババ”を引いてしまった人、とも表現できる）が作業する時間帯もあった。