20160811 cloudsecurity

20160811 cloudsecurity

1. 1. クラウドセキュリティ 基礎 株式会社WHERE IoT基盤センター サービスプロデューサー 兼 情報システム室 インフラエンジニア 仲山 昌宏 ( @nekoruri )
2. 2. 講師プロフィール • 仲山昌宏 • いわゆるセキュリティエンジニア……ではありません • 秋葉原生まれ大手町育ちの 歌って踊れる江戸っ子インフラエンジニア • 株式会社WHERE IoT基盤センター サービスプロデューサー 兼 情報システム室 インフラエンジニア 2
3. 3. 経歴 • 2003-09～2005-03 大学院ネットワーク管理 • 2004-03～2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用 • 2004-09～2005-10 国際大学GLOCOM (研究アシスタント) • 2005-08～2008-09 AIP • 2008-10～2009-12 KBB, I&D • 2010-01～2013-06 Xtone • 2013-07～2016-01 CyberAgent (パシャオク⇒Ameba⇒DC運用) • 2016-02～現職 WHERE (測位技術スタートアップ) ⬅今ここ 学 生 社 会 人 1999-04 ↓ 2006-03 2006-03 ↓
4. 4. 主なスキルセット • システム設計 • クラウドとIoTデバイス組み合わせて 良い感じのシステム • ウェブアプリの内部アーキテクチャ • アプリケーション開発 • メインはサーバサイド Perl、Ruby、Python、JS、PHP • 過去にはWindowsとかも • 最近IoTデバイスの内蔵マイコンにも 手を出し始めた • 情報システム • 社内ITシステムの設計、運用 • 情報セキュリティマネジメント • サーバ/ネットワーク運用 • サーバHW（特にストレージ）周り • IPネットワーク • 「必要があればなんでもやる」 4
5. 5. この講義の目的 • クラウド時代のWebシステムについて • サーバ設計、構築、運用技術の基礎 • サービスの無停止とスケーラビリティを実現する設計 • 継続的インテグレーション、高速なリリースサイクル • クラウドのセキュリティ • ID管理と監査 • セキュリティマネジメント • 演習 5
6. 6. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ 6
7. 7. 経歴 • 2003-09～2005-03 大学院ネットワーク管理 • 2004-03～2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用 • 2004-09～2005-10 国際大学GLOCOM (研究アシスタント) • 2005-08～2008-09 AIP • 2008-10～2009-12 KBB, I&D • 2010-01～2013-06 Xtone • 2013-07～2016-01 CyberAgent (パシャオク⇒Ameba⇒DC運用) • 2016-02～現職 WHERE ⬅今ここ 学 生 社 会 人 1999-04 ↓ 2006-03 2006-03 ↓
8. 8. 株式会社サイバーエージェント • 「アメーバで検索検索♪」の会社 • 半分が広告事業 • 広告の配信システム • 広告の斡旋 • 残りの半分がゲーム事業 • 「グラブル」 • 「デレステ」「モバマス」 • 残りがメディア事業 • アメブロ、AbemaTV 8 https://www.cyberagent.co.jp/ir/about/factsheet/
9. 9. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2016年3Qのゲーム事業売上高：306億円（四半期決算） （2016/04/01～2016/06/30：91日間） 9
10. 10. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2016年3Qのゲーム事業売上高：306億円（四半期決算） （2016/04/01～2016/06/30：91日間） • 1時間あたり1,401万円 10
11. 11. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2016年3Qのゲーム事業売上高：306億円（四半期決算） （2016/04/01～2016/06/30：91日間） • 1時間あたり1,401万円（1分あたり23万円） 11
12. 12. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2016年3Qのゲーム事業売上高：306億円（四半期決算） （2016/04/01～2016/06/30：91日間） • 1時間あたり1,401万円（1分あたり23万円） • ピークタイム（稼ぎ時） • 期間限定イベントのラストスパート • 月初（キャリア決済の限度額がクリア） • 年始めのおみくじ代わり 12
13. 13. サービスの運用とは • 目的： • ITを使って「お金を稼ぐ」 • 手段： • お客さんにサービスを提供し、その対価を受け取る （直接部門） • 従業員にサービスを提供し、生産性を向上させる （間接部門） 13
14. 14. サービスの運用とは • 目的： • ITを使って「お金を稼ぐ」 • 手段： • お客さんにサービスを提供し、その対価を受け取る （直接部門） • 従業員にサービスを提供し、生産性を向上させる （間接部門） 14
15. 15. サービスの価値 • 使いたいときに使える（落ちない）こと • いわゆる「サービスの品質」 15
16. 16. サービスの価値 • 使いたいときに使える（落ちない）こと • いわゆる「サービスの品質」 • そもそも： • サービスの内容がお客さんの期待を満たすこと 16
17. 17. サービスの価値を高める努力 （サイバーエージェントの場合） 1. 膨大な新サービスを続々とリリース • 2015年だけで10サービス以上の提供を開始 2. 頻繁な人材流動で開発体制を最適化 • 2011年 スマホシフト、2014年 アメーバ構造改革 3. 明確な撤退ルールで失敗と正しく向き合う • リリースから2年を目処に成果が出なければ撤退 17
18. 18. インフラ的なつらさ • 流行れば大量のサーバがすぐに必要になる • チューニングには時間が掛かり限界もある • とにかくサーバ追加で時間を「稼ぐ」（通称：金の弾丸） • 廃れればどんどん縮小させる • 縮小しきれない過剰投資は「損失」でしかない • 新しいプロジェクトには新しい技術を積極導入 • プロジェクトごとに使う技術もバラバラ • サーバの共有はむずかしい 18
19. 19. それクラウドでできるよ 19
20. 20. クラウドコンピューティング 20 https://www.ipa.go.jp/files/000025366.pdf
21. 21. クラウドコンピューティング 21 https://www.ipa.go.jp/files/000025366.pdf
22. 22. クラウドコンピューティング • 要点 • 共用されたリソースプールから • いつでもどこからでもネットワーク経由で • 必要な分だけをすぐに利用できる 22
23. 23. クラウド #とは NIST（米国国立標準技術研究所）による基本特徴の整理 1. オンデマンド・ セルフサービス APIでなんでもできる 2. 幅広いネットワークアクセス ネットワーク経由でできる 3. リソースの共用 共用する潤沢なリソースプールがある 4. スピーディな拡張性 すぐに利用可能 5. サービスが 計測可能であること 自らの利用量が適切に計測（されて課金される） 23
24. 24. クラウドの分類 運用方法による分類 • パブリッククラウド • 大規模な事業者が運用して数多くの利用者が共有 • AWSとかAzureとかいろいろ • プライベートクラウド • 社内で単独で運用 • YahooとかCyberAgentとか 24
25. 25. パブリッククラウド • 大規模な事業者 • 豊富なリソースにもとづく最適化 • 膨大な開発能力にもとづく多種多様な機能 • 責任共有モデル • ざっくりOSから下は事業者がセキュリティを担保 • 各種セキュリティガイドラインへの準拠 • むしろベストプラクティスが実装された環境 • OSとその上は利用者がセキュリティを自力で担保 25
26. 26. プライベートクラウド • 既存の自前でデータセンタ借りてサーバ置くモデル • OpenStackなどのクラウドコントローラでクラウド化 • 基本機能はAmazon等と似たようなことができる • 多種多様な機能は少ない • プライベートでの差別化 • 既にノウハウや購買力を持つ場合 • システム間が密結合（消極的理由） • これらを維持しつつ、クラウドや仮想化のメリットを享受 26
27. 27. クラウドのサービス分類 サービス形態による分類 • SaaS • 具体的なアプリケーションとして提供される。 • DropboxとかGmailとか • PaaS • アプリケーションが動く環境が用意される。 • Herokuとか • IaaS • サーバ一式が用意される。いわゆるレンタルサーバに近い。 • ネットワーク機能（FW、LB等）も提供されたりする。 27
28. 28. クラウドのサービス分類 サービス形態による分類 • SaaS • 具体的なアプリケーションとして提供される。 • DropboxとかGmailとか • PaaS • アプリケーションが動く環境が用意される。 • Herokuとか • IaaS • サーバ一式が用意される。いわゆるレンタルサーバに近い。 • ネットワーク機能（FW、LB等）も提供されたりする。 28
29. 29. クラウド(IaaS)でサーバを確保 • 自由なサーバの追加・削除が可能になる • すぐにサーバが増やせる！ ↔ これまでは最大想定分だけのサーバを事前に用意 ↔ 想定を超えるとすぐに対応ができない • 要らないサーバはいつでも捨てられる！ ↔ 資産の耐用年数（5年程度）を使い切れない ↔ 挑戦的なサービスをリリースできない 29
30. 30. 具体的にイメージしてみよう • サーバはすぐに確保・削除できる 30
31. 31. 具体的にイメージしてみよう • サーバはすぐに確保・削除できる ↓ • 作ったサーバに環境構築してすぐ本番投入したい • 本番投入中のサーバでもすぐに消したい 31
32. 32. 「ペット」から「家畜」へ • これまで：サーバ＝ペット • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • これから：サーバ＝家畜 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す 32
33. 33. Discussion #1 クラウド環境のアーキテクチャ • Webシステムのアーキテクチャを考えてみよう • クラウド環境では何が問題になるか • どうすれば解決できるか • ポイント • 作ったサーバに環境構築してすぐ本番投入したい • 本番投入中のサーバでもすぐに消したい 33
34. 34. 34
35. 35. Discussion #1 クラウド環境のアーキテクチャ • Webシステムのアーキテクチャを考えてみよう • クラウド環境では何が問題になるか • どうすれば解決できるか • ポイント • 作ったサーバに環境構築してすぐ本番投入したい • 本番投入中のサーバでもすぐに消したい 35
36. 36. ポイント1 作ったサーバに環境構築してすぐ本番投入したい • サーバの構築や運用の手間はかわらない • ミドルウェア入れて設定ファイルを変更 • アプリの動作に必要なライブラリも入れる • 最新のアプリケーションをデプロイ（設置） • アプリケーション設定（DB認証情報等）も設置 • アプリケーションのプロセスを起動 36
37. 37. ポイント2 本番投入中のサーバでもすぐに消したい • サーバ内に記録されたデータはどうする？ • データベース • セッション情報 • アクセスログ、エラーログ、デバッグログ • システムログ（syslog, イベントログ） • 一時的に手で入れたテスト用設定 37
38. 38. クラウド時代の考え方 • サーバの設計方法も合わせていこう！ • 構築や運用が楽になる方法を作る • システム全体のデータの記録方法を見直す 38
39. 39. 「メリハリ」を付けよう • Statelessサーバ • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 39
40. 40. Statelessサーバの指針 • Twelve-Factor App • http://12factor.net/ja/ • （いくつか宗教的な項目もあるものの） 今までに提起された最適解の「まとめ」 40
41. 41. Twelve-Factor App I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス 41 VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス
42. 42. Twelve-Factor App I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス 42 VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス
43. 43. Twelve-Factor App I. コードベース バージョン管理されている1つのコードベースと 複数のデプロイ • 1つのコードベース • アプリケーション全体が一つのレポジトリ • それ以外は、依存ライブラリか参照先の外部システム • 複数のデプロイ • 本番環境、ステージング環境、開発環境 • 全ての変更をきちんと記録・追跡 43
44. 44. Twelve-Factor App III. 設定 設定を環境変数に格納する • デプロイごとに異なる設定 • DB接続先とかドメイン名とか • アプリ本体に設定を保存しない • 起動時に動的に設定できるようにする • あたらしい種類のデプロイをすぐ作れるようにする • ソースコードを完全に同一にできる 44
45. 45. Twelve-Factor App XI. ログ ログをイベントストリームとして扱う • 時系列で継続して吐き出され続ける「ストリーム」 • アプリは吐き出すだけで、自分でファイルとかに保存しない • 開発環境ならコンソールで眺めてみんな大好き目grep • 本番環境ならログ用ストレージに転送 45
46. 46. Twelve-Factor App I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス 46 VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス
47. 47. じゃあ、Statefulサーバは？ 「銀の弾丸」は無いが、現実的な選択肢は増えている。 1. スケールアップで対応（金の弾丸） • 「Fusion ioは甘え」でもいいじゃないか 2. 分散DB • Cassandra、HBase、MongoDBとかとか 3. すごいストレージサービスを使う • Amazon DynamoDBやGoogle BigQuery 47
48. 48. 脱線： 分散DBにおけるCAP定理 48 • どれかが犠牲になる • 可用性 バルスできない • 一貫性 バルス書いた筈なのに 読めたり読めなかったり ※結果整合性 • ネットワーク分断耐性 バルス書いたのに サーバが死んで消えた 可用性 一貫性 ネットワーク 分断性
49. 49. クラウド時代のサーバ設計 • Statelessサーバ • アプリを動かす • 台数でコントロールできる状態を保つ • Statefulサーバ • データを保存 • 気合い入れて頑張る 49
50. 50. クラウド時代の脆弱性対応 • アプリケーションの脆弱性が圧倒的に多い • いかに迅速に動作確認するか 50
51. 51. Blue-Green Deployment • もう1セット（Green）作って 古い方（Blue）を捨てよう！ 51 ｃ L B サーバー サーバー サーバー サーバー ③問題が無ければ 古い環境（Blue）を廃棄 ①新しいバージョン（Green）の 環境を構築 ②Greenに アクセス先を 切り替え DB 共通環境
52. 52. 万能じゃない • SSHとかStatefulサーバの脆弱性もある • きちんと脆弱性を評価して優先度を決めよう！ • 共通脆弱性評価システム：CVSS v2 https://www.ipa.go.jp/security/vuln/CVSS.html • 脆弱性チェックの自動化ツール：Vuls https://github.com/future-architect/vuls CVSSスコアで危険なものだけ通知できる 52
53. 53. CVSS v2の基準 • 基本評価基準 (Base Metrics) • 脆弱性そのものの特性 • 機密性、完全性、可用性への影響、 攻撃のしやすさ（ネットワーク経由の攻撃可否など） • 現状評価基準 (Temporal Metrics) • 今どれぐらいやばいか • 環境評価基準 (Environmental Metrics) • 二次被害の度合いとかその他の影響範囲 53
54. 54. 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) 54
55. 55. クラウドの管理 • コントロールパネル • ブラウザで人がログイン • マウスでクリッククリッククリック…… • つらい • 人間は必ずミスをする • そもそも人の意志決定の余地は少ない 55
56. 56. APIによるアクセス • サーバ環境をAPIで操作可能 • APIの認証情報（アクセスキー）を利用 • コントロールパネルとほぼ同じ操作が可能 • APIの利用 • APIを利用するライブラリやCLIコマンド • REST API • 自動処理が可能に！ 56
57. 57. Discussion #2 API操作ならではのリスクって？ • AWSみたいな大規模なクラウド環境 • いくらでもサーバが作れる（リミットは一応ある） • APIでさらに作りやすい • どんなリスクが新しく増えたのか考えてみよう！ 57
58. 58. 58
59. 59. Discussion #2 API操作ならではのリスクって？ • AWSみたいな大規模なクラウド環境 • いくらでもサーバが作れる（リミットは一応ある） • APIでさらに作りやすい • どんなリスクが新しく増えたのか考えてみよう！ 59
60. 60. オフレコ 60
61. 61. オフレコ 61
62. 62. APIが万能である故の問題 • APIの認証情報があれば何でもできてしまう • 自動化プログラムとかにカジュアルに組み込みやすい • なにかされたことにすぐに気付きにくい 62
63. 63. クラウドの管理 • 適切なアクセス制御 • 本当にその人に必要な作業しか実行させない • 最小権限の原則 • 操作内容の監査（記録） • 誰がその作業をしたのかを記録 • あやしい行動をチェックできる 63
64. 64. 最小権限の原則 • 情報セキュリティで最も重要な原則 • 必要最小限の権限だけを用意する • 例：アクセスキーの権限を最低限にする • 社外のIPアドレスから操作する権限は本当に必要？ • サンパウロでサーバ作成する権限は本当に必要？ • 1時間1400円もするサーバを作成する権限は(同上) 64
65. 65. AWS Identity and Access Management （IAM） • アクセス権限を管理する仕組み • AWSは元々は1アカウント＝1認証情報（email/password) • ユーザやグループを作成して、権限を細かく割り当て可能 • より抽象化した「ロール」への割り当てもできる • アクセス元IPアドレスなども設定可能 65
66. 66. AWS CloudTrail • 操作内容を記録する • Amazon S3（ストレージサービス）に保管 • 別のAWSアカウントにも送り込める • 外部の分析サービスとの連携も可能 66
67. 67. ユーザの管理 • 何も考えないとすぐに崩壊 • システムの数だけID • システムの数だけパスワード • (ノ ゜Д゜)ノ ==== ┻━━┻ • 管理コスト • どこかでパスワードが一度漏洩すると全て変更してまわる • 入社時のアカウント作成（だいたい漏れる） • 退社時のアカウント削除（だいたい漏れる） 67
68. 68. ID連携 • 社内のID基盤（ログインシステム）と連携 • ID基盤にログインできたユーザは、AWSのコンソールにその ままログイン可能（シングルサインオン） • ID基盤を作り込むことで、特定のプロジェクトに参加してい る正社員だけ連携、といったことも容易 • AWS IAMのユーザでは無く「ロール」に紐付けられる • ログインさせたユーザーの権限も設定できる 68
69. 69. ID連携できないクラウドサービス • ID連携できないものも「把握」はしておく • むやみやたら閉め出すのもリスク • 便利なモノは禁止してもこっそり使われてしまう • 把握はしておき、退職者を棚卸し • Shadow IT • 管理されず把握もされていない外部サービス • 情報漏洩の流出源につながる • ダメ、ゼッタイ！ 69
70. 70. オフレコ 70
71. 71. オフレコ 71
72. 72. オフレコ 72
73. 73. オフレコ 73
74. 74. オフレコ 74
75. 75. ここまでのまとめ • クラウドコンピューティング • ペットから家畜へ、StatelessサーバとStatefulサーバ • APIの利用 • IDと権限の管理 75
76. 76. IaaSの例 • 今回はこの二つを取り上げます • さくらのクラウド • Amazon Web Services （AWS） 76
77. 77. 基本的な機能は一緒 • サーバとネットワークを借りられる • CPU数、メモリ容量を指定可能 ※あらかじめ用意されたパターンから選択 • ディスク容量を指定可能 • 独自サブネットを持つ事が可能 • ファイアウォール • ロードバランサー 77
78. 78. 違う点 • AWS独自の「高レイヤー」なサービス 78
79. 79. 79
80. 80. 違う点 • AWS独自の「高レイヤー」なサービス • 割り切ったサービスレベル • 一つのサーバが突然死ぬくらいは「障害」ではない • 冗長化の枠組みを用意してるから冗長化は利用者の責任 • さくらのクラウドは1台ごとの稼働率で判断 80
81. 81. 個人情報とかの保存 • パブリッククラウドって大丈夫？ 81
82. 82. 個人情報とかの保存 • パブリッククラウドって大丈夫？ • 大丈夫です！（※きちんとやれば） • ISO 27018 クラウド上での個人情報管理に関する規定 大手クラウド事業者がこぞっと取得 82
83. 83. 安全なデータの保存 • 権限管理 • データベース、データベースサーバへの接続権限の最小化 • 暗号化 • データベースの暗号化 • 通信路等の保護 • ネットワークレベルの分離 • 物理サーバ単位の専有化 • これらみなパブリッククラウドでもできます！ 83
84. 84. 「損失」の話、覚えてる？ • 1時間サービスが止まったときの被害はおいくら？ • 2016年3Qのゲーム事業売上高：306億円（四半期決算） （2016/04/01～2016/06/30：91日間） • 1時間あたりXXXXX万円（1分あたりYYYYY万円） 84
85. 85. 「損失」の話、覚えてる？ • 1時間サービスが止まったときの被害はおいくら？ • 2016年3Qのゲーム事業売上高：306億円（四半期決算） （2016/04/01～2016/06/30：91日間） • 1時間あたり1,401万円（1分あたり23万円） • ピークタイム（稼ぎ時） • 期間限定イベントのラストスパート • 月初（キャリア決済の限度額がクリア） • 年始めのおみくじ代わり 85
86. 86. もうちょっと掘り下げてみよう 86
87. 87. そもそも情報セキュリティ #とは • 機密性 Confidentiality • アクセスが許可された人だけが情報を見られること • 完全性 Integrity • 情報が改竄されず正確であること • 可用性 Availability • 必要な時に情報にアクセスできること • さっきの話はここしか見ていなかった 87
88. 88. 機密性が破られたときの損失 • 個人情報漏洩 • アメーバ会員数4000万人×500円＝200億円 （だいたい1年の利益分） • 会員流出に伴う課金売上減少 • アメブロPV減少に伴う広告収入源 • それ以後の機会損失 88
89. 89. 完全性が破られたときの損失 • ゲームのデータが大規模に改竄され信頼を失い サービス終了に追い込まれる • 本来売り上げていたはずの課金アイテムの売上減 • その他のゲームについての風評被害 • 人気あるゲームが出せなくなった事による社員の流出 89
90. 90. リスク評価 • ある程度以上のビジネス継続リスクは許容できない • 対策コストが見合わないリスクは受容してもよい 90
91. 91. 小さな例も考えてみよう • スマホのリズムゲームでチートをされたが、巧妙にも 「非常に上手い人」と同レベルのスコアに留めている。 • スコアがその人本来の2倍になっていて、本来課金していた はずの回復アイテムの売り上げが半分に減っていた。 • ランキングを大きく崩すことはなく他者への影響がない • 売上全体額への影響はごく軽微 ……そんなの本当に調べる価値あるの？ 91
92. 92. 小さな例も考えてみよう • スマホのリズムゲームでチートをされたが、巧妙にも 「非常に上手い人」と同レベルのスコアに留めている。 • スコアがその人本来の2倍になっていて、本来課金していた はずの回復アイテムの売り上げが半分に減っていた。 • ランキングを大きく崩すことはなく他者への影響がない • 売上全体額への影響はごく軽微 ……そんなの本当に調べる価値あるの？ 92 たとえば「ざっくり上限制限」でもよい
93. 93. リスク評価 • リスクの可視化 • 金額に落とすと定量的に評価できる • 失うものが少ないほど受容できるリスクが増える ※ 行き過ぎた結果が「サイバーノーガード戦法」 93
94. 94. 抑止防止検知回復 • 事前（予防） • 抑止 攻撃の機会を減らす • 防止 攻撃の被害を減らす • 事後 • 検知 攻撃されたことを発見する（ための枠組みをあらかじめ作る） • 回復 攻撃により低減したCIAを回復する（ための枠組みをあらかじめ作る） • 全部大事だよ • パッチあては「防止」でしかない 94
95. 95. 抑止・防止 • 攻撃の「機会」そのものを減らす • 対外的なアピール • エンドポイントを気軽に見せない • 攻撃の「被害」を減らす • 関係者の権限を管理する • 責務の分離 • 最小権限 95
96. 96. 検知 • 侵入検知 • → 検知トラック • 操作の監査 • AWS CloudTrail • 監査ログの分析 • 適切な意志決定者への報告、エスカレーション 96
97. 97. 回復 • 影響の封じ込め • 特に情報流出 • サービスの素早い復帰 • そのた各種事後報告 • プレスリリースとか • 個人情報流出被害の告知義務 97
98. 98. 抑止防止検知回復おさらい • ID管理と監査を軸としたセキュリティ施策 • 抑止：ID管理と監査実施のアピール • 防止：適切なID管理と必要最小限の権限設定 • 検知：監査ログの分析、異常検知 • 回復：監査結果から影響範囲の確定、封じ込め対策 98
99. 99. セキュリティはビジネスとの対立ではない • リスク・脆弱性の対応 • 例）クラウドでのデプロイ高速化→パッチ当て早くなる • ID管理と監査 • 裏で取られているだけで利便性は損ねない • むしろ全てAPI経由であることで記録が容易・確実に • 適切なセキュリティへの「投資」と捉えよう 99
100. 100. 演習 • クラウド体験 • クラウドのAPI操作 • IAM＋CloudTrailsでの監査 • LBを挟んだ無停止のパッチあて • クラウドっぽい活用 • RDSとS3でStatelessなサーバを作ってみる 100
101. 101. 渡す環境 • AWSのIAMユーザ • ログイン用URL • ID • パスワード
102. 102. 注意事項 • AWSアカウントには制限が掛かっていません！ • 無料枠と表示されているt2.microだけ使ってください。 • こちらのアカウントは後ほど削除します。
103. 103. ログインチェック • AWSのコンソールにログインできることを確認 • ログインしたら右上の「リージョン」を確認 • 「オレゴン」とかになっていたら、 クリックして「アジアパシフィック(東京)」に変更
104. 104. アクセスキーの生成 • サービス一覧から「IAM」「Identity & Access Management」 • 新規ユーザの作成 • 適当な名前（yourname_cli とか） • 「ユーザーごとにアクセスキーを生成」に☑入っていることを確認 • 作成 • 「ユーザーのセキュリティ認証情報を表示」をクリック • アクセスキー IDとシークレットアクセスキーをメモ • 閉じる • 閉じる
105. 105. EC2管理権限の割り当て • リストから今作ったユーザを開く • 「アクセス許可」タブを開く • 「管理ポリシー」の「ポリシーのアタッチ」をクリック • 「AmazonEC2FullAccess」を探して、□を■にして 右下「ポリシーのアタッチ」をクリック
106. 106. AWS CLIのインストール • AWS配布ページからインストール • https://aws.amazon.com/jp/cli/ • Windowsならダウンロードしてインストール • Mac/Linuxなら、Pythonを入れてコマンドでインストール $ pip install awscli 106
107. 107. AWS CLIに認証情報を登録 • コマンドプロンプトを開く • aws configure を実行 • 以下を入力 AWS Access Key ID [None]: ＜アクセスキーID＞ AWS Secret Access Key [None]:＜シークレットアクセスキー＞ Default region name [None]: ap-northeast-1 Default output format [None]: （そのまま改行）
108. 108. 動作確認 • うまく設定できていれば、 aws ec2 describe-instances でエラーが出ないはずです。
109. 109. APIでサーバ作成 • SSHキーペアを登録 • 面倒なのでコンソールからで良いです。名前をメモること。 • セキュリティグループの変更 • こちらもコンソールから以下をdefaultに追加で開けましょう。 • TCP 80 FROM 0.0.0.0/0 • TCP 22 FROM 0.0.0.0/0 ※ 本来は接続元を制限するのが良いです。
110. 110. APIでサーバ作成 • サーバを立てるサブネットのIDを検索 • SubnetIdを探す • APIでサーバ作成・起動 • エラーが出なければ、表示内容のInstanceIdを検索 「i-ffffffff」形式 110 aws ec2 run-instances --image-id ami-374db956 ⇒ --instance-type t2.micro --key-name ＜キーペア名＞ ⇒ --subnet-id ＜サブネットID＞ aws ec2 describe-subnets
111. 111. APIでサーバ作成 • 起動したサーバのステータスを確認 • PublicIpを探す • Stateの中のNameが「running」になるのをまつ • ここまできたらec2-user ユーザでSSH接続 • 接続先は上の PublicIp 111 aws ec2 describe-instances --instance-id ＜インスタンスID＞
112. 112. 監査ログを見てみよう • コンソールのサービス一覧から 「CloudTrail」を開く • 先ほど作ったIAMユーザによるAPI記録が出てます。
113. 113. LBを挟んだ無停止のパッチあて • 本当に脆弱なソフトウェアを晒すのは良くないので、 今回はApache 2.2から2.4へのアップグレードで試します。 • ELBを経由して2台以上のウェブサーバを用意してみよう • httpd24パッケージではなく、httpdパッケージを使うこと • 設定ファイルにServerSignature OnとServerTokens Fullを入れて、 404ページなどでバージョンが見えるようにします。 • ELBから一台ずつ外してApacheバージョンアップ • httpd から始まるパッケージを削除 • httpd24をインストール • サービス再起動
114. 114. RDSとS3でstatelessなサーバ構築 • Wordpressを入れて以下のようなサーバをつくってみよ う • データベースはAmazon RDSにおいてみる • メディアファイルをAmazon S3においてみる • アクセスログをAmazon S3に送ってみる
115. 115. まとめ • クラウド時代のWebシステムについて • サーバ設計、構築、運用技術の基礎 • サービスの無停止とスケーラビリティを実現する設計 • 具体的なセキュリティ施策 • ID管理と監査 • 機密情報の保存 • 演習 115