#ssmjp ～腹を割って話そうスペシャル～ でのパネルディスカッション発表資料です。 http://ssmjp.connpass.com/event/8615/ ゆるりとした会場の雰囲気にあわせた資料となっております。ご理解いただければ幸いです:-) 2014-12-03: 当日発表では使わなかった「なぜ、セキュリティインシデントは発生するか」を追記したものを再アップしました。

1. Operation Lab
運用設計ラボ
腹を割って話そう (運用×セキュリティ)
運用設計ラボ合同会社
シニアアーキテクト 波田野 裕一
2014-10-27
#ssmjp ～腹を割って話そうスペシャル～

2. 業務歴
‣ ADSLキャリアで開通業務、ATM運用、ISP運用および障害監視を担当
‣ SIerで公共系サービスのサーバ保守
‣ ASP でミドルウェアおよび障害監視システムの設計構築運用
‣ 運用設計ラボを設立。主にドキュメンテーション活動。
「レガシー運用」に詳しい人
Operation Lab
運用設計ラボ
自己紹介
波田野 裕一 (HATANO Hirokazu)
運用設計ラボ合同会社 シニアアーキテクト
参加コミュニティ
✦ Sphinx Users-jp 会長 (2014年度)
✦ 日本UNIXユーザ会(jus) 幹事 (副会長)
✦ IPv6普及・高度化推進協議会 (サブWG 部会長 共同)
✦ Internet Week プログラム委員
✦ Internet Conference 実行委員
✦ BSD / OSS / JANOG

3. 最近の主張: 設計の無い「自動化」は自滅への道
運用の自動化は、「客観化の結果」であって「目的」ではない。
Operation Lab
運用設計ラボ
目的: 「自分達のやっていることの品質安定化&永続化のために」、
手段: 自動「客観化(構造化)された業務の一部」を自動化する。
「目的と手段がひっくりかえる」ことは、よくある
「自動化が目的」の弊害
• 「自動化された業務」の保守が属人化する。
• 「自動化された業務」の仕様が不明になり、業務プロセスが硬直化する。
• 「自動化された業務」でトラブルが発生すると、手動ではリカバリができない。(手
順がわからない)

4. 業務が複雑化
Operation Lab
運用設計ラボ
運用現場の諸問題
1.高負荷
2.属人的
3.見えぬ費用対効果
ブラックボックス化
低付加価値化
「費用」は一定で「効果」は経年劣化する
「費用対効果」は勝手に低減していく現場では制御不能状態
クラウド時代の運用は、美しいといいなぁという期待

5. Operation Lab
運用設計ラボ
運用現場の諸問題詳しくは

6. Operation Lab
運用設計ラボ
「セキュアな運用」を追い求めて

7. 昨年春あたりからセキュリティ事故に変化
Operation Lab
運用設計ラボ
• ガチ攻撃の多発 (経済事犯)
• ゴルゴ13に狙われたら死亡確定
• 片手間で対応無理
「セキュリティは運用の一部」に

8. Operation Lab
運用設計ラボ
「セキュアな運用」を追い求めて
「セキュアな運用」とは
• セキュアとは
• 安全な、不安の無い、保障された、頑丈な、などの意味
• 「セキュアな運用」とは
• 安全な、不安の無い、保障された、頑丈(ロバストネス)な運用
そのイメージは運用現場それぞれで異なる。(共通認識が重要)
• 365日24時間の事業継続性 (全ステークホルダーに重要)
• 現場にとって安全 (不安が無い、ムリが無い。)
• 利用者にとって安全 (不安が無い、ムラが無い。)
• 経営者にとって安全 (不安が無い、ムダが無い。)
• 監査者にとってモレが無い。
「ムリ、ムラ、ムダ、モレ」が無い運用

9. Operation Lab
運用設計ラボ
「セキュアな運用」とは
• 現場にムリが無い運用。
• 利用者にはムラが無い運用。
• 経営者にはムダが無い運用。
• 監査者にはモレが無い運用。

10. Operation Lab
運用設計ラボ
「セキュアな運用」とは
• 現場にムリが無い運用。
ISMSって (ry

11. Operation Lab
運用設計ラボ
「セキュアな運用」とは
• 利用者にはムラが無い運用。
(声) 一部だけセキュアでもダメでしょ

12. Operation Lab
運用設計ラボ
「セキュアな運用」とは
• 経営者にはムダが無い運用。
「それって費用対効果(ry」
これはすごく重要
「運用の価値」が理解されていない

13. Operation Lab
運用設計ラボ
運用ドキュメントを作る時間が…
インターネット運用は「安く、手間をかけず」が特徴で、
運用設計とドキュメンテーションがないがしろにされてきた。
(企業の大小、社歴の長さを問わず)
セキュリティについて作り込む時間が…
インターネット運用は「安く、手間をかけず」が特徴で、
セキュリティがないがしろにされてきた。
(企業の大小、社歴の長さを問わず)
同じ構図!

14. Operation Lab
運用設計ラボ
「セキュアな運用」とは
• 監査者にはモレが無い運用。
運用業務を理解している監査者って(ry
逆に、監査者が理解できる運用をしている?

15. Operation Lab
運用設計ラボ
「セキュアな運用」とは (再)
• 現場にムリが無い運用。
• 利用者にはムラが無い運用。
• 経営者にはムダが無い運用。
• 監査者にはモレが無い運用。
上手い… >
(会場からの声)

16. 「セキュアな運用」を追い求めて
「セキュアな運用」の実現
• セキュリティを独立に考える時代は終了
• セキュリティを事前に組み込んだ運用設計。
• 片手間で対応無理。通常運用の一部に。
Operation Lab
運用設計ラボ
「セキュリティは運用の一部」に
運用現場も考え方を転換する必要が

17. 「セキュアな運用」を追い求めて
• 一番怖いのは内部からの偶発事故
• オンプレミスをやめちゃう(とか)
• クラウドは全てが外になる。全方向一定強度。
Operation Lab
運用設計ラボ
「セキュアな運用」の実現
運用現場も考え方を転換する必要が

18. Operation Lab
運用設計ラボ
「セキュアな運用」とは (再)
• 現場にムリが無い運用
• 利用者にはムラが無い運用
• 経営者には費用対効果が説明できる運用
• 監査者にも理解が可能な運用

19. Operation Lab
運用設計ラボ
「セキュアな運用」を追い求めて
運用設計してますか?

20. 運用現場の現実
業務が複雑化
ブラックボックス化
Operation Lab
運用設計ラボ
運用設計とは
運用現場の「理想」と「現実」の橋渡し
運用現場の理想
‣ サービスの安定
社会基盤に相応しい安定運用。
‣ 業務負荷の平準化
うまく業務が回る運用現場。
‣ 運用に対する評価の適正化
適正な利潤を生む現場と、適切に評価される要員。
1. 高負荷
2. 属人的
3. 見えぬ費用対効果
低付加価値化
「セキュアな運用」を追い求めて

21. 「セキュアな運用」を追い求めて
ステークホルダーの「期待」を実現することで運用の評価は高まる。
Operation Lab
運用設計ラボ
「運用の理想」とは
運用現場の理想
‣ サービスの安定
社会基盤に相応しい安定運用。
‣ 業務負荷の平準化
うまく業務が回る運用現場。
‣運用に対する評価の適正化
適正な利潤を生む現場と、適切に評価される要員。
運用への
期待
ユーザ
経営者
運用
マネージャ
オペレータ監査者
ユーザの理想
‣ サービスの安定
社会基盤に相応しい安定運用。
‣ サービスの費用対効果
コストに見合ったプロフィット。
‣ サービスのプラスα
期待を超えるベネフィット。
仮説: 「ステークホルダーの期待を実現すること」が「運用の理想」

22. 「セキュアな運用」を追い求めて
運用設計とは何か
運用現場の理想運用設計の目的
常にシンプル
テキストを入力してください
運用現場の現実
1. 高負荷
業務が複雑化
2. 属人的
ブラックボックス化
3. 見えぬ費用対効果
低付加価値化
1. 業務の複雑化を許さない仕組み
作り
2. 業務のブラックボックス化を許
さない仕組み作り
常に見える
3. 業務価値の陳腐化を許さない仕
組み作り
‣ サービスの安定
社会基盤に相応しい安定運用。
‣ 業務負荷の平準化
うまく業務が回る運用現場。
‣ 運用に対する評価の適正化
適正な利潤を生む現場と、適切に評価される要員。
1.「運用」への期待の明確化
常に価値を生む
2.「運用設計」の確立
3. 期待に対する消費リソースの測定化
出典: Think IT 「現場視点からの運用方法論 第2回 自分たちの「運用」を知る - 運用設計の本質」(2010-12)

23. Operation Lab
運用設計ラボ
詳しくは

24. 業務価値の陳腐化
を許さない仕組み作り
「セキュアな運用」を追い求めて
常にシンプル常に見える常に価値を生む
管理会計/経営学
Operation Lab
運用設計ラボ
セキュア運用設計とは
運用現場の「理想」と「現実」の橋渡し
業務の複雑化
を許さない仕組み作り
業務のブラックボックス化
を許さない仕組み作り
工学的な客観化(業務の「構造化」「数値化」)
安全で不安の無い、頑丈(ロバストネス)な運用
「ムリ、ムラ、ムダ、モレ」が無い運用

25. Operation Lab
運用設計ラボ
余談: PDCAしてますか?

26. 「セキュアな運用」を追い求めて
ちゃんとサイクルしている現場を聞いたことないです
Operation Lab
運用設計ラボ
PDCAしてませんよね?
• P: プランを立てて、 <<計画>>
• D: だましだまし「やってみた」けど、 <<実施>>
• C: 「ちょっと忙しく」って、 <<停滞>>
• A: 「あれ? どこまでやってたんだっけ?」 <<終了>>

27. 「運用の効率化」が可能
運用の評価適正化
Operation Lab
運用設計ラボ
PDCAからPDSへ
日本人はPDSサイクルで!
3. 諸問題の解消へ
2.「運用設計」の確立
運用実績の測定可能化
「やらないこと」の明確化
本当に必要な運用基盤の整備
3. 期待に対する消費
リソースの測定化
より高度な「期待」の醸成
適切な運用設計が可能
1.「運用」への期待の
明確化
慢性的なリソース不足が解消
慢性的な業務バーストが解消
Do
運用への
期待
Plan See
出展: Internet Week 2009 「運用方法論 システム運用現場の現状分析 そして運用設計へ」 (2009-11)

28. Operation Lab
運用設計ラボ
さて、「監査」と「運用」

29. さて、「監査」と「運用」
「監査」って敵(enemy)ですか?
Operation Lab
運用設計ラボ
心情的にはYes
将来的にはNo

30. さて、「監査」と「運用」
なぜ監査が必要なのか? (従来からの視点)
業務を適切にマネジメントできているか「説明するため」
監査 (外部監査)
Operation Lab
運用設計ラボ
ユーザ
経営者
運用
マネージャ
運用への
期待
オペレータ監査者

31. さて、「監査」と「運用」
運用における「マネジメント」の3要素 (仮説)
マネジメントとは、把握して、判断して、(自力、他力で)制御すること。
Operation Lab
運用設計ラボ
マネジメントとは、(本当は)統制ではない。
セキュリティマネジメント
1. 脅威を把握して、判断して、制御する。
2. 脆弱性を把握して、判断して、制御する。
3. リソースを把握して、判断して、制御する。
サービスマネジメント
1. サービス障害の影響を把握して、判断して、制御する。(サービス設計)
2. サービス障害の可能性を把握して、判断して、制御する。(プロアクティブ)
3. サービス障害の発生を把握して、判断して、制御する。(リアクティブ)

32. Operation Lab
運用設計ラボ
さて、「監査」と「運用」
なぜ監査が必要なのか? (現場視点)
ユーザ
「運用への期待」との「ギャップを知るため」
監査 (自己監査)
経営者
運用
マネージャ
運用への
期待
オペレータ監査者

33. さて、「監査」と「運用」
レビュー(監査)を前提とした運用設計ライフサイクル
リスクマネジメント
運用/システム設計
リスクマネジメント監査 (レビュー)
3. 諸問題の解消へ
Operation Lab
運用設計ラボ
3. 制御
Do
運用への
期待
Plan See
1. 把握
2. 判断
セキュリティ
監査を前提として客観化していないサービス設計は
内部的にも外部的にも評価ができない。

34. さて、「監査」と「運用」
監査監査 (自己監査: セルフレビュー)
監査 (外部監査: 第三者レビュー)
Operation Lab
運用設計ラボ
仮説: セキュリティマネジメントの3要素
リスクマネジメント
情報資産管理
リスク評価
リスク戦略
サービス設計運用設計システム設計
1. 把握
2. 判断
3. 制御

35. さて、「監査」と「運用」
「監査」は「把握するため」に必要
「運用への期待」との「ギャップを知るため」
業務を適切にマネジメントできているか「説明するため」
Operation Lab
運用設計ラボ
なぜ監査が必要なのか?
監査監査 (自己監査: セルフレビュー)
監査 (外部監査: 第三者レビュー) 1. 把握
「監査」という言葉が、強圧的で良くない。
「レビュー」という意味に近い日本語の登場が待ち望まれる。

36. Operation Lab
運用設計ラボ
「運用価値」の表現へ

37. Operation Lab
運用設計ラボ
「運用価値」の表現へ
運用研究から見えてきた「運用の未来」
ITサービス運用に関しては、科学的客観的な業務設計と、
各業務の反復性再現性が重要になる。(2009)
「運用」抽象化への視点
• ITサービスにおける「運用」とはサービスデリバリである。(2009)
• QCDによる科学的客観的評価 (費用対効果の測定可能化)
• サービス手段よりもサービス目的にフォーカス (よりユーザ視点に近い)
• 運用組織は分散協調(API)モデルである。(2009-2010)
• 疎結合な組織設計、業務設計
• 業務処理を隠蔽化し、組織間コミュニケーションを定型化
• 業務における責務の集中
• 運用業務とは工程(UNIXにおけるパイプ処理)である。(2010)
• 工程設計が適切であれば、処理の定型化、多重化が容易に (脱属人化、脱高負荷)
• 工程設計が適切であれば、コードに落し込みがしやすい

38. 構造化ここでは「エンジニアリング(工学)の実践」に近い意味で使います。
工学では何らかの構造物・構造体を作ることが不可避なためです。
Operation Lab
運用設計ラボ
主張: クラウド時代の運用設計
「問題を根性で解決するのは馬鹿です。
問題をエンジニアリングで解決するのが
エンジニアの仕事です」
@yoshiori
http://d.hatena.ne.jp/Yoshiori/20120217/1329491437
「運用価値」の表現へ

39. Operation Lab
運用設計ラボ
「運用価値」の表現へ
主張: クラウド時代の運用設計
運用の構造化
エンジニアリング(工学)の実践
「運用価値」を構造的に表現する
エンジニアリング(定量評価)で
運用工程の実績を示す技術者を
エンジニアと言う

40. 「運用価値」の表現へ
エンジニアリング(定量評価)で
運用工程の実績を示す技術者を
エンジニアと言う
‣ 運用に対する評価の適正化
適正な利潤を生む現場と、適切に評価される要員。
Operation Lab
運用設計ラボ
現在: 家内制手運用の時代
今後: 大規模大量運用の時代

41. ‣ 運用に対する評価の適正化
適正な利潤を生む現場と、適切に評価される要員。
クラウドなら客観数値が取れるんじゃ?
Operation Lab
運用設計ラボ
「運用価値」の表現へ
エンジニアリング(定量評価)で
運用工程の実績を示す技術者を
エンジニアと言う

42. Operation Lab
運用設計ラボ
まとめ (運用×セキュリティ)

43. Operation Lab
運用設計ラボ
まとめ (運用×セキュリティ)
セキュリティマネジメント
1. 脅威を把握して、判断して、制御する。
2. 脆弱性を把握して、判断して、制御する。
3. リソースを把握して、判断して、制御する。
監査監査 (自己監査: セルフレビュー)
監査 (外部監査: 第三者レビュー)
‣ 運用に対する評価の適正化 (運用価値)
適正な利潤を生む現場と、適切に評価される要員。

44. なぜ、セキュリティインシデントは発生するか?
Operation Lab
運用設計ラボ
おまけ

45. なぜ、セキュリティインシデントは発生するか?
社会的な前提条件をリセットして考えることは重要。
Operation Lab
運用設計ラボ
• 仮説: セキュリティインシデント発生の3要因
• 仮説: リソースに関する三原則
• 仮説: セキュリティマネジメントの3要素 (再)

46. なぜ、セキュリティインシデントは発生するか?
仮説: セキュリティインシデント発生の3要因
Operation Lab
運用設計ラボ
1. リソースを持ってるから
2. リソースに対する脅威が存在するから
3. リソースに脆弱性が存在するから

47. なぜ、セキュリティインシデントは発生するか?
なぜ、セキュリティインシデントは発生するか?
Operation Lab
運用設計ラボ
仮説: リソースに関する三原則
1. リソースを持ってるから
リソースに関する三原則
第一原則: リソースを持たない
第二原則: リソースを置かない (どうしても持つ必要がある場合)
第三原則: リソースに触わらせない (どうしても置く必要がある場合)

48. Operation Lab
運用設計ラボ
なぜ、セキュリティインシデントは発生するか?
仮説: リソースに関する三原則
第一原則: リソースを持たない
リソースを持つこと自体がコスト/リスクである
持たなければ「やられない」
第二原則: リソースを置かない (どうしても持つ必要がある場合)
リソースを隔離する。
置かなければ「触われない」
第三原則: リソースに触わらせない (どうしても置く必要がある場合)
リソースにアクセス制御を適用する。
最小限しか「触われない」はず

49. なぜ、セキュリティインシデントは発生するか?
仮説: セキュリティマネジメントの3要素 (再)
監査監査 (自己監査: セルフレビュー)
監査 (外部監査: 第三者レビュー)
Operation Lab
運用設計ラボ
リスクマネジメント
情報資産管理
リスク評価
サービス設計運用設計システム設計
1. 把握
2. 判断
3. 制御
リスク戦略

50. Operation Lab
運用設計ラボ
なぜ、セキュリティインシデントは発生するか?
まとめ
セキュリティマネジメントの3要素
リソースに関する三原則
第一原則: 持たない
第二原則: 置かない
第三原則: 触わらせない
1. リソースを持ってるから
2. リソースに対する脅威が存在するから
3. リソースに脆弱性が存在するから
セキュリティインシデント発生の3要因
組合せ
セキュリティマネジメントの全体像

51. Opera運t用io設n計Lab
Operation Lab
運用設計ラボ
http://www.operation-lab.co.jp/