Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

スカイアーチセミナー:【Web制作・SI企業様向け】サーバー管理が怖くなくなる方法

632 views

Published on

今回は、Web制作・SI企業向けのセミナーになります。
突然サーバー管理を任せられてしまった!
他の会社はどうやって運用しているのだろうか・・・
本当にこの運用方法は正しいのだろうか・・・

日々のサーバー運用に、不安や悩みを抱えていませんか?

今回はそんな方のためにセミナーを開催いたします!

Published in: Internet
  • Be the first to comment

スカイアーチセミナー:【Web制作・SI企業様向け】サーバー管理が怖くなくなる方法

  1. 1. 思いがけずサーバー管理まで任されてしまったWeb制作・SI企業 ご担当者様の為のご担当者様の為の 『サーバー管理・運用が怖くなくなる方法』『サーバー管理・運用が怖くなくなる方法』 株式会社スカイアーチネットワークス 営業本部 リーダー営業本部 リーダー 岡田 行司岡田 行司 (お か だ こ う じ) 1
  2. 2. 本日のゴール サーバー管理の基本を理解し、サーバー管理の基本を理解し、 サーバー管理を行う基礎を築きあげる!サーバー管理を行う基礎を築きあげる! 2
  3. 3. プロフィール 岡田 行司 / Koji Okada 株式会社スカイアーチネットワークス株式会社スカイアーチネットワークス 営業本部 リーダー • 2008年 スカイアーチネットワークス入社 • データセンター担当営業を行い、全国60社150か所のデータセンターを提案• データセンター担当営業を行い、全国60社150か所のデータセンターを提案 • 2009年より内部監査も担当し、現在5年目。情報セキュリティ、個人情報保 護、ITサービスマネジメントの視点からシステム提案を実施。護、ITサービスマネジメントの視点からシステム提案を実施。 • 2012年営業本部 リーダーに就任。担当顧客数No.1/売上No.1 • 信念:顧客のなんとなくを、しっかり形にして提案する事。• 信念:顧客のなんとなくを、しっかり形にして提案する事。 • 趣味:散歩 3
  4. 4. ワークシート • サーバー管理で困っている事を書き出し てみましょう。(5分程度)てみましょう。(5分程度) 4
  5. 5. 問題点 (サーバー管理あるある) 当たり前のようにサー バ管理も行う前提で、 案件が進んでいる サーバーに 詳しい社員案件が進んでいる がいない 夜間・休日に落 ちてても気付か クラウドを使 うちだけは大丈夫!! 大丈夫…… ない 脆弱性対策 大丈夫? クラウドを使 え? 24時間稼働 が必要 既に乗っ取られ 顧客「サーバー なんて勝手に動既に乗っ取られ ているかも なんて勝手に動 いてるの?」 5
  6. 6. リスク 損失 / 費用例 対策 サーバー管理がなぜ必要か 障害発生時の機会損失 売上1,000万円/月のサイトが、 障害で為す術がなく、1日止まったら…? 原因の切り分け、迅速に復旧! 障害の早期復旧(+予防) リスク 損失 / 費用例 対策 情報漏洩 ・1000万円/30日=33.3万円 ・信用失墜 原因の切り分け、迅速に復旧! 1件、発生してしまったら? 機密性の高いシステム構築情報漏洩 1件、発生してしまったら? 平均7505万7636円 *2012年5月 シマンテック調査 セキュリティに配慮した設定。 万が一の際は迅速に対応! 機密性の高いシステム構築 技術者の教育コスト 構築セミナー*に参加したら? ・受講料 8.4万円 ・人件費 3,000×20時間=6万円 約3,000台の構築ノウハウで、 最適化した構成でご提供! 専門事業者のノウハウ活用 ・人件費 3,000×20時間=6万円 *KENスクール「LAMP構築セミナー」料金 最適化した構成でご提供! レスポンス低下による機会損失 ページの反応が0.1秒 0.3秒で表示されていたサイト、 最適化されずに、0.6秒になっていたら? 増強・増設、チューニング! 最適化した構成の必要性 ページの反応が0.1秒 遅くなると、売上が1%落ちる *amazon.com調べ 最適化されずに、0.6秒になっていたら? ・1,000万円/月×3%=30万円/月 増強・増設、チューニング! 6
  7. 7. 目次 超基本編 1. 監視 超基本編 1. 監視 2. バックアップ 3. セキュリティ3. セキュリティ 応用編 4. サーバー安定稼働 応用編 5. クラウド活用 6. まとめ6. まとめ 7
  8. 8. まず抑えたいサバカン超基本 1.監視1.監視 ~異常事態はすぐに気付こう~ 2. バックアップ ~異常事態はすぐに直そう~ 3. セキュリティ3. セキュリティ ~異常事態の発生を抑えよう~~異常事態の発生を抑えよう~ 8
  9. 9. まず抑えたいサバカン超基本 1.監視1.監視 ~異常事態はすぐに気付こう~ 2. バックアップ ~異常事態はすぐに直そう~ 3. セキュリティ3. セキュリティ ~異常事態の発生を抑えよう~~異常事態の発生を抑えよう~ 9
  10. 10. 1.監視 • 監視の問題点 – なにをどこまで監視すればいいか? • 監視ポイントを増やす – 多角的にサーバー状況を監視でき、異常に気付きやすい。– 多角的にサーバー状況を監視でき、異常に気付きやすい。 – サービスに影響が無くてもアラートが出る為、緊急対応が必要 なアラートを見落とすなアラートを見落とす • 監視ポイントを減らす• 監視ポイントを減らす – アラートが少ないので緊急時のアラートが埋もれない – アラート受信後、どこに異常が出ているのか切り分けが必要– アラート受信後、どこに異常が出ているのか切り分けが必要 10
  11. 11. 1.監視 監視が多いと… 監視が少ないと…監視が多いと… ・細かくわかる 監視が少ないと… ・埋もれない・細かくわかる ・埋もれる ・埋もれない ・切り分けが必要 バランスのよい監視が必要バランスのよい監視が必要 11
  12. 12. 1.監視 • サバカン屋の主要監視設定 • Ping監視• Ping監視 • ポート監視 • DB監視 • URL監視• URL監視 • NFSマウント監視 • DISK容量 等• DISK容量 等 サービス(サイト閲覧)に直結する監視のみ アラートを上げる 12
  13. 13. 1.監視 • ほとんどやらない監視 • メモリ閾値• メモリ閾値 • CPU閾値 • トラフィック監視 等 ⇒アラートが上がってもそれ自体どうしようもない⇒アラートが上がってもそれ自体どうしようもない (サーバーの増強が必要) ⇒cactiによるグラフ取得で代用する⇒cactiによるグラフ取得で代用する 13
  14. 14. 1.監視 • Cacti (モニタリングツール) 蓄積しグラフ化する事で、管理を簡素化する蓄積しグラフ化する事で、管理を簡素化する 14
  15. 15. 1.監視 対応 一次切り分け リモート対応 エスカレーション (原因調査) エスカレーション – インフラや開発会社 – お客様への状況報告 動作確認 腕の 見せどころ 動作確認 改善提案 見せどころ 15
  16. 16. まず抑えたいサバカン超基本 1.監視1.監視 ~異常事態はすぐに気付こう~ 2. バックアップ ~異常事態はすぐに直そう~ 3. セキュリティ3. セキュリティ ~異常事態の発生を抑えよう~~異常事態の発生を抑えよう~ 16
  17. 17. 2.バックアップ • 監視バックアップの問題点• 監視バックアップの問題点 – どこの領域をどの間隔で何世代、どこに保存すればいいか? • 領域• 領域 – データ:コンテンツ / データベース / ログ – イメージ:OSから丸ごと全て取得 • 頻度と世代 – イメージ:OSから丸ごと全て取得 – 1日1回 / 1ヶ月に1回 • 保存先 – 1日1回 / 1ヶ月に1回 – 7世代 / 31世代 • 保存先 – サーバー内 / バックアップサーバー – ファイルサーバー– ファイルサーバー – オフィスのPC 17
  18. 18. 2.バックアップ • 領域• 領域 イメージデータ イメージ 1回のデータが大きい データ 1回のデータが少ない 不要なデータも取得 ファイル単位でのリカバ 必要なデータのみ取得可 ファイル単位でのリカバ ファイル単位でのリカバ リができない リストアに時間がかかる ファイル単位でのリカバ リができる リストアが早い リストアに時間がかかる 初期化からも直ぐに復旧 可 リストアが早い 初期化からのリカバリ時 はサーバー構築が必要 可はサーバー構築が必要 18
  19. 19. 2.バックアップ • 頻度と世代• 頻度と世代 ⇒当然、頻度高く、世代を多く取得するとコスト増⇒当然、頻度高く、世代を多く取得するとコスト増 バックアップ取得時は、サーバーが高負荷状態に。 対象サイトの更新頻度は? ⇒更新しないのに毎日取得しますか? ⇒更新が多いのに月に1回ですか? 対象サイトに担保する完全性は?対象サイトに担保する完全性は? ⇒何日前までのデータがあればよいですか? 19
  20. 20. 2.バックアップ • 保存先• 保存先 ⇒保存先により、メリットデメリットがあります。 メリット デメリット サーバー内 ・すぐにデータ復旧ができる ・イメージでの取得ができないサーバー内 ・すぐにデータ復旧ができる ・イメージでの取得ができない ・全データ消失リスク有 専用バックアップサーバー ・別筺体に保存 ・スムーズな復旧 ・予め大容量HDD確保の必要性 ・容量不足時、サーバー追加orリプ レースレース ・バックアップサーバー故障時、デー タ消失の可能性あり クラウドファイルサーバー(S3/nifty ・自動で2重、3重の複製を作成する ・青天井で高コストの可能性クラウドファイルサーバー(S3/nifty クラウドストレージ 等) ※クラウドサーバー利用想定 ・自動で2重、3重の複製を作成する ・利用した容量のみ費用を支払う ・イメージ取得が簡単 ・青天井で高コストの可能性 ・コンパネ操作やAPI連携など知識が 必要 ・転送速度がやや遅い ローカルPC ・遠隔地保管ができる ・紛失、盗難のリスクローカルPC ・遠隔地保管ができる ・紛失、盗難のリスク 20
  21. 21. 2.バックアップ • データとイメージを使い分けて、最適化 – データ:– データ: • 日々のコンテンツ、DBを取得 • 7世代~31世代 – イメージ:– イメージ: • サイトへの新機能実装前後 • セキュリティアップデート前後 都度取得ができているか確認は必須です。都度取得ができているか確認は必須です。 21
  22. 22. まず抑えたいサバカン超基本 1.監視1.監視 ~異常事態はすぐに気付こう~ 2. バックアップ ~異常事態はすぐに直そう~ 3. セキュリティ3. セキュリティ ~異常事態の発生を抑えよう~~異常事態の発生を抑えよう~ 22
  23. 23. • 不正アクセスを防ぐ対策 3.セキュリティ • 不正アクセスを防ぐ対策 – ファイアウォール – アクセス権管理 インターネット – アクセス権管理 – 脆弱性管理 ○ × – 教育 • 不正アクセスを前提とした対策 ○ • 不正アクセスを前提とした対策 – 暗号化 – ログ取得 社内– ログ取得 – バックアップ • イメージ取得 ○ 社内 個人 情報 • イメージ取得 ○ 23
  24. 24. 3.セキュリティ ハッキング攻撃の傾向と変化 2000年~ 2004年~ 現在~ 対象 不特定多数 (ユーザーやサービス、組織) 不特定多数 (ユーザーやサービス、組織) 特定ユーザー、サービス、組織 (企業や制御システム、政府・公的機関)(ユーザーやサービス、組織) (ユーザーやサービス、組織) (企業や制御システム、政府・公的機関) •スクリプトやツール •マルウェア・スパイウェア •スパムメール •フィッシングサイト •標的型攻撃(APT攻撃) •ゼロデイ攻撃やソーシャル・エンジニアリ •ブルート・フォース攻撃 •バッファオーバーフロー •DoS攻撃/DDoS攻撃 •ルートキット •ボットネット •SQLインジェクション ングなどを複合的に利用した非常に高度で 複雑な攻撃 •外部攻撃型 方法 •DoS攻撃/DDoS攻撃 •SQLインジェクション •XSS (クロスサイト・スクリ プティング) •フェイク・アラート –DoS攻撃/DDoS攻撃 –脆弱性を悪用した攻撃・侵入 •内部侵入型•フェイク・アラート •内部侵入型 –ゼロデイ攻撃を利用した不正プログ ラムを、メールやUSB経由で内部端 末に送り込み、内部から情報搾取や末に送り込み、内部から情報搾取や 攻撃を試行 24
  25. 25. 3.セキュリティ「ウェブ改ざん」の被害(IPA) ウェブ改ざんの「原因分類」ウェブ改ざんの「原因分類」 (2012年1月~2013年5月) 新たな手口の追加による “ウェブ改ざん連鎖”の拡大“ウェブ改ざん連鎖”の拡大 25
  26. 26. 3.セキュリティ なぜ事故は起こるのか? 時期、 対象サービス 消失 機密 概要時期、 対象サービス 消失 機密 概要 2009年 3月 Google Docs ○ 意図しない相手とドキュメント共有、脆弱性 4月 Core IP Networks LLC ○ サーバーー押収 6月 Vaserv.com ○ ウェブサイト消失、脆弱性6月 Vaserv.com ○ ウェブサイト消失、脆弱性 10月 Sidekick ○ データ消失、SANのアップグレードに失敗 2010年 5月 Amazon Web Service ○ システムダウン、データ消失 2月 Gmail ○ メール消失 2011年 2月 Gmail ○ メール消失 5月 NTT WebARENA ○ サーバーー接続不可 6月 Dropbox ○ パスワード不要でアクセス可能 7月 Distribute ○ 顧客データ消去7月 Distribute ○ 顧客データ消去 9月 InMotion Hosting ○ インデックスファイル改ざん 2012年 1月 さくらのクラウド ○ データ消失 6月 ファーストサーバーー ○ ○ 手¥順ミスにより、5676件、99.6%の顧客データ消失6月 ファーストサーバーー ○ ○ 手¥順ミスにより、5676件、99.6%の顧客データ消失 2013年 3月 Evernote ○ パスワードハッキング 5月 Yahoo!JAPAN ○ 外部アクセスにより、最大2200万件のYahooIDが抽出 26 2014年 6月 ベネッセコーポレーション ○ 内部アクセスにより、最大2260万件の顧客個人情報が流出 2009~2014年 報道より抜粋
  27. 27. 3.セキュリティ なぜ事故は起こるのか? • セキュリティ上のリスク データの分散 共有データの分散 共有 × A社 B社 C社 × × × ×仮想化 アウトソーシング × × × ハイパーバイザ 仮想OS × ?OS × ? 27
  28. 28. セキュリティ対策のレイヤー 3.セキュリティ セキュリティ対策のレイヤー セキュリティ診断 •ツールやサービスの利用 • 脆弱性診断 ネットワークレイヤー •セキュリティポリシーに基づき、侵入検知・防御 (IP制限) • Firewall • IPS •セキュリティポリシーに基づき、侵入検知・防御 (IP制限) •ブラックリスト実装 • IPS システム(アプリケーション)レイヤー • システムシステム(アプリケーション)レイヤー •要求仕様に基づき、セキュリティ・プログラミング •ホワイトリスト定義 • システム • ファイル改ざん検 知 •ホワイトリスト定義 • ログ監査 28
  29. 29. 3.セキュリティ • 脆弱性への対応• 脆弱性への対応 – 脆弱性診断– 脆弱性診断 • 第三者により、脆弱性がないか評価する – 不要なサービスの停止– 不要なサービスの停止 – JPCERTの情報を的確に取得– JPCERTの情報を的確に取得 脆弱性は突然発見されます。日々確認が必要。脆弱性は突然発見されます。日々確認が必要。 29
  30. 30. 3.セキュリティ • DOS攻撃への対応 監視システムが、ポートの接続不可を検知(ダウンアラート) • DOS攻撃への対応 監視システムが、ポートの接続不可を検知(ダウンアラート) ログで、アクセス元のIPアドレスを確認 ポートの直接アクセス? ログで、アクセス元のIPアドレスを確認 海外?同一IP/同一ネットワーク? 不正アクセス FWで、特定IPを規制 アクセス集中か攻撃かの見極めが重要 30
  31. 31. 3.セキュリティ • 改ざんへの対応 – FWでFTPやSSH接続のIP制限 – コンパネへのIP制限、認証、ポート変更– コンパネへのIP制限、認証、ポート変更 – 改ざん検知サービスの利用– 改ざん検知サービスの利用 31
  32. 32. 振り返り • 皆様が管理されるサーバーはいかがですか ?? • 監視、バックアップ、セキュリティの設計• 監視、バックアップ、セキュリティの設計 、設定について振り返ってみましょう。 32
  33. 33. 振り返り 監視 判定監視 判定 監視ポイントはちょうどよいか アラートは直ぐに気付けるか 障害時の対応方針が明確か障害時の対応方針が明確か サーバーのリソースは最適か バックアップ いつまでの状態に戻せるかいつまでの状態に戻せるか 戻し方が明確か 戻せるものと戻せないものが明確か バックアップデータはどこにあるかバックアップデータはどこにあるか バックアップデータの複製があるか セキュリティ FWなどを利用しているかFWなどを利用しているか アクセス権を分けているか PWは複雑か 脆弱性の管理を行っているか脆弱性の管理を行っているか IP制限を実施しているか 33
  34. 34. 次に抑える応用編 4.サーバ安定稼働4.サーバ安定稼働 ~安定稼働させる為のヒント~ 5.クラウド活用5.クラウド活用 ~クラウドを利用する為のポイント~~クラウドを利用する為のポイント~ 34
  35. 35. 次に抑える応用編 4.サーバ安定稼働4.サーバ安定稼働 ~安定稼働させる為のヒント~ 5.クラウド活用5.クラウド活用 ~クラウドを利用する為のポイント~~クラウドを利用する為のポイント~ 35
  36. 36. 4.サーバー安定稼働 1. 【増強・増設】を最短・最速 – 拡張可能なインフラ選択– 拡張可能なインフラ選択 – 負荷分散の運用ノウハウ 2. 【チューニング】でサーバーの最適化2. 【チューニング】でサーバーの最適化 インフラ 運用 36
  37. 37. サイト概要 4.サーバー安定稼働 サイト概要 • 提供サービス• 提供サービス – 健康食品販売サイト • サーバー構成 – LB :ELB 1– LB :ELB×1 – ウェブ:EC2×2– ウェブ:EC2×2 – DB :RDS×1 ウェブ ウェブ DB 37
  38. 38. 1.【増強・増設】を最短・最速 4.サーバー安定稼働 1.【増強・増設】を最短・最速 スケールアップ • スケールアップ• スケールアップ – DB ウェブ ウェブ • スケールアウト – ウェブ:2台+3台 ウェブ ウェブ DB– ウェブ:2台+3台 – DB :1台+1台 スケールアウト – DB :1台+1台 ウェブ ウェブ ウェブ DBスケールアウト 38
  39. 39. 1.【増強・増設】を最短・最速 4.サーバー安定稼働 スケールアウト 1.【増強・増設】を最短・最速 ウェブ スケールアウト マスター D B マスター レプリケーション スケールアップ D B スレーブスケールアウト 39
  40. 40. 【ウェブ】対応 4.サーバー安定稼働 ウェブは、スケールアウトし易い 【ウェブ】対応 ウェブは、スケールアウトし易い ただし、コンテンツの同期に配慮が必要 40
  41. 41. 4.サーバー安定稼働 • ウェブのスケールアウト対策• ウェブのスケールアウト対策 – NFSサーバーの導入 • コンテンツの一元管理ができる• コンテンツの一元管理ができる • コンテンツ同期不要 • NFSに負荷がかかる可能性有 負荷分散 ウェブウェブウェブ ウェブ NFS 高負荷 41
  42. 42. 4.サーバー安定稼働 • ウェブのスケールアウト対策• ウェブのスケールアウト対策 – コンテンツ同期スクリプトを作成 • lsync+rsync• lsync+rsync • 知識が必要 負荷分散負荷分散 ウェブウェブウェブ ウェブ コンテンツ アップロード コンテンツ同期 42
  43. 43. 【DB】対応 4.サーバー安定稼働 DBは、一筋縄にいかない 【DB】対応 DBは、一筋縄にいかない 43
  44. 44. 【DB】スケールアウトの難しい理由 4.サーバー安定稼働 【DB】スケールアウトの難しい理由 RDBMS(リレーショナルデータベース)RDBMS(リレーショナルデータベース) – スケールアップ(増強)が得意 負荷分散の方針 △○ △○スケールアップ (増強) △スケールアウト (増設) ○ 44
  45. 45. DBのスケール設計 4.サーバー安定稼働 対策例1:キャッシュサーバーの利用 DBのスケール設計 マスター 更新系 スレーブ 参照系 Cache 更新系 参照系 対策例2:テーブルの分割対策例2:テーブルの分割 購買情報 会員情報 商品情報 会員情報 45
  46. 46. 4.サーバー安定稼働 多彩なオプションと スケールアウトとスケールアップのスケールアウトとスケールアップの 合わせ技合わせ技 +++ 46
  47. 47. 2.【チューニング】でサーバーの最適化 4.サーバー安定稼働 • ウェブ 2.【チューニング】でサーバーの最適化 スケール結果を元に • ウェブ – 同時接続数 スケール結果を元に サーバーの最適化 • DB – セッション数 サーバーの最適化 – セッション数 – メモリ– メモリ • 増強 – CloudFront ウェブ ウェブ DB 47
  48. 48. シナリオによる負荷テスト 4.サーバー安定稼働 シナリオによる負荷テスト シナリオ送信 負荷をかける 応答 ★サイトシナリオ作成 ★サイトシナリオの実行 ★負荷と閾値状況(WWWサーバー) 1000010001 総リクエスト同時リクエスト項目 ★サイトシナリオ作成 ★サイトシナリオの実行 ★負荷と閾値状況(WWWサーバー) アクセス状況(閾値) ・平均値 ・最大値 300 400 500 リクエストの処理時間(ミリ 40000040004 50000050005 30000030003 20000020002 1000010001 9項目以降は、大きく変化 ・平均値 ・最大値 0 100 200 300リクエストの処理時間 秒) 90000090009 60000060006 80000080008 50000050005 70000070007 5000 9000 9項目以降は、大きく変化 処理時間が掛かる 0 1 2 3 4 5 6 7 8 9 10 リクエストの処理時間 テスト項目 90000090009 10000001000010 11000001100011 48
  49. 49. サイトレスポンス計測して、ボトルネック解析 4.サーバー安定稼働 サイトレスポンス計測して、ボトルネック解析 ●:コンテンツエラー ●:正常●:正常 ●:応答なし 最適化前 最適化後 – 負荷テスト実施、ページ毎のレスポンスをグラフ化– 負荷テスト実施、ページ毎のレスポンスをグラフ化 – ボトルネック特定、解析レポート 49
  50. 50. リソース利用状況の可視化、最適化 4.サーバー安定稼働 リソース利用状況の可視化、最適化 – 数値の可視化で、リソース最適化の材料を増やす – 不要リソース・コスト削除、ボトルネック調査で運営指針設定– 不要リソース・コスト削除、ボトルネック調査で運営指針設定 50
  51. 51. 次に抑える応用編 4.サーバ安定稼働4.サーバ安定稼働 ~安定稼働させる為のヒント~ 5.クラウド活用5.クラウド活用 ~クラウドを利用する為のポイント~~クラウドを利用する為のポイント~ 51
  52. 52. 5.クラウド活用 • クラウドって? – 利用したい時に利用したいだけ– 利用したい時に利用したいだけ – 直ぐに利用できる– 直ぐに利用できる – サイズ変更も楽々 – ハードウェアが壊れても直ぐに復旧– ハードウェアが壊れても直ぐに復旧 – オプションが豊富で、組み合わせ自由– オプションが豊富で、組み合わせ自由 52
  53. 53. 5.クラウド活用 • デメリットは? – 毎月の費用が変動– 毎月の費用が変動 – サーバー管理は必要– サーバー管理は必要 – 物理サーバーより高くなる事もある 53
  54. 54. 5.クラウド活用セキュリティは? • セキュリティは?• セキュリティは? – クラウドそれ自体は安全です– クラウドそれ自体は安全です 例: 取得認証 AWS ・HIPAA(米国医療基準) AWS ・HIPAA(米国医療基準) ・SOC1/SSAE16/ISAE1402 /SOC2 /SOC3 (内部統制) ・PCI DSS(カード会社基準) ・ISO27001(情報セキュリティ) 等・ISO27001(情報セキュリティ) 等 ニフティクラウド ・ISO27001 ・SOC2 ・PCI DSS 等・PCI DSS 等 利用サーバーのセキュリティ対策が重要利用サーバーのセキュリティ対策が重要 54
  55. 55. 5.クラウド活用 • ガイドラインの活用 「クラウドサービス利用のための情報セキュリティ • ガイドラインの活用 「クラウドサービス利用のための情報セキュリティ マネジメントガイドライン」(経済産業省) http://www.meti.go.jp/press/2013/03/20140314004/20140314004-2.pdf セキュリティの観点から、1)利用者、2)クラウド事業者に必要なセ キュリティの管理策をまとめた文書。「ISO/IEC27002:2005」をベー スに、利用の視点から15個にわたる大項目にまとめている。 ポイント アウトソーシングの留意点と大きく変わらない。リスアウトソーシングの留意点と大きく変わらない。リス クを定期的に確認していく。 55
  56. 56. 5.クラウド活用 • 代表的なサービス,機能 – サーバー– サーバー – ロードバランサー – FW– FW – RDBMS(DB) – キャッシュ – オブジェクトストレージ– オブジェクトストレージ – オートスケール – テンプレート作成– テンプレート作成 56
  57. 57. 5.クラウド活用 • クラウド選定時の注意点 – 定額制か、従量制か?– 定額制か、従量制か? – PaaSサービスを利用するか?– PaaSサービスを利用するか? – エンタメ系?エンタープライズ系? – コントロールパネルでできる事は?– コントロールパネルでできる事は? システム要件に応じたクラウド選定を! 57
  58. 58. 5.クラウド活用 • クラウド導入のポイント• クラウド導入のポイント • 適用範囲の設定が必要 • クラウドサービスの特徴を把握する • 経産省ガイドライン等を活用し、• 経産省ガイドライン等を活用し、 セキュリティリスクをコントロールセキュリティリスクをコントロール 58
  59. 59. 次に抑える応用編 6.まとめ 59
  60. 60. 6.まとめ • 超基本 – 監視・バックアップ・セキュリティ– 監視・バックアップ・セキュリティ • やる事をおさえたら後は毎日実施• やる事をおさえたら後は毎日実施 • 継続運用実施で、クライアントも安心• 継続運用実施で、クライアントも安心 60
  61. 61. 6.まとめ • サーバー安定稼働 – スケールアップ– スケールアップ – スケールアウト– スケールアウト • 初期の設計段階で、考慮が必要 • 中長期の展望を見せる事でクライアン トも安心!トも安心! 61
  62. 62. • クラウド活用 – 特徴を理解し、まずは使ってみよう– 特徴を理解し、まずは使ってみよう • 貴社の課題はクラウド向きか?• 貴社の課題はクラウド向きか? • スケールアップ、スケールアウトとク• スケールアップ、スケールアウトとク ラウドの相性はバツグン! 62
  63. 63. 6.まとめ • 運用に正解無し • PDCAサイクルでシステムに合った管理を• PDCAサイクルでシステムに合った管理を 行いましょう。行いましょう。 – P:設計・設定 – D:監視及び障害対応 – C:原因調査– C:原因調査 – A:改善提案 63

×