クラウドセキュリティ基礎 #seccamp
- 2. この講義の目的 • クラウド時代のWebシステムについて • サーバ設計、構築、運用技術の基礎 • サービスの無停止とスケーラビリティを実現する設計 • 情報セキュリティとして必要な施策 • ID管理と監査 • 機密情報の保存 2
- 3. 自己紹介 • 仲山昌宏 • いわゆるセキュリティエンジニア……ではありません • 秋葉原生まれ大手町育ちの 歌って踊れる江戸っ子インフラエンジニア • 株式会社サイバーエージェント DCソリューション クラウドエンジニア 3
- 4. 会社紹介 • 株式会社サイバーエージェント • 「アメーバで検索検索♪」の会社 • 半分はインターネット広告 • もう半分がAmebaとゲーム 4 https://www.cyberagent.co.jp/ir/about/factsheet/
- 6. インターネットの企業の屋台骨 • 1時間サービスが止まったときの被害はおいくら？ • 2015年3Qの課金売上高：54億円（四半期決算） • 1時間あたり247万円 • 1分あたり4万円 • ピークタイム • 月末月初 • イベントのラストスパート 6
- 7. サイバーエージェントの特徴 • 膨大な新サービス • 2015年だけで既に10サービス以上の提供を開始 • 頻繁な人材流動 • 2011年 スマホシフト、2014年 アメーバ構造改革 • 明確な撤退ルール • リリースから2年を目処に成果が出なければ撤退 7
- 8. どういうことだってばよ • 流行ればどかんとサーバが必要になる • もちろんソフトウェアのチューニングも実施 • 「まずは」サーバ追加で時間を「稼ぐ」 • 廃れればどんどん縮小させる • 縮小しきれない過剰投資は「損失」である • 新しいプロジェクトには新しい技術を積極導入 • プロジェクトごとに使う技術もバラバラ • サーバの共有はむずかしい 8
- 10. クラウド #とは NIST（米国国立標準技術研究所）による基本特徴 1. オンデマンド・ セルフサービス APIでなんでもできる 2. 幅広いネットワークアクセス ネットワーク経由でできる 3. リソースの共用 共用する潤沢なリソースプールがある 4. スピーディな拡張性 すぐに利用可能 5. サービスが 計測可能であること 自らの利用量が適切に計測（されて課金される） 10 定義って重要なので、 ちょっとだけかたい話をします。
- 11. クラウド #とは サービス形態による分類 • SaaS • 具体的なアプリケーションとして提供される。 • DropboxとかGmailとか • PaaS • アプリケーションが動く環境が用意される。 • Herokuとか • IaaS • サーバ一式が用意される。いわゆるレンタルサーバに近い。 • ネットワーク機能（FW、LB等）も提供されたりする。 11 普段身近にあるクラウドはSaaSだけど、 今回は主にIaaSの話をします。
- 12. クラウド #とは 運用方法による分類 • パブリッククラウド • 大規模な事業者が運用して数多くの利用者が共有 • AWSとかいろいろ • プライベートクラウド • 社内で単独で運用 12
- 13. パブリッククラウド • 大規模な事業者 • 豊富なリソースにもとづく最適化 • 膨大な開発能力にもとづく豊富な機能 • 共有責任モデル • ざっくりOSから下は事業者がセキュリティを担保 • 各種セキュリティガイドラインへの準拠 • むしろベストプラクティスが実装された環境 • OSとその上は利用者がセキュリティを自力で担保 13 「膨大な開発能力」←ここ重要です
- 14. プライベートクラウド • 既存の自前でデータセンタ借りてサーバ置くモデル • OpenStackなどのクラウドコントローラでクラウド化 • 基本機能はAmazon等と似たようなことができる • プライベートでの差別化 • 既にノウハウや購買力を持つ場合 • システム間が密結合（消極的理由） 14 まだまだプライベートクラウドの価値も 低くは無いのです……
- 15. 要するに • サービスを止めれば膨大な機会損失 • サービスたくさん作るし流行るときは垂直立ち上げ 利用増加に追いつかないなら死ぬしかないじゃない • パブリックかプライベートかはともかく、 クラウドで最適化しないともう無理！ • クラウドでスケーラビリティのあるシステムを！ 15 やっぱりクラウドって 「銀の弾丸」っぽいですよね！
- 18. スケーラビリティの実際 • すぐにサーバを増減できる ↓ • 作ったサーバに環境構築してすぐ本番投入できる • 本番投入中のサーバでもすぐに消せる 18 台数の増減が容易と言うメリットを 掘り下げるとざっくりこの二つ分解できます。
- 19. 「ペット」と「家畜」問題 • これまで：サーバ＝ペット • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • これから：サーバ＝家畜 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す 19 10000匹のペットなんて 面倒見切れません
- 20. Discussion #1 クラウド環境のアーキテクチャ • Webシステムのアーキテクチャを考えてみよう • クラウド環境では何が問題になるか • どうすれば解決できるか • ポイント • 作ったサーバに環境構築してすぐ本番投入したい • 本番投入中のサーバでもすぐに消したい 20
- 22. ポイント1 作ったサーバに環境構築してすぐ本番投入したい • サーバの環境構築の手間がかかる • ミドルウェア入れて設定ファイルを変更 • アプリの動作に必要なライブラリも入れる • 最新のアプリケーションをデプロイ（設置） • アプリケーション設定（DB認証情報等）も設置 • アプリケーションのプロセスを起動 22 これらを全部自動化しないとねっ♪
- 23. ポイント2 本番投入中のサーバでもすぐに消したい • サーバ内にデータを保存できない • データベース • セッション情報 • アクセスログ、エラーログ、デバッグログ • システムログ（syslog, イベントログ） • 一時的に手で入れたテスト用設定 23 思った以上にいろいろなモノを サーバの中に保存しているものです。
- 24. StatelessサーバとStatefulサーバ • Statelessサーバ • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 24 責務をはっきりと分割して、 メリハリ付けて管理しましょう。
- 25. Statelessサーバの指針 • Twelve-Factor App • http://12factor.net/ja/ • （いくつか宗教的な項目もあるものの） 今までに提起された最適解の「まとめ」 25 本日覚えて帰って欲しいキーワード
- 26. Twelve-Factor App I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス 26 VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス 全て重要なのですが、時間が足りないので、 個人的に特徴的と思うポイントのみ……
- 27. Twelve-Factor App I. コードベース バージョン管理されている1つのコードベースと 複数のデプロイ • 1つのコードベース • アプリケーション全体が一つのレポジトリ • それ以外は、依存ライブラリか参照先の外部システム • 複数のデプロイ • 本番環境、ステージング環境、開発環境 27
- 28. Twelve-Factor App III. 設定 設定を環境変数に格納する • デプロイごとに異なる設定 • DB接続先とかドメイン名とか • アプリ内の設定のことではない • アプリ本体に設定を保存しない • 起動時に動的に設定できるようにする • あたらしい種類のデプロイをすぐ作れるようにする 28
- 29. Twelve-Factor App VII. ポートバインディング ポートバインディングを通してサービスを公開する • アプリが直接TCP(UDP)のポートで待ち受ける • Apache/nginxのような汎用ウェブサーバを経由しない ※ 前段キャッシュサーバなどとは別の話 • このへんはちょっと宗教的な論争もあり 29
- 30. Twelve-Factor App XI. ログ ログをイベントストリームとして扱う • 時系列で継続して吐き出され続ける「ストリーム」 • アプリは吐き出すだけで保存先を問わない • 開発環境ならコンソールで眺めてみんな大好き目grep • 本番環境ならログ用ストレージに転送 30
- 31. Twelve-Factor App I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス 31 VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス
- 32. じゃあ、Statefulサーバは？ 「銀の弾丸」は無いが、現実的な選択肢は増えている。 1. スケールアップで対応 • 「Fusion ioは甘え」でもいいじゃないか 2. 分散DB • Cassandra、HBase、MongoDBとかとか 3. すごいストレージサービスを使う • 数秒間だけ何百何千台のサーバを使えるGoogle BigQuery 32 3番目の選択肢の登場で できることが増えてきました
- 33. 脱線： 分散DBにおけるCAP定理 33 • どれかが犠牲になる • 可用性 バルスできない • 一貫性 バルス書いた筈なのに 読めたり読めなかったり ※結果整合性 • ネットワーク分断耐性 バルス書いたのに サーバが死んで消えた 可用性 一貫性 ネットワーク 分断性 分かるようで分からない悪い例えです。
- 34. クラウド時代のサーバ設計 • Statelessサーバ • アプリを動かす • 台数でコントロールできる状態を保つ • Statefulサーバ • データを保存 • 気合い入れて頑張る 34
- 37. 万能じゃない • SSHとかStatefulサーバの脆弱性もある • きちんと脆弱性を評価して優先度を決めよう！ • 共通脆弱性評価システム：CVSS v2 https://www.ipa.go.jp/security/vuln/CVSS.html 37
- 38. CVSS v2の基準 • 基本評価基準 (Base Metrics) • 脆弱性そのものの特性 • 機密性、完全性、可用性への影響、 攻撃のしやすさ（ネットワーク経由の攻撃可否など） • 現状評価基準 (Temporal Metrics) • 今どれぐらいやばいか • 環境評価基準 (Environmental Metrics) • 二次被害の度合いとかその他の影響範囲 38 覚えて帰って欲しいキーワード その2
- 39. 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
- 40. 実際のIaaS • 今回はこの二つを取り上げます • さくらのクラウド • Amazon Web Services （AWS） 40 実際のクラウド環境について 具体的に話していきます。
- 41. 基本的な機能は一緒 • サーバとネットワークを借りられる • CPU数、メモリ容量を指定可能 ※あらかじめ用意されたパターンから選択 • ディスク容量を指定可能 • 独自サブネットを持つ事が可能 • ファイアウォール • ロードバランサー 41
- 44. 違う点 • AWS独自の「高レイヤー」なサービス • 割り切ったサービスレベル • 一つのサーバが突然死ぬくらいは「障害」ではない • 冗長化の枠組みを用意してるから冗長化は利用者の責任 • さくらのクラウドは1台ごとの稼働率で判断 44 各社のSLAを比較してみると サービスの設計思想が見えて面白いですよ。
- 45. REST APIによるアクセス • ほぼ全ての作業をAPIで利用可能 • APIのアクセスキーをあらかじめ取得 • コントロールパネルと同様の操作が可能 45 最後に出しましたが、 クラウドの最大の特長です！！！！
- 46. Discussion #2 クラウド環境ならではリスクって？ • AWSみたいな大規模なクラウド環境 • いくらでもサーバが作れる（リミットは一応ある） • APIでさらに作りやすい • どんなリスクが新しく増えたのか考えてみよう！ 46
- 48. APIが万能である故の問題 • APIのアクセスキーがあれば何でもできてしまう • 自動化プログラムとかにカジュアルに組み込みやすい • なにかされたことにすぐに気付きにくい • Amazonはさすがによくできている • 権限管理（IAM）と監査の仕組みが整っている 48 Two-Factor Appにもありましたが コードに直接認証情報を書いてはいけません
- 49. AWS Identity and Access Management （IAM） • アカウント内にユーザーを作ることができる仕組み • AWSは元々は1アカウント＝1認証情報（email/password) • 作成したユーザーごとに権限を細かく設定可能 • アクセス元も設定可能 • ID連携も可能（後述） 49
- 50. AWS CloudTrail • APIの呼び出しを記録して送信する • Amazon S3（ストレージサービス）に保管 • 外部の分析サービスとの連携も可能 50
- 51. ID連携 • 社内のログインシステムなどと連携 • ログインシステムが許可したユーザは、AWSのコンソールに そのままログイン可能 • ログインシステム側を作り込むことで、特定のプロジェクト に参加している正社員だけ連携、といったことも容易 • ログインさせたユーザーの権限も設定できる 51
- 52. IaaS以外でもできればID連携 • 退職者リスク • 退職した従業員 • 契約満了した協力会社 • 仮に悪意は無くても管理が万全とは言えない • できるかぎりID連携 • SAML、LDAP 52
- 53. ID連携できないクラウドサービス • ID連携できないものも「把握」はしておく • むやみやたら閉め出すのもリスク • 便利なモノは禁止してもこっそり使われてしまう • 把握はしておき、退職者を棚卸し • Shadow IT • 管理されず把握もされていない外部サービス • 情報漏洩の流出源につながる • ダメ、ゼッタイ！ 53
- 54. 最小権限の原則 • 情報セキュリティで最も重要な原則 • 必要最小限の権限だけを用意する • 例：アクセスキーの権限を最低限にする • APIの接続元IPアドレス • サンパウロでサーバ作成する権限は本当に必要？ 54 本日覚えて帰って欲しいキーワード その3
- 57. 安全なデータの保存 • 権限管理 • データベース、データベースサーバへの接続権限の最小化 • 暗号化 • データベースの暗号化 • 通信路等の保護 • ネットワークレベルの分離 • 物理サーバ単位の専有化 57 クラウドでできることも 増えてきたので、 自前のサーバとやること は変わりません。
- 58. 「損失」の話、覚えてる？ 58
- 59. 「損失」の話、覚えてる？ • 1時間サービスが止まったときの被害はおいくら？ • 2015年3Qの課金売上高：54億円（四半期決算） • 1時間あたり247万円 • 1分あたり4万円 • ピークタイム • 月末月初 • イベントのラストスパート 59
- 61. そもそも情報セキュリティ #とは • 機密性 Confidentiality • アクセスが許可された人だけが情報を見られること • 完全性 Integrity • 情報が改竄されず正確であること • 可用性 Availability • 必要な時に情報にアクセスできること • さっきの話はここしか見ていなかった 61
- 62. 機密性が破られたときの損失 • 個人情報漏洩 • アメーバ会員数4000万人×500円＝200億円 （だいたい1年の利益分） • 会員流出に伴う課金売上減少 • アメブロPV減少に伴う広告収入源 • それ以後の機会損失 62
- 63. 完全性が破られたときの損失 • ゲームのデータが大規模に改竄され信頼を失い サービス終了に追い込まれる • 本来売り上げていたはずの課金アイテムの売上減 • その他のゲームについての風評被害 • 人気あるゲームが出せなくなった事による社員の流出 63
- 65. 小さな例も考えてみよう • スマホのリズムゲームでチートをされたが、巧妙にも 「非常に上手い人」と同レベルのスコアに留めている。 • スコアがその人本来の2倍になっていて、本来課金していた はずの回復アイテムの売り上げが半分に減っていた。 • ランキングを大きく崩すことはなく他者への影響がない • 売上全体額への影響はごく軽微 ……そんなの本当に調べる価値あるの？ 65 小さなリスクは身近にたくさんあるのでは？
- 66. 小さな例も考えてみよう • スマホのリズムゲームでチートをされたが、巧妙にも 「非常に上手い人」と同レベルのスコアに留めている。 • スコアがその人本来の2倍になっていて、本来課金していた はずの回復アイテムの売り上げが半分に減っていた。 • ランキングを大きく崩すことはなく他者への影響がない • 売上全体額への影響はごく軽微 ……そんなの本当に調べる価値あるの？ 66 たとえば「ざっくり上限制限」でもよい
- 67. リスク評価 • リスクの可視化 • 金額に落とすと定量的に評価できる • 失うものが少ないほど受容できるリスクが増える ※ 行き過ぎた結果が「サイバーノーガード戦法」 67 判断が難しいときは、数字に落として 定量的に判断すると納得しやすいです。
- 68. 抑止防止検知回復 • 事前（予防） • 抑止 攻撃の機会を減らす • 防止 攻撃の被害を減らす • 事後 • 検知 攻撃されたことを発見する（ための枠組みをあらかじめ作る） • 回復 攻撃により低減したCIAを回復する（ための枠組みをあらかじめ作る） • 全部大事だよ • パッチあては「防止」でしかない 68 漏れなく考えるためには、 こういうフレームワークに沿うとよいです。
- 69. 抑止・防止 • 攻撃の「機会」そのものを減らす • 対外的なアピール • エンドポイントを気軽に見せない • 攻撃の「被害」を減らす • 関係者の権限を管理する • 責務の分離 • 最小権限 69
- 70. 検知 • 侵入検知 • → 検知トラック • 操作の監査 • AWS CloudTrail • 監査ログの分析 • 適切な意志決定者への報告、エスカレーション 70
- 71. 回復 • 影響の封じ込め • 特に情報流出 • サービスの素早い復帰 • そのた各種事後報告 • プレスリリースとか • 個人情報流出被害の告知義務 71
- 72. 抑止防止検知回復おさらい • ID管理と監査を軸としたセキュリティ施策 • 抑止：ID管理と監査実施のアピール • 防止：適切なID管理と必要最小限の権限設定 • 検知：監査ログの分析、異常検知 • 回復：監査結果から影響範囲の確定、封じ込め対策 72
- 73. セキュリティ施策がスピード感を損なわ ないことの確認 • リスク・脆弱性の対応 • 例）クラウドでのデプロイ高速化→パッチ当て早くなる • ID管理と監査 • 裏で取られているだけで利便性は損ねない • むしろ全てAPI経由であることで記録が容易・確実に 73 最後に繰り返しますが、 ビジネスのスピード感とのすりあわせは重要
- 74. まとめ • クラウド時代のWebシステムについて • サーバ設計、構築、運用技術の基礎 • サービスの無停止とスケーラビリティを実現する設計 • 具体的なセキュリティ施策 • ID管理と監査 • 機密情報の保存 74