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

クラウドセキュリティ 基礎 株式会社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

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

サービスの運用とは • 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

クラウドコンピューティング https://www.ipa.go.jp/files/000025366.pdf 21

• https://www.ipa.go.jp/files/000025366.pdf

クラウドコンピューティング • 要点 • 共用されたリソースプールから • いつでもどこからでもネットワーク経由で • 必要な分だけをすぐに利用できる 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

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

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

• https://www.ipa.go.jp/security/vuln/CVSS.html
• https://github.com/future-architect/vuls

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

• https://aws.amazon.com/jp/cli/

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