セキュリティ・ミニキャンプ in 北海道 2016に参加してきた

セキュリティキャンプ

はじめに

2016年11月5日・6日に北海道大学で開催された「セキュリティ・ミニキャンプ in 北海道 2016」にチューターとして参加してきました。

ハードウェアを直接いじくる講義や、法や倫理に関する演習まで幅広い6つの講義が行われ、低レイヤ一色だったおととしや、高レイヤ一色だった昨年とはまた違ったキャンプだったと思います。

この記事では内容についてダイジェストでお伝えしつつ、(もしあれば)来年の参考になどしてもらえればありがたいなと思っています。

それでは早速、お楽しみください。

開催概要

2日間にわたって行われたミニキャンプは、以下のような段取りで行われました。

  • 11月5日
    1. セキュリティ・キャンプ全国大会へ行こう（上野先生）
    2. セキュリティ基礎（園田先生）
    3. スマホゲームでサーバサイドアプリケーションへの攻撃と対策を学ぼう（岸谷先生）
    4. (夕食)
    5. 若者相手のネットワークと法・倫理問題（町村先生）
    6. (ホテルでお泊まり)
  • 11月6日
    1. クラウドセキュリティ基礎（仲山先生）
    2. (昼食)
    3. Linuxによるハードウェア制御の初歩（竹岡先生）

チューターとして参加して

ひょんなことから拾っていただき、昨年に引き続きチューターを担当することができました。まず拾っていただいたことに感謝感謝です。

開催中はチューターのA氏がチューター慣れしている感じがにじみ出ていて、とてもいい影響を受けることができました。もし、次の機会があれば今回ちょっと反省している(気が利いてないなと思った)点については改善したいです。

反省は反省として、グループワークなどの議論をひっかき回しに行ったり、演習でうまくいっていない点をカバーしに行ったり、グループを横断的に見ることができるのはチューターの特権なのかなと。参加者の立場だと課題に取り組むのに精一杯で、他グループの人との交流がおろそかになりがちですが、チューターという立場を利用して逆にいろいろな柔軟な考えに触れて、吸収することができたのかなと感じています。

今回のキャンプはハプニングの連続で一時はどうなることかと思いましたが、それでもきちんと運営していて大人の方々のエラーハンドリング技術にはただただ驚くばかりでした。この知見は、自分が運営している様々なイベントでも生かせるようになりたいと考えています。

そういうわけで今回はチューターとして参加できて本当に良かったと思います。全国大会経験者はぜひ応募してみると、新たな知見に満ちあふれていて面白いですよ！

講義について

ここからは講義の内容をダイジェストでお伝えします。ダイジェスト(?)ですのであしからず。

セキュリティ・キャンプ全国大会へ行こう

上野先生による、全国大会の紹介です。全国大会への応募について、また全国大会でどんな講義が行われたかについてのお話がありました。

応募用紙は知識量よりも「セキュリティについての知識欲」や「参加したいという熱意」を見ているという大事なお話がありました。

また全国大会では日本はもとより世界で活躍するセキュリティのスペシャリストが講義を担当していると紹介していました。

セキュリティ基礎

園田先生のセキュリティ基礎です。毎年恒例のグループワークで、特定のテーマについてグループで話し合ってその結果を発表します。今年は園田先生が地方でIoTを活用する活動を始めたことから、IoT機器の安全性についてというテーマでディスカッションを行いました。

先月末DDoS攻撃の発生源として話題になったMiraiを例に、IoT機器が狙われているという背景から、ではどのようにすればセキュリティを向上できるか各グループで議論が交わされました。

IoT機器への攻撃はTelnetを狙った23番ポートへの攻撃がほとんどである、というヒントから話が発展していき、多くのグループから「TelnetではなくSSHを使うべきではないか」とか「23番ポートをどこか別のポートに移してはどうか」といった意見が出ました。一方で、「物理的に部屋に侵入されて悪意のあるファームウェアを直接書き込まれたりしないか」とか「どうしてIoT機器でSSHが一般的ではないのか」といった疑問も出されました。

スマホゲームでサーバサイドアプリケーションへの攻撃と対策を学ぼう

岸谷先生による、サーバーサイドアプリケーションの脆弱性に関する講義です。

まず、サーバーサイドアプリケーションの基本について学びました。現在のスマホアプリはゲーム画面を表示するクライアント部分と、データを取り扱うサーバー部分に分かれており、今回は後者についてのセキュリティを学んでいくという説明がありました。

サーバー部分に対して脆弱性があると、ユーザー側に本来見えてはいけないデータが表示されるような危険性があるという解説の後、実際にAPIに対して実行可能なJavScript文字列を送信し、それを実行させるというデモを見ました。

「プログラムは考えたとおりではなく書いたとおりに動く」という格言を紹介していただき、脆弱性を見つけ出すためには自分が考えたロジックが脆弱ではないかどうかについて検証する必要があるとも解説されていました。

さらに脆弱性診断についても触れていました。脆弱性診断士は攻撃者視点でテストすることが重要で、発見した脆弱性の影響や対策方法について報告する仕事であると説明されていました。また脆弱性を一般のユーザーから募るバグバウンティ制度についても説明がありました。

最後に脆弱なサーバーサイドアプリケーションを持つスマホゲームを題材に、脆弱性を突いてチートを行う演習を行いました。Burp Suiteを用いてスマホアプリから送られるHTTP Requestを改竄してサーバーに送ったり、サーバーから送られてきたResponseを改竄してクライアントに受け取らせたりしつつ、ゲームに勝てるよう各グループが試行錯誤をしていました。

若者相手のネットワークと法・倫理問題

町村先生による、法や倫理に関する講義です。様々な「ジレンマ」の状況から、情報技術を用いる者としての法や倫理の問題を考えていく技術中心の他の講義とは毛色の違う講義でした。

初めに考えたのは「トンネル内で自動運転車が人を轢きそうになったときに人を轢くか車を壁に当てるか」というジレンマでした。意見はおおよそ2等分に分かれ、それぞれが「自動運転でも運転手が責任が負うべきだから人を轢くべきではない」とか「自動運転車を買う人は自分が安全であると考えているはずだから車は運転手を守るべきだ」などという意見が出されました。

「カルネアデスの板」と呼ばれる問題から緊急避難についても考えました。この問題については、日本では刑法で自己に危険が迫っていて緊急に引き起こしてしまった損害は罰せられないという規定があると言うことを学びました。さらに「自動運転車が直進すると1人を轢いてしまい、避けると5人を轢いてしまう場合はどうすべきか」という問題について取り組みました。この問題ではすべての参加者が1人を轢いた方が良いと答えました。

続いて「Pokémon Go」についての問題についてグループワークを行いました。「プレイしている人としていない人との摩擦」とか「プレイしていいかどうかのTPOをわきまえるべきなのではないか」とか「足跡機能を使ったストーキングが可能なのではないか」といった意見が出されました。

後半は倫理から法律に話題が移り変わりました。まず「著作物とは何か」という問いから始まりました。そしてある著作物に関して5人の行為が著作権を侵害しているかしていないかについて考えました。まとめとして法律や裁判の判決文はパブリックドメインであることや、見出しに創作性がない場合に限って著作権が付与されないという判決が出た「読売Online事件」について学びました。また、ベネッセ情報漏洩事件やSuica情報売却事件をもとに、個人情報の保護についてのお話がありました。

クラウドセキュリティ基礎

2日目の午前は仲山先生によるクラウドセキュリティに関する講義です。まずはサービスの運用についてサイバーエージェントの例をもとに説明されました。売り上げを単純に割り算すると、サービスが停止した場合1分あたり約23万円の損失を出してしまうということを例に、サービスの価値について学びました。

クラウドを用いると、サービスが流行した場合に大量のサーバーが必要になった場合や、逆に縮小したくなった際にすぐ縮小できるなど、そのサービスごとに必要に応じてネットワーク経由ですぐに利用できるメリットがあることを学びました。また、クラウドにはAWSなどのプライベートクラウドと社内で運用されるプライベートクラウドがあり、場合に応じて使い分けていることも説明されました。IaaS(Infrastructure as a Service)についても話があり、自由にサーバーを追加したり削除したりできるようになったことで、減価償却の問題や初期投資の問題を解決できるということです。

ここからは内容が濃かったので章ごとに見ていきます。

ペットから家畜へ

これまではサーバーはペットのように死ぬまで面倒を見るものでしたが、これからは集団として見て個別には面倒を見ず、おかしくなったら殺してしまう風潮であると解説されていました。

ディスカッション「Webシステムのアーキテクチャ」

クラウド環境について、すぐに本番投入するときやサーバーを増やしたり減らしたりするときの準備すべき点について話し合いました。参加者からは以下のような意見が出されました。

  • API Keyの流出による被害
  • 削除したデータが本当に削除されているのか
  • 何台もあるサーバーのうち1台が死んでしまったときにどうするか
  • 動かしたままパッチを当てたりできるLive Migration機能を使ったらどうか
  • クラウドをハイパーバイザで動かしたら良さそう
  • Application Containerについて
  • OSをアップデートしたいときにどうしたらよいか
  • 設定ファイルなどの同期はどうすべきか

参加者からの意見を受けて、「確かにクラウドによってサーバーを用意する手間はかからないけれども、中身をセットアップする手間は今でも変わっておらず、サーバー内のデータをどう取り扱えば良いか考えなければならない」と問題提起がありました。クラウドに合わせたデータの取り扱い方を進めていかないと、かえって高くつくこともあるという注意点もありました。

メリハリを付ける

そういった問題を解決するために、サーバーをStatelessとStatefulの2種類に分けて管理するとよいというお話がありました。

  • Stateless Server
    • 一切データを保存しない
    • アプリを動かすだけ
    • 一度構築した状態で動き続ける
    • Twelve Factor App
  • Stateful Server
    • データを保存しておくだけのサーバー
    • 追加や削除をしづらいので死ぬ気で守る
    • スペックを高めたり、台数を増やして分散させたりする(Load Balancer利用)

Twelve Factor App

アプリケーションを作成するときの哲学として、Twelve Factor Appを読むとよいとおすすめされました。

  • アプリケーション全体がひとつのリポジトリ
  • それ以外は依存ライブラリなど
  • 複数のデプロイ環境を用意
  • 各種設定は環境変数に設定し、ソースコード中には含めない
  • ログはイベントストリームとして扱い、ローカルにファイルを保存しない

Stateful Server…?

Statefulサーバーを作成する際には、以下のようなサービスを(お金の力で)運用するとよいらしいです。

  • 性能に関してはスケールアップで対応(金の弾丸)
  • 分散DB(Cassandra, HBase, MongoDB)
  • すごいストレージサービス(Amazon DynamoDB / Google BigQuery)

Applicataionの脆弱性対策

万が一脆弱性が見つかったときに、いかにサービスを止めずにサーバーを交換する方法について言及がありました。

  • アプリケーションの脆弱性が多いため、いかに迅速に動作確認して適用するかが問われている
    • 新しいバージョンのサーバー群を作って、古いサーバー群を消してしまう
    • Load Balancerで新サーバーにアクセスを切り替える
  • Statefulサービスの脆弱性もある
  • 脆弱性の優先度を決めて対処しよう(Vulsなどで優先度を付ける)

クラウドの管理

APIキーをGitHubにお漏らししてしまった事件などから、管理は最小権限でかつなるべく自動化してというお話でした。

  • Control Panelは人が操作する。すなわち、ミスをする。
  • API使って自動化しよう！
  • API Keyが漏れると何でもできちゃうよね
    • 最小権限の原則
    • 操作内容の記録

PaaS

  • 餅は餅屋システム
  • ありものを組み合わせる
  • 一見コストが高く見えるが、最適化できるとコスト減も可能
    • 自分たちでやると給料が発生するが、サービスでやってもらえばかえって安いことも

AWS

  • 世界最大規模のクラウド
  • PaaSが多いけどIaaSもあるよ
  • AmazonはOSから下の責任を持つ
  • Regionたくさん
  • 複数のAvailability Zoneにデータを置いておかないと落ちても知らないよ？

AWSの冗長化

  • LBやNoSQLはサーバーという概念がなく、AZを意識せず既に冗長化されている

インフラのコード化

  • サーバー構成をコードに書き起こす
  • Terraform
    • AWSやAzureの構成をコードで管理できる
  • HashiCorp
  • PullReqなどでインフラ構成を改良できる
  • サーバー本体の管理はできるけれども、中身の管理は…?

サーバー構成管理

  • 昔は職人芸、今は構成管理ツール(Puppet, Chef, Ansible)が流行っている
  • 構成管理ツールは冪等性を担保してくれる
  • 最新のやり方はアプリケーションコンテナ(Docker)
    • OSからミドルウェア、アプリケーション本体までまるっと入っている
    • 機動に必要なコマンドラインやポートフォワーディングもOK
    • 全部入りだから冪等性も考える必要性がないし、管理はシェルスクリプトで十分

application PaaS (aPaaS)

  • 要するにHeroku
  • Dockerコンテナを動かせちゃう

Serverless Architecture

  • フルマネージドなPaaSの発展系
    • サーバーまで含めてアプリケーションと考える
    • 自動でスケールが調節される
  • Amazon Lambda
    • プロセスが利用できる最大メモリ量まで指定可能
    • 100ms単位で消費時間によって課金
  • Statelessなサーバーにしか使えない
    • いつ増えて減るかは全くわからない
    • サーバーが消えるとデータも消える
    • Statelessという制約を受け入れることでフルマネージドというメリットが受けられる
  • 大きなアプリケーションサーバーがあった時代から、マイクロサービスへの転換
  • 通信も同期型通信から非同期型通信へ
    • WebSocketなどの普及で、ブラウザでも非同期通信が簡単に
  • リアクティブアーキテクチャ
  • 動かしたいのはサービスであってサーバーではない

セキュリティ

  • これまで
    • 大きなアプリの中身に侵入
  • これから
    • 小さなアプリなので、実装レベルの脆弱性は減少(してほしい)
    • コンポーネントの利用方法による脆弱性
    • コンポーネント単位の認可が重要に

おわりに

  • Amazonがクラウドサービスを初めてまだ10年
  • ベストプラクティスがこれからどんどん変わっていく可能性
  • 動きが速くて面白いね
  • 無料枠や、時間を短く使って安く済ませてとにかく手を動かせ！
  • ブログや勉強会、同人誌で情報を発信しよう

Linuxによるハードウェア制御の初歩

本当は1日目の予定でしたが、色々ハプニングがあって最後の講義となりました。内容としては、Raspberry Piを使って

  • LEDの点滅
  • スイッチの認識
  • モーターの制御

を実装するという講義でした。

いきなりのハードウェアで戸惑った人もいれば、いつも実験でやっているからと慣れた手つきで進めている人もいて、慣れている人がそうでない人にやり方を伝授するなど参加者同士での交流も最も賑わった講義だったと思います。

Raspberry Piとのネットワーク接続がうまくいかなかったりなど実習中もいろいろなハプニングが起きましたが、結果的に全員がモーターの制御までたどり着いて、充実した様子だったのでほっとしました。

おわりに

とにもかくにも参加された学生の皆さん、お疲れ様でした。個人個人、得た物は様々だったでしょうが、その知見を持ち帰って自分の中でかみ砕いて吸収してくれると、どちらかというとスタッフ側にいた人間としてはうれしい限りです。

最後になりますが、開催に関して尽力された実施協議会やIPAの方々、刺激的な講義をしてくださった講師の方々、参加者の皆さんを支えてくださったサポーターの方々、チューターの2人、そして何より参加してくれた25名の皆様、本当にありがとうございました。またの機会に、生きて会いましょう！

 Share!