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

Operation Lab運用設計ラボ

腹を割って話そう (運用×セキュリティ)運用設計ラボ合同会社シニアアーキテクト波田野裕一

2014-10-27

#ssmjp ～腹を割って話そうスペシャル～


自己紹介

✦ Sphinx Users-jp 会長 (2014年度) ✦ 日本UNIXユーザ会(jus) 幹事 (副会長) ✦ IPv6普及・高度化推進協議会 (サブWG 部会長共同) ✦ Internet Week プログラム委員 ✦ Internet Conference 実行委員 ✦ BSD / OSS / JANOG

波田野裕一 (HATANO Hirokazu) 運用設計ラボ合同会社シニアアーキテクト

‣ ADSLキャリアで開通業務、ATM運用、ISP運用および障害監視を担当

‣ SIerで公共系サービスのサーバ保守

‣ ASP でミドルウェアおよび障害監視システムの設計構築運用

‣ 運用設計ラボを設立。主にドキュメンテーション活動。

業務歴

参加コミュニティ「レガシー運用」に詳しい人


運用の自動化は、「客観化の結果」であって「目的」ではない。

最近の主張: 設計の無い「自動化」は自滅への道

「自分達のやっていることの品質安定化&永続化のために」、目的:

手段: 自動「客観化(構造化)された業務の一部」を自動化する。

「目的と手段がひっくりかえる」ことは、よくある「自動化が目的」の弊害

• 「自動化された業務」の保守が属人化する。 • 「自動化された業務」の仕様が不明になり、業務プロセスが硬直化する。 • 「自動化された業務」でトラブルが発生すると、手動ではリカバリができない。(手順がわからない)


運用現場の諸問題

1.高負荷

2.属人的

3.見えぬ費用対効果

ブラックボックス化

低付加価値化

業務が複雑化

「費用」は一定で「効果」は経年劣化する「費用対効果」は勝手に低減していく

現場では制御不能状態

クラウド時代の運用は、美しいといいなぁという期待


詳しくは運用現場の諸問題


「セキュアな運用」を追い求めて


昨年春あたりからセキュリティ事故に変化

• ガチ攻撃の多発 (経済事犯) • ゴルゴ13に狙われたら死亡確定 • 片手間で対応無理

「セキュリティは運用の一部」に


「セキュアな運用」とは• セキュアとは

• 安全な、不安の無い、保障された、頑丈な、などの意味

• 「セキュアな運用」とは • 安全な、不安の無い、保障された、頑丈(ロバストネス)な運用

そのイメージは運用現場それぞれで異なる。(共通認識が重要) • 365日24時間の事業継続性 (全ステークホルダーに重要) • 現場にとって安全 (不安が無い、ムリが無い。) • 利用者にとって安全 (不安が無い、ムラが無い。) • 経営者にとって安全 (不安が無い、ムダが無い。) • 監査者にとってモレが無い。

「ムリ、ムラ、ムダ、モレ」が無い運用



「セキュアな運用」とは

• 現場にムリが無い運用。 • 利用者にはムラが無い運用。 • 経営者にはムダが無い運用。 • 監査者にはモレが無い運用。



• 現場にムリが無い運用。

ISMSって (ry



• 利用者にはムラが無い運用。

(声) 一部だけセキュアでもダメでしょ



• 経営者にはムダが無い運用。

「それって費用対効果(ry」

これはすごく重要「運用の価値」が理解されていない


運用ドキュメントを作る時間が…

インターネット運用は「安く、手間をかけず」が特徴で、運用設計とドキュメンテーションがないがしろにされてきた。(企業の大小、社歴の長さを問わず)

セキュリティについて作り込む時間が…インターネット運用は「安く、手間をかけず」が特徴で、セキュリティがないがしろにされてきた。 (企業の大小、社歴の長さを問わず)

同じ構図!



• 監査者にはモレが無い運用。

運用業務を理解している監査者って(ry

逆に、監査者が理解できる運用をしている?


「セキュアな運用」とは (再)

• 現場にムリが無い運用。 • 利用者にはムラが無い運用。 • 経営者にはムダが無い運用。 • 監査者にはモレが無い運用。

上手い… >

(会場からの声)


• セキュリティを独立に考える時代は終了 • セキュリティを事前に組み込んだ運用設計。 • 片手間で対応無理。通常運用の一部に。

「セキュリティは運用の一部」に

「セキュアな運用」の実現「セキュアな運用」を追い求めて

運用現場も考え方を転換する必要が


• 一番怖いのは内部からの偶発事故 • オンプレミスをやめちゃう(とか) • クラウドは全てが外になる。全方向一定強度。

「セキュアな運用」の実現「セキュアな運用」を追い求めて

運用現場も考え方を転換する必要が


「セキュアな運用」とは (再)

• 現場にムリが無い運用 • 利用者にはムラが無い運用 • 経営者には費用対効果が説明できる運用 • 監査者にも理解が可能な運用


運用設計してますか?



運用設計とは

運用現場の「理想」と「現実」の橋渡し

運用現場の理想

‣ サービスの安定社会基盤に相応しい安定運用。

‣ 業務負荷の平準化うまく業務が回る運用現場。

‣ 運用に対する評価の適正化適正な利潤を生む現場と、適切に評価される要員。

1. 高負荷

2. 属人的

3. 見えぬ費用対効果

運用現場の現実


低付加価値化

業務が複雑化



「運用の理想」とは

運用現場の理想



‣運用に対する評価の適正化適正な利潤を生む現場と、適切に評価される要員。

運用への期待

ユーザ

経営者

運用マネージャ

オペレータ監査者

ユーザの理想


‣ サービスの費用対効果コストに見合ったプロフィット。

‣ サービスのプラスα 期待を超えるベネフィット。

ステークホルダーの「期待」を実現することで運用の評価は高まる。

仮説: 「ステークホルダーの期待を実現すること」が「運用の理想」


運用設計とは何か

テキストを入力してください

1. 高負荷

2. 属人的

3. 見えぬ費用対効果

運用現場の現実


低付加価値化

業務が複雑化

1. 業務の複雑化を許さない仕組み作り

2. 業務のブラックボックス化を許さない仕組み作り

3. 業務価値の陳腐化を許さない仕組み作り

運用設計の目的運用現場の理想




1.「運用」への期待の明確化

3. 期待に対する消費リソースの測定化

2.「運用設計」の確立

常にシンプル

常に見える

常に価値を生む

出典: Think IT 「現場視点からの運用方法論第2回自分たちの「運用」を知る - 運用設計の本質」(2010-12)



詳しくは


セキュア運用設計とは

運用現場の「理想」と「現実」の橋渡し

工学的な客観化(業務の「構造化」「数値化」)

業務の複雑化を許さない仕組み作り

業務のブラックボックス化を許さない仕組み作り

業務価値の陳腐化を許さない仕組み作り

常に価値を生む常にシンプル常に見える管理会計/経営学

安全で不安の無い、頑丈(ロバストネス)な運用

「ムリ、ムラ、ムダ、モレ」が無い運用



余談: PDCAしてますか?


PDCAしてませんよね?

• P: プランを立てて、 <<計画>>

• D: だましだまし「やってみた」けど、 <<実施>>

• C: 「ちょっと忙しく」って、 <<停滞>>

• A: 「あれ? どこまでやってたんだっけ?」 <<終了>>

ちゃんとサイクルしている現場を聞いたことないです



日本人はPDSサイクルで!

3. 諸問題の解消へ

2.「運用設計」の確立

運用実績の測定可能化

「やらないこと」の明確化

本当に必要な運用基盤の整備

3. 期待に対する消費リソースの測定化

より高度な「期待」の醸成

「運用の効率化」が可能

運用の評価適正化

出展: Internet Week 2009 「運用方法論システム運用現場の現状分析そして運用設計へ」 (2009-11)

PDCAからPDSへ

1.「運用」への期待の明確化

適切な運用設計が可能

慢性的な業務バーストが解消

慢性的なリソース不足が解消

運用への期待

SeePlan

Do


さて、「監査」と「運用」


「監査」って敵(enemy)ですか?

心情的にはYes 将来的にはNo



ユーザ

経営者



なぜ監査が必要なのか? (従来からの視点)業務を適切にマネジメントできているか「説明するため」

監査 (外部監査)


運用への期待


運用における「マネジメント」の3要素 (仮説)

マネジメントとは、(本当は)統制ではない。

セキュリティマネジメント 1. 脅威を把握して、判断して、制御する。

2. 脆弱性を把握して、判断して、制御する。

3. リソースを把握して、判断して、制御する。

マネジメントとは、把握して、判断して、(自力、他力で)制御すること。

サービスマネジメント 1. サービス障害の影響を把握して、判断して、制御する。(サービス設計)

2. サービス障害の可能性を把握して、判断して、制御する。(プロアクティブ)

3. サービス障害の発生を把握して、判断して、制御する。(リアクティブ)



ユーザ

経営者



「運用への期待」との「ギャップを知るため」

監査 (自己監査)


なぜ監査が必要なのか? (現場視点)

運用への期待


3. 諸問題の解消へ

運用への期待

SeePlan

Do

レビュー(監査)を前提とした運用設計ライフサイクル

1. 把握

監査を前提として客観化していないサービス設計は内部的にも外部的にも評価ができない。

2. 判断

3. 制御

セキュリティ

リスクマネジメント監査 (レビュー)

運用/システム設計

リスクマネジメント



仮説: セキュリティマネジメントの3要素


監査監査 (自己監査: セルフレビュー)

監査 (外部監査: 第三者レビュー)

情報資産管理

リスク評価

リスク戦略

サービス設計運用設計システム設計

1. 把握

2. 判断

3. 制御



なぜ監査が必要なのか?


監査 (外部監査: 第三者レビュー)1. 把握

「監査」は「把握するため」に必要

「監査」という言葉が、強圧的で良くない。「レビュー」という意味に近い日本語の登場が待ち望まれる。

「運用への期待」との「ギャップを知るため」

業務を適切にマネジメントできているか「説明するため」



「運用価値」の表現へ


運用研究から見えてきた「運用の未来」ITサービス運用に関しては、科学的客観的な業務設計と、各業務の反復性再現性が重要になる。(2009)

• ITサービスにおける「運用」とはサービスデリバリである。(2009) • QCDによる科学的客観的評価 (費用対効果の測定可能化) • サービス手段よりもサービス目的にフォーカス (よりユーザ視点に近い)

• 運用組織は分散協調(API)モデルである。(2009-2010) • 疎結合な組織設計、業務設計 • 業務処理を隠蔽化し、組織間コミュニケーションを定型化 • 業務における責務の集中

• 運用業務とは工程(UNIXにおけるパイプ処理)である。(2010) • 工程設計が適切であれば、処理の定型化、多重化が容易に (脱属人化、脱高負荷) • 工程設計が適切であれば、コードに落し込みがしやすい

「運用」抽象化への視点



主張: クラウド時代の運用設計

「問題を根性で解決するのは馬鹿です。問題をエンジニアリングで解決するのが

エンジニアの仕事です」 @yoshiori

構造化ここでは「エンジニアリング(工学)の実践」に近い意味で使います。工学では何らかの構造物・構造体を作ることが不可避なためです。

http://d.hatena.ne.jp/Yoshiori/20120217/1329491437



主張: クラウド時代の運用設計

運用の構造化


「運用価値」を構造的に表現する

エンジニアリング(定量評価)で運用工程の実績を示す技術者を

エンジニアと言う

エンジニアリング(工学)の実践



現在: 家内制手運用の時代

今後: 大規模大量運用の時代






クラウドなら客観数値が取れるんじゃ?





まとめ (運用×セキュリティ)




まとめ (運用×セキュリティ)セキュリティマネジメント 1. 脅威を把握して、判断して、制御する。

2. 脆弱性を把握して、判断して、制御する。

3. リソースを把握して、判断して、制御する。

‣ 運用に対する評価の適正化 (運用価値) 適正な利潤を生む現場と、適切に評価される要員。


なぜ、セキュリティインシデントは発生するか?おまけ


なぜ、セキュリティインシデントは発生するか?

• 仮説: セキュリティインシデント発生の3要因 • 仮説: リソースに関する三原則 • 仮説: セキュリティマネジメントの3要素 (再)

社会的な前提条件をリセットして考えることは重要。


1. リソースを持ってるから 2. リソースに対する脅威が存在するから 3. リソースに脆弱性が存在するから

仮説: セキュリティインシデント発生の3要因なぜ、セキュリティインシデントは発生するか?


仮説: リソースに関する三原則

1. リソースを持ってるから


リソースに関する三原則第一原則: リソースを持たない第二原則: リソースを置かない (どうしても持つ必要がある場合) 第三原則: リソースに触わらせない (どうしても置く必要がある場合)



第一原則: リソースを持たない

第二原則: リソースを置かない (どうしても持つ必要がある場合)

第三原則: リソースに触わらせない (どうしても置く必要がある場合)

リソースを持つこと自体がコスト/リスクである持たなければ「やられない」

リソースを隔離する。置かなければ「触われない」

リソースにアクセス制御を適用する。最小限しか「触われない」はず


仮説: リソースに関する三原則


仮説: セキュリティマネジメントの3要素 (再)




情報資産管理

リスク評価

サービス設計運用設計システム設計

1. 把握

2. 判断

3. 制御


リスク戦略


まとめ

セキュリティマネジメントの3要素

リソースに関する三原則

第一原則: 持たない第二原則: 置かない第三原則: 触わらせない

セキュリティインシデント発生の3要因

組合せ

セキュリティマネジメントの全体像


1. リソースを持ってるから 2. リソースに対する脅威が存在するから 3. リソースに脆弱性が存在するから


http://www.operation-lab.co.jp/

OperationLab運用設計

http://www.operation-lab.co.jp/