クラウドサービスは安全？

旭川ICT協議会セミナー2012年7月26日

坂本和士旭川ICT協議会教育部会　副部会長

KSシステム　代表

1

• クラウドサービスの定義• 国内の利用動向• 導入への懸念事項• なぜセキュリティ対策が必要か

前半

2

• 求められるセキュリティ要件および対策• 事故事例を考える

後半

3

• サービス内容による区分　SaaS、PaaS、IaaS

• サービス提供範囲による区分　パブリッククラウド、プライベートクラウド

クラウドサービスの定義

4

• Software as a Service• ネットワークを通じて顧客にアプリケーションソフトの機能を必要に応じて提供

• ワンシステム・マルチテナント• 電子メール、グループウェア、CRMなど

SaaS

5

• Google Apps（Gmail 他）• Microsoft Online Services• Salesforce CRM• サイボウズ Office

SaaSのサービス例

6

• Platform as a Service• ネットワークを通じて顧客にアプリケーションソフトを利用するためのプラットフォームを提供

• OS・ミドルウェア・ストレージ・データベース

PaaS

7

• Google App Engine• Windows Azure• Amazon S3、DynamoDB、SimpleDB• Force.comプラットフォーム• Heroku

PaaSのサービス例

8

• Infrastructure as a Service• ネットワークを通じて顧客にハードウェアやネットワークなどのインフラを提供

• 仮想サーバ・仮想スイッチ・オートスケール

IaaS

9

• Amazon EC2• ニフティクラウド• GMOクラウド Public• BIGLOBEホスティング• Asahikawa CB Data Center

IaaSのサービス例

10

• 一般利用者を対象に提供されるクラウドサービス• 一般的にクラウドサービスというとこちらを指す• 比較的に低コストで各種サービスを利用できる

パブリッククラウド

11

• 企業が自社内でクラウドコンピューティングのシステムを構築しクラウドサービスを提供

• システム構築のイニシャルコストやランニングコストがかかる

プライベートクラウド

12

• IDC Japan が2012年4月に実施したユーザー動向調査「2012年　国内クラウド市場調査」の結果

• クラウド導入は堅調に進んだが「検討したが利用しない」とする企業が大幅に増加

• パブリッククラウドを利用中の企業が具体的に評価したプロバイダー／ベンダー数は3社以内

• プライベートクラウド市場では「差別化」が構築を行うベンダーの課題に

国内の利用動向

13

クラウドの利用状況

14

評価・検討したパブリッククラウドのプロバイダー／ベンダー数

15

• クラウドサービスというものがよくわからない• クラウドサービスを提供しているプロバイダーや構築を行うベンダーを知らない

• 本当にコストが下がるの？上記に加えて、、、

導入への懸念事項

16

セキュリティ対策が不安j-*9B*D}Z��f

/B+9Pv��HY /B+9Il�!��p

���� ���� ��

��� ���

� �� �� �� � ���

����

�������$! ������('�(�

����������&# �����

"�%

)

Se�Pv���/B+9Il���`X5.AC7)xk�$%�OKw�XV&i'��%

Pv��Il���� �����=F4�5.AC7)~t&i"���Pv����Un�5.AC7)KQ&i'��%�#� �]`XR{J���%`X247?E6<8+,(�M�_T 5.AC7)���%z|J�

��quly����\�h�

�

/B+9Pv����5.AC7)G�HY�bd������/B+9Pv��/B+9Il���`X5.AC7)xkT �� �����=F4�5.AC7)~t&i'��%�

��quly����\�h�� /B+91F;4�`X5.AC7)xk���%(D0F8�kXVg���quly����\�h�

`X5.AC7)��$ Il����%247?�v�����������%HY& ��%R��%

/B+9Pv���#�`X5.AC7)>:3@D8-*9B*D�}Z

Pv��s�$%5.AC7)C4/�N����^a

Il��c���%Wr���Pv��%

[}or

`X5.AC7)xk�$%Pv��Il��M��L�m�

17

クラウド事業者への要求j-*9B*D}Z��f

/B+9Pv��HY /B+9Il�!��p

���� ���� ��

��� ���

� �� �� �� � ���

����

�������$! ������('�(�

����������&# �����

"�%

)

Se�Pv���/B+9Il���`X5.AC7)xk�$%�OKw�XV&i'��%

Pv��Il���� �����=F4�5.AC7)~t&i"���Pv����Un�5.AC7)KQ&i'��%�#� �]`XR{J���%`X247?E6<8+,(�M�_T 5.AC7)���%z|J�

��quly����\�h�

�

/B+9Pv����5.AC7)G�HY�bd������/B+9Pv��/B+9Il���`X5.AC7)xkT �� �����=F4�5.AC7)~t&i'��%�

��quly����\�h�� /B+91F;4�`X5.AC7)xk���%(D0F8�kXVg���quly����\�h�

`X5.AC7)��$ Il����%247?�v�����������%HY& ��%R��%

/B+9Pv���#�`X5.AC7)>:3@D8-*9B*D�}Z

Pv��s�$%5.AC7)C4/�N����^a

Il��c���%Wr���Pv��%

[}or

`X5.AC7)xk�$%Pv��Il��M��L�m�

18

なぜセキュリティ対策が必要？

• 情報資産は企業にとって重要な資産の一つ• 情報資産を社外に置くことにより新たなリスクが発生する　→　社内よりコントロールが難しい

• 米国の Gartner が2008年に発表した「Assessing the Security Risks of Cloud Computing」でクラウドベンダー（プロバイダー）を選択する際に7項目のリスクがあると説明している

19

特権ユーザーによるアクセスアウトソースされたサービスは、企業のIT部門が社内プログラムに対して行使する「物理的管理」「論理的管理」「人的管理」の影響を受けない。そのため、 社外で処理された機密性の高いデータは最初からリスクを含有している。したがって、自社データを扱うベンダー側の人員については、なるべく多くの情報を収集しておく。「従業員の具体的な情報をベンダーに提供させ、特権を持つ管理者や彼らに対するア

クセス監視／制御を行うよう求める必要がある」 （Gartner）

20

コンプライアンス関連たとえ管理するのがクラウド・ベンダーの側だとしても、自社データの安全性と完全性は最終的に顧客が責任を持つことになる。通常のベンダーであれば、基本的に外部の監査や安全性のチェックを受けている。だが、この種の調査を拒否しているクラウド・ベンダーもいるため、そうしたベンダーには重要性の最も低いデータしか任せられないことになる。（Gartner）

21

データの保管場所多くの場合、データがホスティングされる正確な場所は顧客にはわからない。実際、どの国にデータが保管されているのかすら見当もつかないだろう。したがって「データの保管／処理は明確な法的権限に基づいて行われるのか」「現地のプライバシー保護規制に従うことを契約条件に盛り込めるか」といった点を事前に確認しておきたい。（Gartner）

22

データの隔離クラウド内のデータは、通常はほかの顧客データとシステム環境を共有することになる。こうした環境下では暗号化が有効な対策となるが、これも万全ではな い。Gartnerは「どのような方法で、保管しているデータを隔離しているのかを調べておく必要がある」と述べている。クラウド・ベンダーは、経験豊富な専門家と共に暗号化スキームを設計し、検証結果を顧客に示さなければならない。「暗号化スキームに不備があると、データがまったく使えないという事態が発生する。ごく一般的な暗号化であっても、利便性を損なう場合がある」（Gartner）

23

データの復旧クラウド・ベンダーは、たとえデータの保管場所を明らかにしないとしても、災害が起こった際に顧客のデータおよびサービスがどうなるのかは開示しておくべきである。「データおよびアプリケーション・インフラのレプリケーションを行っていないサービスの場合、大規模災害時に顧客が致命的なダメージを被る」 と、Gartnerは警鐘を鳴らしている。「完ぺきなレストレーションを実行するだけの備えがあるのか」「復旧までにどれぐらい時間がかかるのか」をベン ダーに確認しておく必要がある。（Gartner）

24

調査に対する協力姿勢クラウド・コンピューティングにまつわる不適切行為や違法行為は、現状では調査が難しいとGartnerは述べている。「多数の顧客のログイン記録やデー タが共同保管されていたり、複数のデータセンターに分散保管されていたりする可能性があるため、クラウド・サービスの実態を追跡調査するのは非常に困難だ。特定の調査にベンダーが協力するという条件を契約に盛り込むことができる、もしくは当該のベンダーがそうした調査を積極的に受け入れてきたという実績がある場合を除き、調査や証拠開示に対する要求はまず通らないと考えたほうがよい」（Gartner）

25

長期にわたる事業継続性理想を言えば、決して倒産せず、大手企業に買収もしくは吸収されることのないクラウド・ベンダーを選びたい。とはいえ、そうした出来事が起こった後もデー タを利用し続けられるよう顧客も準備しておく必要がある。「契約を結ぶ可能性のあるベンダーとの話し合いでは、データの回収方法と、その際に利用する フォーマットが後継アプリケーションに移植可能なものであるか否かを確認しておきたい」（Gartner）

26

国内でも同様の指針が発表済

• 経済産業省が2011年4月に発表• 「クラウドサービス利用のための情報セキュリティマネジメントガイドラインの公表～クラウドサービスの安全・安心な利用に向けて～」

• http://www.meti.go.jp/press/2011/04/20110401001/20110401001.html

27

休憩

28

求められるセキュリティ要件　および対策• 導入前• 導入後• クラウドサービス利用者もしくはクラウド事業者の双方にあてはめて考える

29

導入前

• 情報セキュリティポリシーの確立と実施• クラウドサービス／プロバイダー／ベンダーの選択• 責任と権限の明確化• 社内業務の整理

30

情報セキュリティポリシーの 確立と実施• 社内の情報資産を整理しセキュリティポリシーを策定する（トップダウンで）

• 無理のない体制を整え実施する（可能であれば実施専門の部署を置く）ー　特にトラブル時対応

• クラウドサービスに載せる情報資産を明確にするパブリッククラウド利用の場合は必須

31

クラウドサービス／プロバイダー／ベンダーの選択• サービス内容• 第三者認証（または監査）• サービスレベル合意（SLA）• セキュリティホワイトペーパー• サービスダッシュボード

32

サービス内容

• 自社業務を載せることが可能か• 載せる際に、どこまで自社業務を整理・変更する必要があるか（コストと実効性の比較）

• 自社業務の内容から、どのくらいの稼働率、ダウンタイム、アップタイムが必要で、それを実現しているか（サービスレベル合意）

33

第三者認証（または監査）

• 以下の第三者認証があるISMS（JIS Q27001）Pマーク（JIS Q15001）PCI DSS（クレジット業界のグローバル基準）SAS70（米国　内部統制関連）HIPPA（米国　医療情報）

• 第三者認証の取得が難しい場合は情報セキュリティ監査を定期的に実施し報告書が公開されているか

34

サービスレベル合意（SLA）

• もともとは通信事業者がネットワークサービスの通信品質を保証するために行った契約形態

• サービス内容について保証設定値を設け、未達だった場合の罰則や補償を規定

• 国内のITサービスにおいては事業継続できない時の罰則として支払いの免除を記載しているだけのものが多い

• サービス最大停止時間などの具体的な内容と実現する技術に関する情報を要求する必要がある

35

セキュリティホワイトペーパー

• 提供しているサービスのセキュリティ対策を定義• 現時点で公開しているプロバイダー／ベンダーは少ない　　　　　　　　　　　　　　　　　　　　Amazon Web Services　ニフティクラウド

• セキュリティに特化したホワイトペーパーでなくても参考になる 　　　　　　　　　　　　　　　Windows Azure　Google Apps 他

36

サービスダッシュボード

• クラウドサービスではログの取得が自由にできない場合が多い

• システムの最新状態を正しく把握するためにサービスダッシュボードを活用する

• この機能の使いやすさはクラウドサービス選択の重要な要素の一つと言える

• 複数のクラウドサービスを利用する時に各サービスダッシュボードの統合ができる仕組みがあると良い（API等）

37

サービスダッシュボードの例

ニフティクラウドのサービスダッシュボード

38

コミュニケーションスキル

• サポート窓口のコミュニケーションスキルを確認する（電話・メール）

• 情報公開の内容および更新頻度を確認する

39

責任と権限の明確化

• 事故発生時の対応を素早く行うために、社内の関係部署や人員について責任と権限を明確にする

• クラウド利用者とクラウドプロバイダー／ベンダーの間で、責任と権限および補償内容を明確にする　　　　　　　　→　まだまだ発展途上と言える　

40

社内業務の整理

• パブリッククラウドを利用する場合、提供内容に社内業務を合わせる必要がある　　　　　　　　　　→　クラウドサービスの選択の仕方が重要

• プライベートクラウドを利用する場合でも、単純にサーバーの引っ越しをするだけでは不十分　　　　　　→　過去のゴミを整理

41

導入後

• 運用状況の監視　　　　　　　　　　　　　　　　• 経営層と管理者層間の密なコミュニケーション• トラブル対応の訓練

42

運用状況の監視

• サービスダッシュボードを活用する　　　　　　　　　　　　　　　　• サービスダッシュボードの外部向けAPIが用意されているなら各種情報収集の自動化を行う

• サーバー上の各種ログ取得および視覚化ツールも活用する

• 正常処理時の上限・下限値を設定しておき、異常発生時に素早く通知する手段を用意する

43

経営層と管理者層間の密な　　コミュニケーション• 経営層は「コンピュータはわからない」と考えない→　情報資産も銀行の預金残高も同じく重要

• 管理者層は「どうせ社長はわからないし」と考えない　　　　　　　　　　　　　　　　　　　　　　→　わかってもらえるように提供する情報を工夫

• 普段からコミュニケーションが密であればトラブル発生時にスムーズな対応ができる

44

トラブル対応の訓練

• クラウドサービス導入後素早く、できればテスト稼働時にトラブルを想定した訓練を行う

• システム環境およびデータの復元• 関係者（社内・顧客）への連絡• クラウドプロバイダー／ベンダーとトラブル時の対応を打合せておく（プライベートクラウドの場合、訓練に参加することを契約に入れておくこともできる）

45

事故事例を考える

• セールスフォース• ファーストサーバ

46

セールスフォースの事故内容

• SaaSの事故事例• 2012年6月28日朝、本番系と待機系のストレージに二重障害が発生し共有メモリが破損するとともに、一部顧客が約5時間にわたってアクセスできなくなった

• さらに7月10日にデータセンターで電源障害が発生し、一部顧客は2日間にわたってサービスを利用できなかった

47

セールスフォースの事故から　　見えてきたもの• SaaSの場合、アプリケーション全体（管理、バックアップ、リカバリー等）を維持しているのはプロバイダーなので、プロバイダーの考え方次第では顧客が口を挟めない　　　　　　　　　　　　　　　　→　独自にバックアップをとることが難しい場合がある

• SLAで保証しているアップタイムを知り、自社がどこまでのダウンタイムを許容するか決める

• リカバリーの管理手順や保守管理のレベルも「完全」に理解しておく

• 用意されているならテスト環境のデータを本番環境と同じにしておく

48

ファーストサーバの事故内容• IaaSおよびSaaSの事故事例

• 2012年6月20日17時頃データ消失が発生

• 原因は管理プログラムのバグにより該当するすべてのサーバのすべてのファイルを消去した

• ファーストサーバ内のバックアップデータも消失

• 被害顧客件数は5,698件でデータ復旧は不可能と断定　　　　→　Webやメールの復旧が不可能ということ

• サイボウズを利用していた約400社は顧客管理や営業記録がすべて無くなり事業継続が困難な企業も？

• 現在、ヤフーの支援を受けて対応中

49

ファーストサーバの事故から　　見えてきたもの• バックアップの概念の違い低料金でサービスを提供するために外部サーバではなく同一サーバ内にバックアップをとっていた

• 損害賠償対応はすると報道されているが、、、

• 事実と異なる説明があったもよう本番系と同時に待機系を動かしている　←　×外部データにバックアップを保存　←　×

• これらを信じた顧客がバカなのか、それとも優良誤認なのか？　→　今後、裁判になったなら注目する必要有

• 独自のバックアップ体制を用意しておく

50

まとめ（導入前）

• 情報セキュリティポリシーの確立と実施• クラウドサービス／プロバイダー／ベンダーの選択• 責任と権限の明確化• 社内業務の整理

51

まとめ（導入後）

• 運用状況の監視　　　　　　　　　　　　　　　　• 経営層と管理者層間の密なコミュニケーション• トラブル対応の訓練

52

クラウドサービスは　　　　　これからの技術• クラウドサービスならではの新たな問題が発生している

• あらゆるリスクを想定し対策を行う• 最新情報に通じておく• 上手に活用するならITコスト削減につながる

53

ご清聴ありがとう　ございました

54