クラウドセキュリティ基礎

セキュリティ・キャンプ2015

2015年8月14日 @ 幕張

株式会社サイバーエージェント仲山昌宏

この講義の目的

•クラウド時代のWebシステムについて

•サーバ設計、構築、運用技術の基礎

• サービスの無停止とスケーラビリティを実現する設計

•情報セキュリティとして必要な施策

• ID管理と監査

• 機密情報の保存

2

自己紹介

•仲山昌宏

•いわゆるセキュリティエンジニア……ではありません

•秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア

•株式会社サイバーエージェントDCソリューションクラウドエンジニア

3

会社紹介

•株式会社サイバーエージェント

•「アメーバで検索検索♪」の会社

•半分はインターネット広告

•もう半分がAmebaとゲーム

4

https://www.cyberagent.co.jp/ir/about/factsheet/

インターネットの企業の屋台骨

• 1時間サービスが止まったときの被害はおいくら？

5

インターネットの企業の屋台骨

• 1時間サービスが止まったときの被害はおいくら？

• 2015年3Qの課金売上高：54億円（四半期決算）

• 1時間あたり247万円

• 1分あたり4万円

•ピークタイム

•月末月初

•イベントのラストスパート

6

サイバーエージェントの特徴

•膨大な新サービス

• 2015年だけで既に10サービス以上の提供を開始

•頻繁な人材流動

• 2011年スマホシフト、2014年アメーバ構造改革

•明確な撤退ルール

•リリースから2年を目処に成果が出なければ撤退

7

どういうことだってばよ

•流行ればどかんとサーバが必要になる

•もちろんソフトウェアのチューニングも実施

•「まずは」サーバ追加で時間を「稼ぐ」

•廃れればどんどん縮小させる

•縮小しきれない過剰投資は「損失」である

•新しいプロジェクトには新しい技術を積極導入

•プロジェクトごとに使う技術もバラバラ

•サーバの共有はむずかしい8

それクラウドでできるよ

•必要なサーバを必要な分だけ使える！やっためう！すごいめう！！

9http://hixyon.tumblr.com/post/108161470958/20140709

クラウド #とは

NIST（米国国立標準技術研究所）による基本特徴

1. オンデマンド・セルフサービスAPIでなんでもできる

2. 幅広いネットワークアクセスネットワーク経由でできる

3. リソースの共用共用する潤沢なリソースプールがある

4. スピーディな拡張性すぐに利用可能

5. サービスが計測可能であること自らの利用量が適切に計測（されて課金される）

10

定義って重要なので、ちょっとだけかたい話をします。

クラウド #とは

サービス形態による分類

• SaaS

• 具体的なアプリケーションとして提供される。

• DropboxとかGmailとか

• PaaS

• アプリケーションが動く環境が用意される。

• Herokuとか

• IaaS

• サーバ一式が用意される。いわゆるレンタルサーバに近い。

• ネットワーク機能（FW、LB等）も提供されたりする。11

普段身近にあるクラウドはSaaSだけど、今回は主にIaaSの話をします。

クラウド #とは

運用方法による分類

•パブリッククラウド

•大規模な事業者が運用して数多くの利用者が共有

• AWSとかいろいろ

•プライベートクラウド

•社内で単独で運用

12

パブリッククラウド

•大規模な事業者

•豊富なリソースにもとづく最適化

•膨大な開発能力にもとづく豊富な機能

•共有責任モデル

•ざっくりOSから下は事業者がセキュリティを担保

•各種セキュリティガイドラインへの準拠

•むしろベストプラクティスが実装された環境

• OSとその上は利用者がセキュリティを自力で担保

13

「膨大な開発能力」←ここ重要です

プライベートクラウド

•既存の自前でデータセンタ借りてサーバ置くモデル

• OpenStackなどのクラウドコントローラでクラウド化

•基本機能はAmazon等と似たようなことができる

•プライベートでの差別化

•既にノウハウや購買力を持つ場合

•システム間が密結合（消極的理由）

14

まだまだプライベートクラウドの価値も低くは無いのです……

要するに

•サービスを止めれば膨大な機会損失

•サービスたくさん作るし流行るときは垂直立ち上げ利用増加に追いつかないなら死ぬしかないじゃない

•パブリックかプライベートかはともかく、クラウドで最適化しないともう無理！

•クラウドでスケーラビリティのあるシステムを！

15

やっぱりクラウドって「銀の弾丸」っぽいですよね！

やっぱりクラウドすごい

•必要なサーバを必要な分だけ使える！やっためう！すごいめう！！

16http://hixyon.tumblr.com/post/108161470958/20140709

やっためう！すごいめう！←フラグ

スケーラビリティの実際

•すぐにサーバを増減できる

17

スケーラビリティの実際

•すぐにサーバを増減できる

↓

•作ったサーバに環境構築してすぐ本番投入できる

•本番投入中のサーバでもすぐに消せる

18

台数の増減が容易と言うメリットを掘り下げるとざっくりこの二つ分解できます。

「ペット」と「家畜」問題

•これまで：サーバ＝ペット

• 1台1台名前を付けて、手間を掛けて育てていく

•少しおかしくなっても直して死ぬまで面倒を見る

•これから：サーバ＝家畜

•集団の役割だけを見て、1台ずつの個別の面倒は見ない

•おかしくなったら殺す

19

10000匹のペットなんて面倒見切れません

Discussion #1クラウド環境のアーキテクチャ

• Webシステムのアーキテクチャを考えてみよう

•クラウド環境では何が問題になるか

•どうすれば解決できるか

•ポイント

•作ったサーバに環境構築してすぐ本番投入したい

•本番投入中のサーバでもすぐに消したい

20

21

＜こんな意見が出ました＞

・仮想化ソフトウェアの上にしかシステムが無いので、障害が起きたときにデータが失われてしまうリスクが増してしまう・複数の顧客でサーバを共有していると個人情報とか不味いケースがありそう・本番環境を作るまでの作業を自動化とかしないと意味が無い・負荷分散するとPHPのセッションファイルが同期できない・集約することで、裏のネットワークとかがボトルネックになりそう

ポイント1作ったサーバに環境構築してすぐ本番投入したい

•サーバの環境構築の手間がかかる

•ミドルウェア入れて設定ファイルを変更

•アプリの動作に必要なライブラリも入れる

•最新のアプリケーションをデプロイ（設置）

•アプリケーション設定（DB認証情報等）も設置

•アプリケーションのプロセスを起動

22

これらを全部自動化しないとねっ♪

ポイント2本番投入中のサーバでもすぐに消したい

•サーバ内にデータを保存できない

•データベース

•セッション情報

•アクセスログ、エラーログ、デバッグログ

•システムログ（syslog, イベントログ）

•一時的に手で入れたテスト用設定

23

思った以上にいろいろなモノをサーバの中に保存しているものです。

StatelessサーバとStatefulサーバ

• Statelessサーバ

•アプリケーションを動かすサーバ

•データを中に一切保存せず、コピーすれば動くレベル

•いつでも追加/削除しやすい状態を保つ

• Statefulサーバ

•データベース、ログ

•追加/削除がしづらいので死ぬ気で守る

•スペックアップや分散DBの利用でスケーラビリティ確保

24

責務をはっきりと分割して、メリハリ付けて管理しましょう。

Statelessサーバの指針

• Twelve-Factor App

• http://12factor.net/ja/

•（いくつか宗教的な項目もあるものの）今までに提起された最適解の「まとめ」

25

本日覚えて帰って欲しいキーワード

Twelve-Factor App

I. コードベース

II. 依存関係

III. 設定

IV. バックエンドサービス

V. ビルド、リリース、実行

VI. プロセス

26

VII. ポートバインディング

VIII. 並行性

IX. 廃棄容易性

X. 開発/本番一致

XI. ログ

XII. 管理プロセス

全て重要なのですが、時間が足りないので、個人的に特徴的と思うポイントのみ……

Twelve-Factor AppI. コードベース

バージョン管理されている1つのコードベースと複数のデプロイ

• 1つのコードベース

•アプリケーション全体が一つのレポジトリ

•それ以外は、依存ライブラリか参照先の外部システム

•複数のデプロイ

•本番環境、ステージング環境、開発環境

27

Twelve-Factor AppIII. 設定

設定を環境変数に格納する

•デプロイごとに異なる設定

• DB接続先とかドメイン名とか

•アプリ内の設定のことではない

•アプリ本体に設定を保存しない

•起動時に動的に設定できるようにする

•あたらしい種類のデプロイをすぐ作れるようにする

28

Twelve-Factor AppVII. ポートバインディング

ポートバインディングを通してサービスを公開する

•アプリが直接TCP(UDP)のポートで待ち受ける

• Apache/nginxのような汎用ウェブサーバを経由しない※前段キャッシュサーバなどとは別の話

•このへんはちょっと宗教的な論争もあり

29

Twelve-Factor AppXI. ログ

ログをイベントストリームとして扱う

•時系列で継続して吐き出され続ける「ストリーム」

•アプリは吐き出すだけで保存先を問わない

•開発環境ならコンソールで眺めてみんな大好き目grep

•本番環境ならログ用ストレージに転送

30

Twelve-Factor App

I. コードベース

II. 依存関係

III. 設定

IV. バックエンドサービス

V. ビルド、リリース、実行

VI. プロセス

31

VII. ポートバインディング

VIII. 並行性

IX. 廃棄容易性

X. 開発/本番一致

XI. ログ

XII. 管理プロセス

じゃあ、Statefulサーバは？

「銀の弾丸」は無いが、現実的な選択肢は増えている。

1. スケールアップで対応

•「Fusion ioは甘え」でもいいじゃないか

2. 分散DB

• Cassandra、HBase、MongoDBとかとか

3. すごいストレージサービスを使う

•数秒間だけ何百何千台のサーバを使えるGoogle BigQuery

32

3番目の選択肢の登場でできることが増えてきました

脱線：分散DBにおけるCAP定理

33

•どれかが犠牲になる

•可用性バルスできない

•一貫性バルス書いた筈なのに読めたり読めなかったり※結果整合性

•ネットワーク分断耐性バルス書いたのにサーバが死んで消えた

可用性

一貫性ネットワーク

分断性

分かるようで分からない悪い例えです。

クラウド時代のサーバ設計

• Statelessサーバ

•アプリを動かす

•台数でコントロールできる状態を保つ

• Statefulサーバ

•データを保存

•気合い入れて頑張る

34

クラウド時代の脆弱性対応

•アプリケーションの脆弱性が圧倒的に多い

•つまり……？

35

このへんからセキュリティにも踏み込んで行きます

Blue-Green Deployment

•もう1セット（Green）作って古い方（Blue）を捨てよう！

36

ｃ

L

B

サーバー

サーバー

サーバー

サーバー

③問題が無ければ古い環境（Blue）を廃棄

①新しいバージョン（Green）の環境を構築

②Greenにアクセス先を切り替え

DB

共通環境

脆弱性に限らず、一般的なテクニック動作が怪しかったらすぐ戻せるのが最大の特長

万能じゃない

• SSHとかStatefulサーバの脆弱性もある

•きちんと脆弱性を評価して優先度を決めよう！

•共通脆弱性評価システム：CVSS v2https://www.ipa.go.jp/security/vuln/CVSS.html

37

CVSS v2の基準

•基本評価基準 (Base Metrics)

•脆弱性そのものの特性

•機密性、完全性、可用性への影響、攻撃のしやすさ（ネットワーク経由の攻撃可否など）

•現状評価基準 (Temporal Metrics)

•今どれぐらいやばいか

•環境評価基準 (Environmental Metrics)

•二次被害の度合いとかその他の影響範囲38

覚えて帰って欲しいキーワードその2

CVSS実例

• CVE-2014-0160 Heartbleed

• Base Score: 5.0

• CVE-2014-3566 POODLE

• Base Score: 4.3

• CVE-2014-6271 Shellshock

• Base Score: 10.0

• CVE-2015-0235 GHOST

• Base Score: 6.8(RedHat) / 10.0(NVD)

39

実際のIaaS

•今回はこの二つを取り上げます

•さくらのクラウド

• Amazon Web Services （AWS）

40

実際のクラウド環境について具体的に話していきます。

基本的な機能は一緒

•サーバとネットワークを借りられる

• CPU数、メモリ容量を指定可能※あらかじめ用意されたパターンから選択

•ディスク容量を指定可能

•独自サブネットを持つ事が可能

•ファイアウォール

•ロードバランサー

41

違う点

• AWS独自の「高レイヤー」なサービス

42

43

うはｗｗｗサービス多すぎｗｗｗｗｗｗ

違う点

• AWS独自の「高レイヤー」なサービス

•割り切ったサービスレベル

•一つのサーバが突然死ぬくらいは「障害」ではない

•冗長化の枠組みを用意してるから冗長化は利用者の責任

•さくらのクラウドは1台ごとの稼働率で判断

44

各社のSLAを比較してみるとサービスの設計思想が見えて面白いですよ。

REST APIによるアクセス

•ほぼ全ての作業をAPIで利用可能

• APIのアクセスキーをあらかじめ取得

•コントロールパネルと同様の操作が可能

45

最後に出しましたが、クラウドの最大の特長です！！！！

Discussion #2クラウド環境ならではリスクって？

• AWSみたいな大規模なクラウド環境

•いくらでもサーバが作れる（リミットは一応ある）

• APIでさらに作りやすい

•どんなリスクが新しく増えたのか考えてみよう！

46

47

＜こんな意見が出ました＞

・アクセスキーの管理が面倒そう・アクセスキーが悪用されたときの被害がすぐ大きくなりそう・社内のシステムとの連携を考えないといけないのでは

わかりやすく誘導したのでそれに沿って回答してくれた班が多かったです。アクセスキーの管理が大変だ、という視点もその通りです。つい最近にHashicorpがVaultという認証情報の管理ツールを出したのもその文脈ですね。

APIが万能である故の問題

• APIのアクセスキーがあれば何でもできてしまう

•自動化プログラムとかにカジュアルに組み込みやすい

•なにかされたことにすぐに気付きにくい

• Amazonはさすがによくできている

•権限管理（IAM）と監査の仕組みが整っている

48

Two-Factor Appにもありましたがコードに直接認証情報を書いてはいけません

AWS Identity and Access Management （IAM）

•アカウント内にユーザーを作ることができる仕組み

• AWSは元々は1アカウント＝1認証情報（email/password)

•作成したユーザーごとに権限を細かく設定可能

•アクセス元も設定可能

• ID連携も可能（後述）

49

AWS CloudTrail

• APIの呼び出しを記録して送信する

• Amazon S3（ストレージサービス）に保管

•外部の分析サービスとの連携も可能

50

ID連携

•社内のログインシステムなどと連携

•ログインシステムが許可したユーザは、AWSのコンソールにそのままログイン可能

•ログインシステム側を作り込むことで、特定のプロジェクトに参加している正社員だけ連携、といったことも容易

•ログインさせたユーザーの権限も設定できる

51

IaaS以外でもできればID連携

•退職者リスク

•退職した従業員

•契約満了した協力会社

•仮に悪意は無くても管理が万全とは言えない

•できるかぎりID連携

• SAML、LDAP

52

ID連携できないクラウドサービス

• ID連携できないものも「把握」はしておく

•むやみやたら閉め出すのもリスク

•便利なモノは禁止してもこっそり使われてしまう

•把握はしておき、退職者を棚卸し

• Shadow IT

•管理されず把握もされていない外部サービス

•情報漏洩の流出源につながる

•ダメ、ゼッタイ！

53

最小権限の原則

•情報セキュリティで最も重要な原則

•必要最小限の権限だけを用意する

•例：アクセスキーの権限を最低限にする

• APIの接続元IPアドレス

•サンパウロでサーバ作成する権限は本当に必要？

54

本日覚えて帰って欲しいキーワードその3

個人情報とかの保存

•パブリッククラウドって大丈夫？

55

個人情報とかの保存

•パブリッククラウドって大丈夫？

•大丈夫です！（※きちんとやれば）

56

安全なデータの保存

•権限管理

•データベース、データベースサーバへの接続権限の最小化

•暗号化

•データベースの暗号化

•通信路等の保護

•ネットワークレベルの分離

•物理サーバ単位の専有化

57

クラウドでできることも増えてきたので、

自前のサーバとやることは変わりません。

「損失」の話、覚えてる？

58

「損失」の話、覚えてる？

• 1時間サービスが止まったときの被害はおいくら？

• 2015年3Qの課金売上高：54億円（四半期決算）

• 1時間あたり247万円

• 1分あたり4万円

•ピークタイム

•月末月初

•イベントのラストスパート

59

もうちょっと掘り下げてみよう

60

そもそも情報セキュリティ #とは

•機密性 Confidentiality

•アクセスが許可された人だけが情報を見られること

•完全性 Integrity

•情報が改竄されず正確であること

•可用性 Availability

•必要な時に情報にアクセスできること

•さっきの話はここしか見ていなかった

61

機密性が破られたときの損失

•個人情報漏洩

•アメーバ会員数4000万人×500円＝200億円（だいたい1年の利益分）

•会員流出に伴う課金売上減少

•アメブロPV減少に伴う広告収入源

•それ以後の機会損失

62

完全性が破られたときの損失

•ゲームのデータが大規模に改竄され信頼を失いサービス終了に追い込まれる

•本来売り上げていたはずの課金アイテムの売上減

•その他のゲームについての風評被害

•人気あるゲームが出せなくなった事による社員の流出

63

リスク評価

•ある程度以上のビジネス継続リスクは許容できない

•対策コストが見合わないリスクは受容してもよい

64

二つ極端な例を出しました。どちらも「ある程度以上のリスク」です。

小さな例も考えてみよう

•スマホのリズムゲームでチートをされたが、巧妙にも「非常に上手い人」と同レベルのスコアに留めている。

•スコアがその人本来の2倍になっていて、本来課金していたはずの回復アイテムの売り上げが半分に減っていた。

•ランキングを大きく崩すことはなく他者への影響がない

•売上全体額への影響はごく軽微

……そんなの本当に調べる価値あるの？

65

小さなリスクは身近にたくさんあるのでは？

小さな例も考えてみよう

•スマホのリズムゲームでチートをされたが、巧妙にも「非常に上手い人」と同レベルのスコアに留めている。

•スコアがその人本来の2倍になっていて、本来課金していたはずの回復アイテムの売り上げが半分に減っていた。

•ランキングを大きく崩すことはなく他者への影響がない

•売上全体額への影響はごく軽微

……そんなの本当に調べる価値あるの？

66

たとえば「ざっくり上限制限」でもよい

リスク評価

•リスクの可視化

•金額に落とすと定量的に評価できる

•失うものが少ないほど受容できるリスクが増える※行き過ぎた結果が「サイバーノーガード戦法」

67

判断が難しいときは、数字に落として定量的に判断すると納得しやすいです。

抑止防止検知回復

• 事前（予防）

• 抑止攻撃の機会を減らす

• 防止攻撃の被害を減らす

• 事後

• 検知攻撃されたことを発見する（ための枠組みをあらかじめ作る）

• 回復攻撃により低減したCIAを回復する（ための枠組みをあらかじめ作る）

• 全部大事だよ

• パッチあては「防止」でしかない

68

漏れなく考えるためには、こういうフレームワークに沿うとよいです。

抑止・防止

•攻撃の「機会」そのものを減らす

•対外的なアピール

•エンドポイントを気軽に見せない

•攻撃の「被害」を減らす

•関係者の権限を管理する

• 責務の分離

• 最小権限

69

検知

•侵入検知

• → 検知トラック

•操作の監査

• AWS CloudTrail

•監査ログの分析

•適切な意志決定者への報告、エスカレーション

70

回復

•影響の封じ込め

•特に情報流出

•サービスの素早い復帰

•そのた各種事後報告

•プレスリリースとか

•個人情報流出被害の告知義務

71

抑止防止検知回復おさらい

• ID管理と監査を軸としたセキュリティ施策

•抑止：ID管理と監査実施のアピール

•防止：適切なID管理と必要最小限の権限設定

•検知：監査ログの分析、異常検知

•回復：監査結果から影響範囲の確定、封じ込め対策

72

セキュリティ施策がスピード感を損なわないことの確認

•リスク・脆弱性の対応

•例）クラウドでのデプロイ高速化→パッチ当て早くなる

• ID管理と監査

•裏で取られているだけで利便性は損ねない

•むしろ全てAPI経由であることで記録が容易・確実に

73

最後に繰り返しますが、ビジネスのスピード感とのすりあわせは重要

まとめ

•クラウド時代のWebシステムについて

•サーバ設計、構築、運用技術の基礎

• サービスの無停止とスケーラビリティを実現する設計

•具体的なセキュリティ施策

• ID管理と監査

• 機密情報の保存

74