Devsumi2016に行ってきました（１日目）

資料等は以下にまとめられています。

codezine.jp

【DevOps時代に明日から活かせるセキュリティ対策術】

OWASP Japanの方のお話です。

●OWASPとは？

• ウェブを取り巻く問題を解決するための国際的な非営利コミュニティ
  • 日本では各地で３ヶ月に１度の頻度で勉強会を開催。

●セキュリティ対策に関する２つの勘違い

• セキュリティ対策は難しい
• セキュリティ対策は後回しにしてよい

●なぜセキュリティ対策は難しいと考えられがちなのか？

• システム固有のビジネスロジックに加え、OSI参照モデルの第１～７層までの理解が必要。

• 攻撃者は効率性を重視し、楽な対象から狙う。

  • 攻撃にかかる負担やコストを高める「ちょっとしたセキュリティ意識」だけでよい。
  • ガチガチにやりすぎると、逆に「ハックしてやろう」という意識をあおるｗ

●なぜセキュリティ対策は後回しにされがちなのか？

• 機能要件、UIはユーザ満足に直結するが、「２段階認証だから使おう」というユーザは少ない。
• セキュリティ対策は品質の１要素に過ぎない
  • 付加価値であり、実装は任意

違う！ということで以下の例。

SQLインジェクション対策もれの責任を開発会社に問う判決 | 徳丸浩の日記

●効率的なセキュリティ対策を実現するには

• 設計・開発工程でセキュリティ対策するのが最も効果が高い
• 設計・開発工程でセキュリティ対策するのが最も安い

セキュリティ対策の鍵はプログラマ、アーキテクト、ひいてはプロジェクトマネージャが握っている！

●OWASPの成果物をどう使うか？

• OWASP Top10
  • ウェブアプリにおける10大脆弱性の学びに。
  • 簡単に取り組むなら「既知の脆弱性を持つコンポーネントの使用」
  • セキュリティのエキスパートと一般ユーザの一番の違いは「使用しているソフトウェアのアップデートをしているか」
• OWASP Cheat Sheet Series
  • セキュリティの教本の集合体。
  • 全部英語ですが…
    • 日本語版を公開中です！
• JPCERTがCheat Sheet Seriesの翻訳を調達中
• OWASP Proactive Controls
  • ウェブ開発時に考慮したい10のセキュリティ対策を紹介
  • Cheat Sheet Seriesと併せてセキュリティ対策ができる
• OWASP ASVS
  • 自身が所属する組織におけるセキュリティの取り組みのガイドライン
  • 簡単に取り組むことができて効果が高いのはV1とV19
  • こっちもJPCERTが翻訳を調達中
• OWASP ZAP
  • 初学者にも玄人にもウケがよい脆弱性診断ツール

とりあえず、CheatSheetSeriesを会社で読ませたい。

「ちょっとのセキュリティで攻撃者はめんどくさくて次に行く」の言葉が残った。

たしかに、SMTP-AUTHやプロキシのアカウントをハックするぐらいなら、オープンのサーバを探すわな。 20年ぐらい前の自分もそうしてたし。

【データ分析で始めるサービス改善最初の一歩】

IIJの入社２年目の方です。

●IIJ GIOストレージ＆アナリシスサービス

• S3互換のストレージとHiveによる解析機能。

●これまでの運用

• 単発の障害検知を目的にした監視システム
  • ping,snmp等
  • munin
  • エラーログ収集

• ユニットテスト、結合テスト中心の児童課

  • 定常的なパフォーマンス計測については手薄

• サービス利用の全体傾向をつかむこと、ができていなかった。

  • 障害の全体像
  • 需要予測がしづらい
  • 予防的なパフォーマンス改善ができない →ログを収集・分析することで実現する！

●ログ収集と可視化

利用傾向をつかむために

• 手始めにログ収集・可視化に取り組む
  • Flumeでログ収集
  • Elasticsearchへの蓄積、Kibanaで可視化

●問題点

• ログの量が多い
  • １日20GB
    • １年7TBOver…
  • そのままでは長期間のログ保管ができない
• 「有用」なログの選別がつらい
  • モジュールごとにフォーマットや取得できる値がバラバラ
  • スタックトレースが吐かれているものも…

●対策：収集するログを絞る

• Apacheアクセスログのみ
  • ユーザの利用傾向をつかむには十分
  • ログの大部分はアプリのトレースログだったので捨てた
• FlumeにEsperを組み込んで集約
  • サイバーエージェントの事例を参考にした。

●Esperとは？

• CEP（複合イベント処理）エンジン
  • SQLライクなイベントデータの操作が可能
• ログ集約に活用
  • 一定時間ごとにログを集計し、アクセス総件数や処理時間の最大値・平均値などを計算
• Elasticsearchには集計した値のみ投入
  • FlumeのInterceptorでEsperを動かすようにカスタマイズし、ログの量を1／10程度にした

●Kibanaで可視化

これは楽でした。

• HTTPメソッド、処理時間などを集計
• 可視化する項目を選ぶ際に試行錯誤
  • Kibanaで可視化するためにMappingTemplateを設定する必要がある
  • 項目の選択、可視化を繰り返して有用な可視化対象の項目を探した。
• Indexの定期的な削除が必要
• ログ集約の結果、分布図が書けなくなった…
  • 集計してから投入したんだから当たり前だよね…

●現在

• アクセス傾向はつかめるようになった
• ログの収集・可視化は簡単だが、収集することを前提に。
  • 収集する前提でログフォーマットを検討

●可視化したが…

• 可視化だけでは不足
  • 人の目で判断
  • 情報が落ちている

●次の一歩

• ログを全量手に入れることで分析できたが
  • まだ属人性が高い
    • 観点などは経験者の目が頼り。
• 判断まで自動化し、属人性を排除する。

●異常値の検出

• シンプルな指標値では顧客環境によるばらつきが大きく、検出できなかった。
• 方針転換
  • 機械学習のアルゴリズムを使う
  • 閾値による検出からユーザ利用傾向の変化へ

●解析してみて

• サービスを包括していろいろ計れるようになった。
• 大変なのはデータの用意と読み解き方
  • アルゴリズムの試行錯誤が必要

ログがあると全ての項目を見たくなるのはよくわかります。

捨てる勇気も大事ですね。

【SparkやBigQueryなどを用いたモバイルゲーム分析環境】

ランチセッションなのでまったり聞く。

●分析環境

AWSおよびGCPで構成されています。

●用途

• BIツール（Cynapse）
  • KPIを可視化し、施策に役立てています（自社ツール）
• アドホック分析（エンジニア）
  • 過去ログの集計
  • RDBでは処理が難しい大量データの集計
• アドホック分析（アナリスト）
  • ユーザ行動分析
  • テキストマイニング

大量データの転送と集計にこんなやり方をしているそうです。

http://qiita.com/yuichi_komatsu/items/3aae65c362b2a57f6fbfqiita.com

午後はPivotalLabsの見学に行くので、今日はここで離脱。