SlideShare a Scribd company logo
Operation Lab 
運用設計ラボ 
腹を割って話そう (運用×セキュリティ) 
運用設計ラボ合同会社 
シニアアーキテクト 波田野 裕一 
2014-10-27 
#ssmjp ~腹を割って話そうスペシャル~
業務歴 
‣ ADSLキャリアで開通業務、ATM運用、ISP運用および障害監視を担当 
‣ SIerで公共系サービスのサーバ保守 
‣ ASP でミドルウェアおよび障害監視システムの設計構築運用 
‣ 運用設計ラボを設立。主にドキュメンテーション活動。 
「レガシー運用」に詳しい人 
Operation Lab 
運用設計ラボ 
自己紹介 
波田野 裕一 (HATANO Hirokazu) 
運用設計ラボ合同会社 シニアアーキテクト 
参加コミュニティ 
✦ Sphinx Users-jp 会長 (2014年度) 
✦ 日本UNIXユーザ会(jus) 幹事 (副会長) 
✦ IPv6普及・高度化推進協議会 (サブWG 部会長 共同) 
✦ Internet Week プログラム委員 
✦ Internet Conference 実行委員 
✦ BSD / OSS / JANOG
最近の主張: 設計の無い「自動化」は自滅への道 
運用の自動化は、「客観化の結果」であって「目的」ではない。 
Operation Lab 
運用設計ラボ 
目的: 「自分達のやっていることの品質安定化&永続化のために」、 
手段: 自動「客観化(構造化)された業務の一部」を自動化する。 
「目的と手段がひっくりかえる」ことは、よくある 
「自動化が目的」の弊害 
• 「自動化された業務」の保守が属人化する。 
• 「自動化された業務」の仕様が不明になり、業務プロセスが硬直化する。 
• 「自動化された業務」でトラブルが発生すると、手動ではリカバリができない。(手 
順がわからない)
業務が複雑化 
Operation Lab 
運用設計ラボ 
運用現場の諸問題 
1.高負荷 
2.属人的 
3.見えぬ費用対効果 
ブラックボックス化 
低付加価値化 
「費用」は一定で「効果」は経年劣化する 
「費用対効果」は勝手に低減していく現場では制御不能状態 
クラウド時代の運用は、美しいといいなぁという期待
Operation Lab 
運用設計ラボ 
運用現場の諸問題詳しくは
Operation Lab 
運用設計ラボ 
「セキュアな運用」を追い求めて
昨年春あたりからセキュリティ事故に変化 
Operation Lab 
運用設計ラボ 
• ガチ攻撃の多発 (経済事犯) 
• ゴルゴ13に狙われたら死亡確定 
• 片手間で対応無理 
「セキュリティは運用の一部」に
Operation Lab 
運用設計ラボ 
「セキュアな運用」を追い求めて 
「セキュアな運用」とは 
• セキュアとは 
• 安全な、不安の無い、保障された、頑丈な、などの意味 
• 「セキュアな運用」とは 
• 安全な、不安の無い、保障された、頑丈(ロバストネス)な運用 
そのイメージは運用現場それぞれで異なる。(共通認識が重要) 
• 365日24時間の事業継続性 (全ステークホルダーに重要) 
• 現場にとって安全 (不安が無い、ムリが無い。) 
• 利用者にとって安全 (不安が無い、ムラが無い。) 
• 経営者にとって安全 (不安が無い、ムダが無い。) 
• 監査者にとってモレが無い。 
「ムリ、ムラ、ムダ、モレ」が無い運用
Operation Lab 
運用設計ラボ 
「セキュアな運用」とは 
• 現場にムリが無い運用。 
• 利用者にはムラが無い運用。 
• 経営者にはムダが無い運用。 
• 監査者にはモレが無い運用。
Operation Lab 
運用設計ラボ 
「セキュアな運用」とは 
• 現場にムリが無い運用。 
ISMSって (ry
Operation Lab 
運用設計ラボ 
「セキュアな運用」とは 
• 利用者にはムラが無い運用。 
(声) 一部だけセキュアでもダメでしょ
Operation Lab 
運用設計ラボ 
「セキュアな運用」とは 
• 経営者にはムダが無い運用。 
「それって費用対効果(ry」 
これはすごく重要 
「運用の価値」が理解されていない
Operation Lab 
運用設計ラボ 
運用ドキュメントを作る時間が… 
インターネット運用は「安く、手間をかけず」が特徴で、 
運用設計とドキュメンテーションがないがしろにされてきた。 
(企業の大小、社歴の長さを問わず) 
セキュリティについて作り込む時間が… 
インターネット運用は「安く、手間をかけず」が特徴で、 
セキュリティがないがしろにされてきた。 
(企業の大小、社歴の長さを問わず) 
同じ構図!
Operation Lab 
運用設計ラボ 
「セキュアな運用」とは 
• 監査者にはモレが無い運用。 
運用業務を理解している監査者って(ry 
逆に、監査者が理解できる運用をしている?
Operation Lab 
運用設計ラボ 
「セキュアな運用」とは (再) 
• 現場にムリが無い運用。 
• 利用者にはムラが無い運用。 
• 経営者にはムダが無い運用。 
• 監査者にはモレが無い運用。 
上手い… > 
(会場からの声)
「セキュアな運用」を追い求めて 
「セキュアな運用」の実現 
• セキュリティを独立に考える時代は終了 
• セキュリティを事前に組み込んだ運用設計。 
• 片手間で対応無理。通常運用の一部に。 
Operation Lab 
運用設計ラボ 
「セキュリティは運用の一部」に 
運用現場も考え方を転換する必要が
「セキュアな運用」を追い求めて 
• 一番怖いのは内部からの偶発事故 
• オンプレミスをやめちゃう(とか) 
• クラウドは全てが外になる。全方向一定強度。 
Operation Lab 
運用設計ラボ 
「セキュアな運用」の実現 
運用現場も考え方を転換する必要が
Operation Lab 
運用設計ラボ 
「セキュアな運用」とは (再) 
• 現場にムリが無い運用 
• 利用者にはムラが無い運用 
• 経営者には費用対効果が説明できる運用 
• 監査者にも理解が可能な運用
Operation Lab 
運用設計ラボ 
「セキュアな運用」を追い求めて 
運用設計してますか?
運用現場の現実 
業務が複雑化 
ブラックボックス化 
Operation Lab 
運用設計ラボ 
運用設計とは 
運用現場の「理想」と「現実」の橋渡し 
運用現場の理想 
‣ サービスの安定 
社会基盤に相応しい安定運用。 
‣ 業務負荷の平準化 
うまく業務が回る運用現場。 
‣ 運用に対する評価の適正化 
適正な利潤を生む現場と、適切に評価される要員。 
1. 高負荷 
2. 属人的 
3. 見えぬ費用対効果 
低付加価値化 
「セキュアな運用」を追い求めて
「セキュアな運用」を追い求めて 
ステークホルダーの「期待」を実現することで運用の評価は高まる。 
Operation Lab 
運用設計ラボ 
「運用の理想」とは 
運用現場の理想 
‣ サービスの安定 
社会基盤に相応しい安定運用。 
‣ 業務負荷の平準化 
うまく業務が回る運用現場。 
‣運用に対する評価の適正化 
適正な利潤を生む現場と、適切に評価される要員。 
運用への 
期待 
ユーザ 
経営者 
運用 
マネージャ 
オペレータ監査者 
ユーザの理想 
‣ サービスの安定 
社会基盤に相応しい安定運用。 
‣ サービスの費用対効果 
コストに見合ったプロフィット。 
‣ サービスのプラスα 
期待を超えるベネフィット。 
仮説: 「ステークホルダーの期待を実現すること」が「運用の理想」
「セキュアな運用」を追い求めて 
運用設計とは何か 
運用現場の理想運用設計の目的 
常にシンプル 
テキストを入力してください 
運用現場の現実 
1. 高負荷 
業務が複雑化 
2. 属人的 
ブラックボックス化 
3. 見えぬ費用対効果 
低付加価値化 
1. 業務の複雑化を許さない仕組み 
作り 
2. 業務のブラックボックス化を許 
さない仕組み作り 
常に見える 
3. 業務価値の陳腐化を許さない仕 
組み作り 
‣ サービスの安定 
社会基盤に相応しい安定運用。 
‣ 業務負荷の平準化 
うまく業務が回る運用現場。 
‣ 運用に対する評価の適正化 
適正な利潤を生む現場と、適切に評価される要員。 
1.「運用」への期待の明確化 
常に価値を生む 
2.「運用設計」の確立 
3. 期待に対する消費リソースの測定化 
出典: Think IT 「現場視点からの運用方法論 第2回 自分たちの「運用」を知る - 運用設計の本質」(2010-12)
Operation Lab 
運用設計ラボ 
詳しくは
業務価値の陳腐化 
を許さない仕組み作り 
「セキュアな運用」を追い求めて 
常にシンプル常に見える常に価値を生む 
管理会計/経営学 
Operation Lab 
運用設計ラボ 
セキュア運用設計とは 
運用現場の「理想」と「現実」の橋渡し 
業務の複雑化 
を許さない仕組み作り 
業務のブラックボックス化 
を許さない仕組み作り 
工学的な客観化(業務の「構造化」「数値化」) 
安全で不安の無い、頑丈(ロバストネス)な運用 
「ムリ、ムラ、ムダ、モレ」が無い運用
Operation Lab 
運用設計ラボ 
余談: PDCAしてますか?
「セキュアな運用」を追い求めて 
ちゃんとサイクルしている現場を聞いたことないです 
Operation Lab 
運用設計ラボ 
PDCAしてませんよね? 
• P: プランを立てて、 <<計画>> 
• D: だましだまし「やってみた」けど、 <<実施>> 
• C: 「ちょっと忙しく」って、 <<停滞>> 
• A: 「あれ? どこまでやってたんだっけ?」 <<終了>>
「運用の効率化」が可能 
運用の評価適正化 
Operation Lab 
運用設計ラボ 
PDCAからPDSへ 
日本人はPDSサイクルで! 
3. 諸問題の解消へ 
2.「運用設計」の確立 
運用実績の測定可能化 
「やらないこと」の明確化 
本当に必要な運用基盤の整備 
3. 期待に対する消費 
リソースの測定化 
より高度な「期待」の醸成 
適切な運用設計が可能 
1.「運用」への期待の 
明確化 
慢性的なリソース不足が解消 
慢性的な業務バーストが解消 
Do 
運用への 
期待 
Plan See 
出展: Internet Week 2009 「運用方法論 システム運用現場の現状分析 そして運用設計へ」 (2009-11)
Operation Lab 
運用設計ラボ 
さて、「監査」と「運用」
さて、「監査」と「運用」 
「監査」って敵(enemy)ですか? 
Operation Lab 
運用設計ラボ 
心情的にはYes 
将来的にはNo
さて、「監査」と「運用」 
なぜ監査が必要なのか? (従来からの視点) 
業務を適切にマネジメントできているか「説明するため」 
監査 (外部監査) 
Operation Lab 
運用設計ラボ 
ユーザ 
経営者 
運用 
マネージャ 
運用への 
期待 
オペレータ監査者
さて、「監査」と「運用」 
運用における「マネジメント」の3要素 (仮説) 
マネジメントとは、把握して、判断して、(自力、他力で)制御すること。 
Operation Lab 
運用設計ラボ 
マネジメントとは、(本当は)統制ではない。 
セキュリティマネジメント 
1. 脅威を把握して、判断して、制御する。 
2. 脆弱性を把握して、判断して、制御する。 
3. リソースを把握して、判断して、制御する。 
サービスマネジメント 
1. サービス障害の影響を把握して、判断して、制御する。(サービス設計) 
2. サービス障害の可能性を把握して、判断して、制御する。(プロアクティブ) 
3. サービス障害の発生を把握して、判断して、制御する。(リアクティブ)
Operation Lab 
運用設計ラボ 
さて、「監査」と「運用」 
なぜ監査が必要なのか? (現場視点) 
ユーザ 
「運用への期待」との「ギャップを知るため」 
監査 (自己監査) 
経営者 
運用 
マネージャ 
運用への 
期待 
オペレータ監査者
さて、「監査」と「運用」 
レビュー(監査)を前提とした運用設計ライフサイクル 
リスクマネジメント 
運用/システム設計 
リスクマネジメント監査 (レビュー) 
3. 諸問題の解消へ 
Operation Lab 
運用設計ラボ 
3. 制御 
Do 
運用への 
期待 
Plan See 
1. 把握 
2. 判断 
セキュリティ 
監査を前提として客観化していないサービス設計は 
内部的にも外部的にも評価ができない。
さて、「監査」と「運用」 
監査監査 (自己監査: セルフレビュー) 
監査 (外部監査: 第三者レビュー) 
Operation Lab 
運用設計ラボ 
仮説: セキュリティマネジメントの3要素 
リスクマネジメント 
情報資産管理 
リスク評価 
リスク戦略 
サービス設計運用設計システム設計 
1. 把握 
2. 判断 
3. 制御
さて、「監査」と「運用」 
「監査」は「把握するため」に必要 
「運用への期待」との「ギャップを知るため」 
業務を適切にマネジメントできているか「説明するため」 
Operation Lab 
運用設計ラボ 
なぜ監査が必要なのか? 
監査監査 (自己監査: セルフレビュー) 
監査 (外部監査: 第三者レビュー) 1. 把握 
「監査」という言葉が、強圧的で良くない。 
「レビュー」という意味に近い日本語の登場が待ち望まれる。
Operation Lab 
運用設計ラボ 
「運用価値」の表現へ
Operation Lab 
運用設計ラボ 
「運用価値」の表現へ 
運用研究から見えてきた「運用の未来」 
ITサービス運用に関しては、科学的客観的な業務設計と、 
各業務の反復性再現性が重要になる。(2009) 
「運用」抽象化への視点 
• ITサービスにおける「運用」とはサービスデリバリである。(2009) 
• QCDによる科学的客観的評価 (費用対効果の測定可能化) 
• サービス手段よりもサービス目的にフォーカス (よりユーザ視点に近い) 
• 運用組織は分散協調(API)モデルである。(2009-2010) 
• 疎結合な組織設計、業務設計 
• 業務処理を隠蔽化し、組織間コミュニケーションを定型化 
• 業務における責務の集中 
• 運用業務とは工程(UNIXにおけるパイプ処理)である。(2010) 
• 工程設計が適切であれば、処理の定型化、多重化が容易に (脱属人化、脱高負荷) 
• 工程設計が適切であれば、コードに落し込みがしやすい
構造化ここでは「エンジニアリング(工学)の実践」に近い意味で使います。 
工学では何らかの構造物・構造体を作ることが不可避なためです。 
Operation Lab 
運用設計ラボ 
主張: クラウド時代の運用設計 
「問題を根性で解決するのは馬鹿です。 
問題をエンジニアリングで解決するのが 
エンジニアの仕事です」 
@yoshiori 
http://d.hatena.ne.jp/Yoshiori/20120217/1329491437 
「運用価値」の表現へ
Operation Lab 
運用設計ラボ 
「運用価値」の表現へ 
主張: クラウド時代の運用設計 
運用の構造化 
エンジニアリング(工学)の実践 
「運用価値」を構造的に表現する 
エンジニアリング(定量評価)で 
運用工程の実績を示す技術者を 
エンジニアと言う
「運用価値」の表現へ 
エンジニアリング(定量評価)で 
運用工程の実績を示す技術者を 
エンジニアと言う 
‣ 運用に対する評価の適正化 
適正な利潤を生む現場と、適切に評価される要員。 
Operation Lab 
運用設計ラボ 
現在: 家内制手運用の時代 
今後: 大規模大量運用の時代
‣ 運用に対する評価の適正化 
適正な利潤を生む現場と、適切に評価される要員。 
クラウドなら客観数値が取れるんじゃ? 
Operation Lab 
運用設計ラボ 
「運用価値」の表現へ 
エンジニアリング(定量評価)で 
運用工程の実績を示す技術者を 
エンジニアと言う
Operation Lab 
運用設計ラボ 
まとめ (運用×セキュリティ)
Operation Lab 
運用設計ラボ 
まとめ (運用×セキュリティ) 
セキュリティマネジメント 
1. 脅威を把握して、判断して、制御する。 
2. 脆弱性を把握して、判断して、制御する。 
3. リソースを把握して、判断して、制御する。 
監査監査 (自己監査: セルフレビュー) 
監査 (外部監査: 第三者レビュー) 
‣ 運用に対する評価の適正化 (運用価値) 
適正な利潤を生む現場と、適切に評価される要員。
なぜ、セキュリティインシデントは発生するか? 
Operation Lab 
運用設計ラボ 
おまけ
なぜ、セキュリティインシデントは発生するか? 
社会的な前提条件をリセットして考えることは重要。 
Operation Lab 
運用設計ラボ 
• 仮説: セキュリティインシデント発生の3要因 
• 仮説: リソースに関する三原則 
• 仮説: セキュリティマネジメントの3要素 (再)
なぜ、セキュリティインシデントは発生するか? 
仮説: セキュリティインシデント発生の3要因 
Operation Lab 
運用設計ラボ 
1. リソースを持ってるから 
2. リソースに対する脅威が存在するから 
3. リソースに脆弱性が存在するから
なぜ、セキュリティインシデントは発生するか? 
なぜ、セキュリティインシデントは発生するか? 
Operation Lab 
運用設計ラボ 
仮説: リソースに関する三原則 
1. リソースを持ってるから 
リソースに関する三原則 
第一原則: リソースを持たない 
第二原則: リソースを置かない (どうしても持つ必要がある場合) 
第三原則: リソースに触わらせない (どうしても置く必要がある場合)
Operation Lab 
運用設計ラボ 
なぜ、セキュリティインシデントは発生するか? 
仮説: リソースに関する三原則 
第一原則: リソースを持たない 
リソースを持つこと自体がコスト/リスクである 
持たなければ「やられない」 
第二原則: リソースを置かない (どうしても持つ必要がある場合) 
リソースを隔離する。 
置かなければ「触われない」 
第三原則: リソースに触わらせない (どうしても置く必要がある場合) 
リソースにアクセス制御を適用する。 
最小限しか「触われない」はず
なぜ、セキュリティインシデントは発生するか? 
仮説: セキュリティマネジメントの3要素 (再) 
監査監査 (自己監査: セルフレビュー) 
監査 (外部監査: 第三者レビュー) 
Operation Lab 
運用設計ラボ 
リスクマネジメント 
情報資産管理 
リスク評価 
サービス設計運用設計システム設計 
1. 把握 
2. 判断 
3. 制御 
リスク戦略
Operation Lab 
運用設計ラボ 
なぜ、セキュリティインシデントは発生するか? 
まとめ 
セキュリティマネジメントの3要素 
リソースに関する三原則 
第一原則: 持たない 
第二原則: 置かない 
第三原則: 触わらせない 
1. リソースを持ってるから 
2. リソースに対する脅威が存在するから 
3. リソースに脆弱性が存在するから 
セキュリティインシデント発生の3要因 
組合せ 
セキュリティマネジメントの全体像
Opera運t用io設n計Lab 
Operation Lab 
運用設計ラボ 
http://www.operation-lab.co.jp/

More Related Content

What's hot

2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション
2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション
2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーションOperation Lab, LLC.
 
「運用改善」を考える 〜「自動化」を考える前に
「運用改善」を考える 〜「自動化」を考える前に「運用改善」を考える 〜「自動化」を考える前に
「運用改善」を考える 〜「自動化」を考える前に
Operation Lab, LLC.
 
運用現場の過去、現在、未来
運用現場の過去、現在、未来運用現場の過去、現在、未来
運用現場の過去、現在、未来
Hirokazu Hatano
 
AWSCLI Lambda
AWSCLI LambdaAWSCLI Lambda
AWSCLI Lambda
Operation Lab, LLC.
 
2015-05-23 クラウドの運用になって インフラエンジニアは何が変わるのか?
2015-05-23 クラウドの運用になって インフラエンジニアは何が変わるのか?2015-05-23 クラウドの運用になって インフラエンジニアは何が変わるのか?
2015-05-23 クラウドの運用になって インフラエンジニアは何が変わるのか?
Operation Lab, LLC.
 
運用設計の必要性と5年後のIT部門の姿について
運用設計の必要性と5年後のIT部門の姿について運用設計の必要性と5年後のIT部門の姿について
運用設計の必要性と5年後のIT部門の姿について
UNIRITA Incorporated
 
20110827 restudy-pyconjp2011
20110827 restudy-pyconjp201120110827 restudy-pyconjp2011
20110827 restudy-pyconjp2011
Hirokazu Hatano
 
あるインフラエンジニアの過去と未来
あるインフラエンジニアの過去と未来あるインフラエンジニアの過去と未来
あるインフラエンジニアの過去と未来
Tsubasa Hirota
 
システム運用 (インフラ編)
システム運用 (インフラ編)システム運用 (インフラ編)
システム運用 (インフラ編)Takashi Abe
 
製造業向け量子コンピュータ時代のDXセミナー ~見える化、分析、予測、その先の最適化へ~
製造業向け量子コンピュータ時代のDXセミナー ~見える化、分析、予測、その先の最適化へ~製造業向け量子コンピュータ時代のDXセミナー ~見える化、分析、予測、その先の最適化へ~
製造業向け量子コンピュータ時代のDXセミナー ~見える化、分析、予測、その先の最適化へ~
Fixstars Corporation
 
JaSST'12 Kansai
JaSST'12 KansaiJaSST'12 Kansai
JaSST'12 Kansai
智治 長沢
 
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
賢 秋穂
 
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)
Shingo Kitayama
 
Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-
Shingo Kitayama
 
STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015
STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015
STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015
Yahoo!デベロッパーネットワーク
 
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」
Rescale Japan株式会社
 
Serverless の自動回復と自動化のためのアーキテクチャ
Serverless の自動回復と自動化のためのアーキテクチャServerless の自動回復と自動化のためのアーキテクチャ
Serverless の自動回復と自動化のためのアーキテクチャ
Tsuyoshi Ushio
 
2017 10-04ワークショップ発表資料公開用
2017 10-04ワークショップ発表資料公開用2017 10-04ワークショップ発表資料公開用
2017 10-04ワークショップ発表資料公開用
Cybozucommunity
 
セミナー資料「STAR-CCM+ クラウド活用ハンズオンセミナー with Rescale」
セミナー資料「STAR-CCM+ クラウド活用ハンズオンセミナー with Rescale」セミナー資料「STAR-CCM+ クラウド活用ハンズオンセミナー with Rescale」
セミナー資料「STAR-CCM+ クラウド活用ハンズオンセミナー with Rescale」
Rescale Japan株式会社
 

What's hot (19)

2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション
2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション
2014-07-26 jawsug-chiba ドキュメントを書こう! 運用自動化時代のドキュメンテーション
 
「運用改善」を考える 〜「自動化」を考える前に
「運用改善」を考える 〜「自動化」を考える前に「運用改善」を考える 〜「自動化」を考える前に
「運用改善」を考える 〜「自動化」を考える前に
 
運用現場の過去、現在、未来
運用現場の過去、現在、未来運用現場の過去、現在、未来
運用現場の過去、現在、未来
 
AWSCLI Lambda
AWSCLI LambdaAWSCLI Lambda
AWSCLI Lambda
 
2015-05-23 クラウドの運用になって インフラエンジニアは何が変わるのか?
2015-05-23 クラウドの運用になって インフラエンジニアは何が変わるのか?2015-05-23 クラウドの運用になって インフラエンジニアは何が変わるのか?
2015-05-23 クラウドの運用になって インフラエンジニアは何が変わるのか?
 
運用設計の必要性と5年後のIT部門の姿について
運用設計の必要性と5年後のIT部門の姿について運用設計の必要性と5年後のIT部門の姿について
運用設計の必要性と5年後のIT部門の姿について
 
20110827 restudy-pyconjp2011
20110827 restudy-pyconjp201120110827 restudy-pyconjp2011
20110827 restudy-pyconjp2011
 
あるインフラエンジニアの過去と未来
あるインフラエンジニアの過去と未来あるインフラエンジニアの過去と未来
あるインフラエンジニアの過去と未来
 
システム運用 (インフラ編)
システム運用 (インフラ編)システム運用 (インフラ編)
システム運用 (インフラ編)
 
製造業向け量子コンピュータ時代のDXセミナー ~見える化、分析、予測、その先の最適化へ~
製造業向け量子コンピュータ時代のDXセミナー ~見える化、分析、予測、その先の最適化へ~製造業向け量子コンピュータ時代のDXセミナー ~見える化、分析、予測、その先の最適化へ~
製造業向け量子コンピュータ時代のDXセミナー ~見える化、分析、予測、その先の最適化へ~
 
JaSST'12 Kansai
JaSST'12 KansaiJaSST'12 Kansai
JaSST'12 Kansai
 
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
 
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)
[Red Hat Forum 2017] Ansible Towerの実践!!エンタープライズのInfrastructure as Codeの現在(イマ)
 
Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-
 
STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015
STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015
STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015
 
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」
 
Serverless の自動回復と自動化のためのアーキテクチャ
Serverless の自動回復と自動化のためのアーキテクチャServerless の自動回復と自動化のためのアーキテクチャ
Serverless の自動回復と自動化のためのアーキテクチャ
 
2017 10-04ワークショップ発表資料公開用
2017 10-04ワークショップ発表資料公開用2017 10-04ワークショップ発表資料公開用
2017 10-04ワークショップ発表資料公開用
 
セミナー資料「STAR-CCM+ クラウド活用ハンズオンセミナー with Rescale」
セミナー資料「STAR-CCM+ クラウド活用ハンズオンセミナー with Rescale」セミナー資料「STAR-CCM+ クラウド活用ハンズオンセミナー with Rescale」
セミナー資料「STAR-CCM+ クラウド活用ハンズオンセミナー with Rescale」
 

Similar to 2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)

GP4エンジニアリング・ソリューションのご紹介
GP4エンジニアリング・ソリューションのご紹介GP4エンジニアリング・ソリューションのご紹介
GP4エンジニアリング・ソリューションのご紹介
中村昌弘 中村昌弘
 
JAWS-UG三都物語_企業でのAWS導入のエントリーポイント
JAWS-UG三都物語_企業でのAWS導入のエントリーポイントJAWS-UG三都物語_企業でのAWS導入のエントリーポイント
JAWS-UG三都物語_企業でのAWS導入のエントリーポイントToshiyuki Konparu
 
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Hiromasa Oka
 
今、おさえておきたい DevOps
今、おさえておきたい DevOps 今、おさえておきたい DevOps
今、おさえておきたい DevOps
智治 長沢
 
Jasst12九州 倉貫資料:アジャイル・Ruby・クラウド(ARC)を活用したビジネスにおけるテストの実践 #jasst12Q
Jasst12九州 倉貫資料:アジャイル・Ruby・クラウド(ARC)を活用したビジネスにおけるテストの実践 #jasst12QJasst12九州 倉貫資料:アジャイル・Ruby・クラウド(ARC)を活用したビジネスにおけるテストの実践 #jasst12Q
Jasst12九州 倉貫資料:アジャイル・Ruby・クラウド(ARC)を活用したビジネスにおけるテストの実践 #jasst12Q
Yoshihito Kuranuki
 
ヒーロー島 Visual Studio 2012
ヒーロー島 Visual Studio 2012ヒーロー島 Visual Studio 2012
ヒーロー島 Visual Studio 2012
智治 長沢
 
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
Hideaki Tokida
 
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用masashi takehara
 
アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱
Koichi ITO
 
X dev 20121106
X dev 20121106X dev 20121106
X dev 20121106Ken Azuma
 
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
Kenji Hiranabe
 
【schoo WEB-campus】どうすれば小さなチームでも大きな成果を出せるのか
【schoo WEB-campus】どうすれば小さなチームでも大きな成果を出せるのか【schoo WEB-campus】どうすれば小さなチームでも大きな成果を出せるのか
【schoo WEB-campus】どうすれば小さなチームでも大きな成果を出せるのか
schoowebcampus
 
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
Ryo Mitoma
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
陽一 滝川
 
A 1-1 tfs on azure で始めるイマドキのソフトウェア開発
A 1-1 tfs on azure で始めるイマドキのソフトウェア開発A 1-1 tfs on azure で始めるイマドキのソフトウェア開発
A 1-1 tfs on azure で始めるイマドキのソフトウェア開発
GoAzure
 
Go azure tfs_service
Go azure tfs_serviceGo azure tfs_service
Go azure tfs_service
Kaoru NAKAMURA
 
OSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSCOSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSC
Daisuke Nishino
 
Information20120312
Information20120312Information20120312
Information20120312b-slash
 
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapanモダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
満徳 関
 

Similar to 2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ) (20)

GP4エンジニアリング・ソリューションのご紹介
GP4エンジニアリング・ソリューションのご紹介GP4エンジニアリング・ソリューションのご紹介
GP4エンジニアリング・ソリューションのご紹介
 
JAWS-UG三都物語_企業でのAWS導入のエントリーポイント
JAWS-UG三都物語_企業でのAWS導入のエントリーポイントJAWS-UG三都物語_企業でのAWS導入のエントリーポイント
JAWS-UG三都物語_企業でのAWS導入のエントリーポイント
 
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
 
今、おさえておきたい DevOps
今、おさえておきたい DevOps 今、おさえておきたい DevOps
今、おさえておきたい DevOps
 
Jasst12九州 倉貫資料:アジャイル・Ruby・クラウド(ARC)を活用したビジネスにおけるテストの実践 #jasst12Q
Jasst12九州 倉貫資料:アジャイル・Ruby・クラウド(ARC)を活用したビジネスにおけるテストの実践 #jasst12QJasst12九州 倉貫資料:アジャイル・Ruby・クラウド(ARC)を活用したビジネスにおけるテストの実践 #jasst12Q
Jasst12九州 倉貫資料:アジャイル・Ruby・クラウド(ARC)を活用したビジネスにおけるテストの実践 #jasst12Q
 
ヒーロー島 Visual Studio 2012
ヒーロー島 Visual Studio 2012ヒーロー島 Visual Studio 2012
ヒーロー島 Visual Studio 2012
 
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
 
20130320 agile pm
20130320 agile pm20130320 agile pm
20130320 agile pm
 
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
 
アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱
 
X dev 20121106
X dev 20121106X dev 20121106
X dev 20121106
 
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
 
【schoo WEB-campus】どうすれば小さなチームでも大きな成果を出せるのか
【schoo WEB-campus】どうすれば小さなチームでも大きな成果を出せるのか【schoo WEB-campus】どうすれば小さなチームでも大きな成果を出せるのか
【schoo WEB-campus】どうすれば小さなチームでも大きな成果を出せるのか
 
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
 
A 1-1 tfs on azure で始めるイマドキのソフトウェア開発
A 1-1 tfs on azure で始めるイマドキのソフトウェア開発A 1-1 tfs on azure で始めるイマドキのソフトウェア開発
A 1-1 tfs on azure で始めるイマドキのソフトウェア開発
 
Go azure tfs_service
Go azure tfs_serviceGo azure tfs_service
Go azure tfs_service
 
OSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSCOSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSC
 
Information20120312
Information20120312Information20120312
Information20120312
 
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapanモダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
 

2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)

  • 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)
  • 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. リソースを把握して、判断して、制御する。 監査監査 (自己監査: セルフレビュー) 監査 (外部監査: 第三者レビュー) ‣ 運用に対する評価の適正化 (運用価値) 適正な利潤を生む現場と、適切に評価される要員。
  • 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/