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