Successfully reported this slideshow.

2013年03月 第32回WebSig24会議「社内LAN撲滅運動」

37,257 views

Published on

第32回WebSig24/7 会議でサーバーワークスの大石が発表した、「社内LAN撲滅運動」のスライドです。

▼元ブログはこちら
http://blog.serverworks.co.jp/ceo/?p=328

AWS専業のクラウドインテグレーターであるサーバーワークスが、なぜISMS認証の取得を目指すようになったのか、そしてどのように考え、どんなサービスを利用したのか、その背景と舞台裏についてお伝えしました。

Published in: Business
  • オンラインストレージサービスを社内に置かれたファイルサーバの共有ドライブのように使うとネットワーク帯域が浪費されるが、サムネイルやメタデータの閲覧あるいは内容のプレビューに対応したネットワーク帯域に優しいサービスへの移行はワークスタイルの変化を強いるので、ファイルのやり取りで仕事を進めるやり方に慣れてる人達からの抵抗が大きいみたいな話が次の課題なんじゃないかなーと何となく予想。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

2013年03月 第32回WebSig24会議「社内LAN撲滅運動」

  1. 1. クラウド専業のインテグレーターがIISSMMSS認証を取得した舞台裏 社内LLAANN 撲滅運動 •  株式会社サーバーワークス •  大石 @@ooooiisshhii
  2. 2. おおいし クラウド の すけ 大石 蔵人之助 株式会社サーバーワークス 代表取締役–  昭和48年7月20日 新潟市生まれ–  コンピューターとの出会いは10歳の頃–  当時はPC-8001にベーマガのプログラムを入力する日々–  コンピューターの購入は11歳 / SHARP X1–  中2の時に初めてプログラムが書籍に掲載–  高校入学記念にX68000を購入–  仙台の大学に進学・本格的なオタクライフ開始–  大学生の時にパソコン通信開始。本格的にシェアウェアを販売–  総合商社でインターネットサービスプロバイダー事業に携わる–  2000年にECのASPを立ち上げるべく起業
  3. 3. 持ちネタ 切腹
  4. 4. もし今日のセッションで 皆さんに何も得るものがなければ・・・ 切腹します
  5. 5. 大学向�けサービス 約 200 校2004年 2011年
  6. 6. 昔の合格発表
  7. 7. 今の合格発表
  8. 8. シェア 6600%%
  9. 9. ところが・・・
  10. 10. 必要なサーバー数 課題 無駄 必要なコスト 2月 8月
  11. 11. そこで、
  12. 12. 22000077年からAAWWSSのテスト利用を開始
  13. 13. 22000088年 社内サーバー購入�禁止令
  14. 14. 22001111年 AWS Solution Provider 22001122年 Amazon Partner Network最上位の Advanced Consulting Partner に認定
  15. 15. IISSMMSS認証取得のきっかけ 3・11
  16. 16. サイトダウンの理由 被災者: 非被災者: 救急医療など、支援 義援金やボランティが受けられる場所を ア活動など、支援で 探す目的で きる方法を探す目的
  17. 17. EC2
  18. 18. 義援金受付システム
  19. 19. 負荷分散装置 20台の、物理的に離れた 2つのデータセンターに設置 されたウェブサーバー 1日に500万通送信できる メールサーバー 物理的に離れたデータセンター間で 環境構築22時間 リアルタイムに同期し、かつ1時間おきにアプリ開発4488時間 バックアップを取るデータベース
  20. 20. タイムチャート: 33月1144日 日本赤十字社様との打ち合わせ 33月1155日 サイト復旧 33月1177日 義援金管理システム稼働開始
  21. 21. 事実 震災後の迅速な義援金の募集に一役買ったのは、
  22. 22. こうした事例が 呼び水となって・・・
  23. 23. AWSによるSI売上 2010年 2011年 2012年
  24. 24. 突然の変化 AAWWSSによる災害対策が急激に クローズアップ 大企業のニーズに応えるため、 IISSMMSSが必須に!
  25. 25. ISMSあるある •  IISSMMSSを取ることで、生産性が下がる •  IISSMMSSとったからノートPPCCを持ち出せない •  「iiPPhhoonnee持ち込んだらダメ」とか 「働きたくない会社に成り下がる」 「昔はよかった」
  26. 26. ISMSをとっても 絶対にゆずれない点 •  IISSMMSS認証を取っても 生産性の低下は最小限に •  ノートPPCC,, スマホの持ち出しは必須 •  社長のわたしが働きたい環境を!
  27. 27. ISMS認証取得を始めるときに 一番大切なもの
  28. 28. 経営者のメッセージ!
  29. 29. サーバーワークスの場合 •  IISSMMSS認証は「営業のために取る!」 •  だから「売上があがる方向�でなければ NNGG!!」 •  「守り」と「攻め」を両立すること!! 「情報セキュリティ基本方針」で コミット!
  30. 30. 実際にやったこと
  31. 31. 社内システムの因数分解 開発 営業 共通 管理系 サービス
  32. 32. 従前 営業 開発 • 自前SFA • Excel 共通サービス 管理系 • Exchange • Ac6ve  Directory • SharePoint • ファイルサーバー
  33. 33. IISSMMSS後 開発 営業 • GitHub • Salesforce • Amazon  EC2 共通サービス 管理系 • Google  Apps • Ac6ve  Directory • Box • OneLogin • yammer • MDM
  34. 34. 開発者向�け
  35. 35. 開発者向�けサービス •  開発環境はEECC22(これは前から) •  受託系 •  サービス系 –  RReeddMMiinnee –  PPiivvoottaall TTrraacckkeerr –  SSuubbvveerrssiioonn –  GGiittHHuubb –  JJeennkkiinnss –  JJeennkkiinnss –  これらをEECC22へ
  36. 36. 営業
  37. 37. みんなSSaalleessffoorrcceeとか 興味なさそうなので 飛ばします!
  38. 38. 共通
  39. 39. 共通サービス •  GGooooggllee AAppppss –  メール、カレンダー –  DDrriivveeはBBooxx経由で利用 –  GGooooggllee++のハングアウトは活躍の場が増えそう
  40. 40. 共通サービス •  YYaammmmeerr –  社内メッセージング –  社内メール禁止!全てYYaammmmeerrで! –  ffaacceebbooookkグループにしないのは、投稿ミス を無くすため!
  41. 41. MDM
  42. 42. 共通サービス •  MMDDMM –  酔っ払ってiiPPhhoonnee無くしたりしても、社員が安 心して仕事するために必須 –  BBYYOODDといえども、SShhaarreeとかPPeerrffeeccttDDaarrkkと かはダメよ!っていうポリシーをちゃんと展開で きる –  世の中のサービスはiiPPhhoonnee,, AAnnddrrooiidd対応が大半 –  WWiinnddoowwss,, OOSSXX,, iiPPhhoonnee,, AAnnddrrooiiddに対応した サービスとなるとサイバネットくらいしか選択肢 なし(判断時)
  43. 43. 共通サービス •  SSSSOO:OOnneeLLooggiinn –  多数のIIDDを管理するために契約 –  唯一、うまくいっていない! –  OOnneeLLooggiinnがダウンしたら全サービスにログ インできないとかドMMすぎワロタ –  各サービスのパスワードを複雑にして覚えら れなくするのは必須だが、SSSSOOにするか各端 末のパスワードマネージャーにするか微妙 •  最近の議論:SSSSOOのサービスを22つ契約 すればいいんじゃない・・?
  44. 44. 〜議論編〜
  45. 45. 社内の議論 11..  そもそもセキュリティ大丈夫なの? 22..  DDrrooppbbooxx使いたい! 33..  AAccttiivveeDDiirreeccttoorryyってどうなのよ? 44..  BBYYOODD
  46. 46. 議論① クラウドのセキュリティが なんとなく不安…�
  47. 47. 一般的なシステムの脅威 外部データ漏えい 攻撃者によるアタック内部 物理的アクセスによる データ盗難
  48. 48. クラウド特有の脅威 仮想マシン 場所が分からなくて、 なんとなく不安・・・仮想マシン 物理マシンを共有したら、 意図せず漏洩したりしないか オペレーターが情報をもって仮想マシン いったりしないか?
  49. 49. AWS(Amazon) は 何をしているのか?
  50. 50. Amazonの回答 11..  第三者認証 22..  テクノロジー 33..  場所の隠匿
  51. 51. 第三者認証 •  ISMS(ISO27001)•  PCI DSS Level 1•  FISMA-Modarate•  ISAE3402 SOC1 (formerly known as SAS70 type II)
  52. 52. テクノロジー •  特許技術で、Xenを拡張•  AWS社員も顧客のデータに アクセスできない
  53. 53. 場所の隠匿 • 場所は明かさない • 見学もさせない ?
  54. 54. 中国  –  2500年前
  55. 55. 戦っても勝ち目はない趙の決断 「降伏と見せかけて  始皇帝を暗殺しよう」
  56. 56. 秦の始皇帝暗殺を企んだ刺客が持って行ったもの地図
  57. 57. 地図を渡す=完全な服従の意 地図を渡す=攻撃が成功する 可能性が極めて高くなる
  58. 58. 場所の情報はそれほど 重要な情報なので、AAWWSSは場所を明かさない
  59. 59. 安心 < 安全
  60. 60. AAWWSSのセキュリティモデル 外部 外部 利用者 データ漏えい アタック が防御 仮想マシン 内部同士の共有も、 明示しない限り禁止 仮想マシン 物理的 AAWWSSが 内部 防御 アクセス
  61. 61. 「預ける」否定派へ質問 1. 会社経営に必須の資源は何ですか?2. それはどこにありますか?
  62. 62. なぜ大切なお金を銀行に預けるのか? • セキュリティ –  社内より銀行の方が安全 • 可用性 –  預けた支店が事故を起こしても口座情報は保持 • 利便性 –  AATTMM+カードでどこでもアクセス
  63. 63. AAWWSSも、銀行と同じです • セキュリティ –  社内よりAAWWSSの方が堅牢な物理セキュリティを確保 • 可用性 –  クラウド側で高い耐久性を維持 (SS33のファイル耐久性は9999..999999999999999999%%) • 利便性 –  ネット越しにどこからでも簡単にアクセス
  64. 64. NASAと自社とでは、 どちらがIITTインフラの セキュリティレベルを保つ 仕組みが整っているか?
  65. 65. AAWWSSで、われわれの組織内の インフラよりもはるかに高い セキュリティを保てるようになる NASA  ジェット推進研究所(JPL)のシニア・ソリューション・アーキテクト  カワジャ・シャムズ(Khawaja  Shams)氏  hPp://www.atmarkit.co.jp/ait/ar6cles/1301/24/news087.html
  66. 66. セキュリティを高めるために、 銀行にお金を預けることと同様 システムもクラウドに預けた方が、セキュリティレベルが上がる
  67. 67. •  注意 クラウドなら何でも銀行と一緒 といっている訳ではないです! ちゃんとアセスメントをして、セキュリティを保つ能力の高い クラウドを選択して利用
  68. 68. 議論② ファイルサーバーどうするか? DDrrooppbbooxx使いたいんですけど!
  69. 69. スタート地点 •  社内のファイルサーバーは無くすが、 すべてオンラインでは不便 •  オフライン対応(ローカル同期)できる ストレージサービスを検討 •  候補 –  DDrrooppbbooxx ffoorr TTeeaammss –  BBooxx –  SSuuggaarrSSyynncc ※まだGGooooggllee DDrriivveeは出ていませんでした
  70. 70. Dropboxの問題 管理者 社内領域 分からない 見えない ○×○×○×○×○ ×○×○×○×○× ○×○×○×○×○ ○×○×○×○× ○×○×○×○×○ ×○×○×○×○× ○×○×○×○× ×○×○×○×○× ○×○×○×○×○ ○×○×○×○× ×○×○×○×○× ○×○×○×○× 社外ユーザー 機密性・責任追従性の担保に問題あり!
  71. 71. Boxなら… 管理者 社内領域 分かる 見える ○×○×○×○×○ ×○×○×○×○× ○×○×○×○×○ ○×○×○×○× ○×○×○×○×○ ×○×○×○×○× ○×○×○×○× ×○×○×○×○× ○×○×○×○×○ ○×○×○×○× ×○×○×○×○× ○×○×○×○× 社外ユーザー 機密性・責任追従性を確保可能
  72. 72. 議論③ AAccttiivveeDDiirreeccttoorryyどうするか?
  73. 73. AAccttiivveeDDiirreeccttoorryy •  社内PPCCの認証 •  認証に加えてセキュリティポリシーまで 配布できるできる子! •  MMaaccが増えてきて存在が微妙に・・・
  74. 74. AAccttiivveeDDiirreeccttoorryy •  各種クラウドサービスがAADDへ対応済み •  IIDDの管理基盤として良くできている •  セキュリティポリシーの配布はMMDDMMにや らせるが、IIDD管理として継続して利用!
  75. 75. 議論④ BBYYOODD ((BBrriinngg yyoouurr oowwnn ddeevviiccee))
  76. 76. 会社的には •  PPCCやデバイスの購入�コストが浮いてラッ キー •  資産管理とかしなくていいからラッキー •  みんながやる気だしてくれてラッキー
  77. 77. 個人のメリット •  自分の好きな端末で仕事できてうれし い! •  どこでも仕事ができるので、時間の自由 が増える!
  78. 78. 個人のデメリット •  端末購入�の費用を負担しなくてはいけない •  個人の情報と会社の情報の管理が面倒 (端末暗号化が必須とか) •  無くしたりしたときの責任分担ががが
  79. 79. このままだと 会社のメリット 個人のメリット<
  80. 80. 補助でフェアに •  PPCCのBBYYOODDだと33,,000000円/月 •  携帯のBBYYOODDだと22,,000000円/月 –  携帯通話は、005500番号を付与して005500の分は 会社負担
  81. 81. そして社内LLAANN撲滅へ・・・
  82. 82. 全クラウド化の結果 • 社内サーバーは22台に! –  AAccttiivveeDDiirreeccttoorryy DDoommaaiinn CCoonnttrroolllleerr •  EECC22へ移行中 –  AAsstteerriisskk(IIPP電話) •  IIPP電話の外部サービスへ移行中
  83. 83. 全部クラウド化できると・・・
  84. 84. 社内LLAANN撲滅!
  85. 85. 社内LLAANN撲滅! •  ネットワーク上の社内・社外という区別 が無くなる! •  どこでも仕事ができる環境が整う! •  会社の引っ越しも在宅勤務もスムーズ に!
  86. 86. なぜこんなことをしているのか?調達モデルの変化
  87. 87. 今までのSI のどが 渇いた! ○×○×○×○×○ ○×○×○×○×○ ×○×○×○×○× ×○×○×○×○× ○×○×○×○× ○×○×○×○× 調達チーム 品質チーム ○×○×○×○×○ ○×○×○×○×○ ○×○×○×○×○ ○×○×○×○×○ ×○×○×○×○× ×○×○×○×○× ×○×○×○×○× ×○×○×○×○× ○×○×○×○× ○×○×○×○× ○×○×○×○× ○×○×○×○× バケツを 川から 水の量を 水の品質を 調達する係 水をくむ係 計る係 調べる係
  88. 88. これからのSI のどが 渇いた!    どうぞ! H2O H H O   アマゾン工場 (クラウド事業者)
  89. 89. クラウド型調達では •  非常に小さいチーム •  すばやいデリバリー •  つくらない技術≒分子式の知識 が重要に! –  組み合わせ分子式の例 •  AWSのCDP •  Heroku と EC2+SQS •  Salesforce と S3
  90. 90. 会社<個人
  91. 91. 環境変化とパフォーマンス SSIIの仕組みが変わってくる 個人のパワーが今までよりも大きくなる 気持ちよく働ける環境の大切さが増す 社内制度がパフォーマンスに与える割合が増える
  92. 92. 「遅れている」 •  GGoooogglleeの検索結果が隠蔽 •  ffaacceebbooookkにアクセスできない •  高速ネットの為にはネカフェに行かなく てはいけない
  93. 93. でも日本の会社も・・・ •  22cchhへの書き込み制限 •  SSNNSSのアクセス制限 •  オフィスのLLAANNからしか繋がらない社内 システム
  94. 94. 情報共産主義 •  ベルリンの壁(ファイヤーウォール、 出入�り口のゲート)で外と中を分け る! •  自由なんてあるかボケ!社員は会社が 指定した仕事だけしていればいいんで す! •  持ち出しなんて当然厳禁!持ち込み だって許しません!!
  95. 95. 情報民主化 •  社員の仕事を監視・制限しても生産性 もモチベーションもあがらない。むし ろ自由を与えてイノベーションの種を まいてほしい! •  自由なデバイスでたのし気持ちよく仕 事してほしい! •  会社と個人の相互信頼こそが、 セキュリティのキモ!
  96. 96. 予測不能 • リーマンショック • 震災・原発事故 • AAKKBBから前田敦子に 続いて板野友美�まで 引退!?
  97. 97. ロードマップを描くことはできません。 しかし知恵を磨くことはできます。               --- ウォーレン・バフェット
  98. 98. 震災が私たちに教えてくれたこと •  大切なことは、 予測の精度を高めるのでは無く、 予測不能な事態がおきても最善手を打つ 「適応マネジメント」
  99. 99. 私たちが得た学び •  ガチガチの社内システムより、必要な時 に柔軟に使えるクラウドの方が適応力が 高い •  適応力こそ、これから先の不透明な時代 を生き抜く必要条件 •  クラウドかどうかは本質的な問題ではな い。信頼関係こそが本当の課題
  100. 100. 本日のまとめ
  101. 101. まとめ ①ISMSの設計には経営者の想い、相互の信頼といったシステム以外の部分が最も大切!②クラウドのセキュリティ 銀行正しい選択で、むしろ社内にあるよりセキュリティレベル向上!③クラウド時代に必要なクラウド分子式の知識を身につけて、働きやすい環境を自分で創ろう!
  102. 102. 切腹しろ という方は お申し出下さい
  103. 103. そうでない方は ぜひこの事例を参考に 働きやすさとセキュリティの 両立を!
  104. 104. ありがとうございました @ooishi

×