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

• 過去にはWindowsとかも

• 最近IoTデバイスの内蔵マイコンにも手を出し始めた

• 情報システム

• 社内ITシステムの設計、運用

• 情報セキュリティマネジメント

• サーバ/ネットワーク運用

• サーバHW（特にストレージ）周り

• IPネットワーク

• 「必要があればなんでもやる」

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

↓

前職の話が分かりやすいと思うので、CA社を例に挙げて説明します。

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

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

•半分が広告事業

• 広告の配信システム

• 広告の斡旋

•残りの半分がゲーム事業

• 「グラブル」

• 「デレステ」「モバマス」

•残りがメディア事業

• アメブロ、AbemaTV

8

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



• 2016年3Qのゲーム事業売上高：306億円（四半期決算）（2016/04/01～2016/06/30：91日間）

• 1時間あたり1,401万円（1分あたり23万円）

9

毎分23万円、稼ぎ時ならその何倍か安いような高いような……





•ピークタイム（稼ぎ時）

•期間限定イベントのラストスパート

•月初（キャリア決済の限度額がクリア）

•年始めのおみくじ代わり

10

「障害時の損失」は、「普段稼いでいる金額」でもあります。


•目的：

• ITを使って「お金を稼ぐ」

•手段：

•お客さんにサービスを提供し、その対価を受け取る（直接部門）

•従業員にサービスを提供し、生産性を向上させる（間接部門）

11

運用とは、サービスの価値を届け続けることです。

サービスの価値

•使いたいときに使える（落ちない）こと

•いわゆる「サービスの品質」

12

サービスの価値を決めるのは、一つは、それが期待通りに動いていることですが……

サービスの価値

•使いたいときに使える（落ちない）こと

•いわゆる「サービスの品質」

•そもそも：

•サービスの内容がお客さんの期待を満たすこと

13

サービスの価値を決めるもう一つは、それが期待通りの内容であることです。

サービスの価値を高める努力（サイバーエージェントの場合）

1. 膨大な新サービスを続々とリリース

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

2. 頻繁な人材流動で開発体制を最適化

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

3. 明確な撤退ルールで失敗と正しく向き合う

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

14

価値を高め「続ける」ことが最大の課題です。

インフラ的なつらさ

•流行れば大量のサーバがすぐに必要になる

•チューニングには時間が掛かり限界もある

•とにかくサーバ追加で時間を「稼ぐ」（通称：金の弾丸）

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

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

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

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

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

多種多様なサーバを、必要な時に必要なだけ使いたい！

それクラウドでできるよ

16

クラウドコンピューティング

17

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


18

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

イメージしづらいかもしれませんが、要点は黄色の部分です。


•要点

•共用されたリソースプールから

•いつでもどこからでもネットワーク経由で

•必要な分だけをすぐに利用できる

19

クラウド #とは

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

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

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

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

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

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

20

NISTの定義はあくまで「一つの定義」ですが、それなりに広まっているものです。

クラウドの分類

運用方法による分類

•パブリッククラウド

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

• AWSとかAzureとかいろいろ

•プライベートクラウド

•社内で単独で運用

• YahooとかCyberAgentとか

21

パブリックも、プライベートも、あるんだよ。

パブリッククラウド

•大規模な事業者

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

•膨大な開発能力にもとづく多種多様な機能

•責任共有モデル

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

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

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

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

22

「責任共有モデル」はAmazon用語ですが、考え方はだいたい皆同じです。

プライベートクラウド

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

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

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

•多種多様な機能は少ない

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

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

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

•これらを維持しつつ、クラウドや仮想化のメリットを享受

23

クラウドのサービス分類

サービス形態による分類

• SaaS

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

• DropboxとかGmailとか

• PaaS

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

• Herokuとか

• IaaS

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

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

IaaSとPaaSの定義は既に「古い」ものですが、この講義ではいわゆるIaaSを主に対象とします

クラウド(IaaS)でサーバを確保

•自由なサーバの追加・削除が可能になる

•すぐにサーバが増やせる！↔ これまでは最大想定分だけのサーバを事前に用意↔ 想定を超えるとすぐに対応ができない

•要らないサーバはいつでも捨てられる！↔ 資産の耐用年数（5年程度）を使い切れない↔ 挑戦的なサービスをリリースできない

25

IaaSとPaaSの定義は既に「古い」ものですが、

この講義ではいわゆるIaaSを主に対象とします

具体的にイメージしてみよう

•サーバはすぐに確保・削除できる

↓

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

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

26

「ペット」から「家畜」へ

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

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

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

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

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

•おかしくなったら殺す

27

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

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

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

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

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

•ポイント

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

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

28

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

•サーバの構築や運用の手間はかわらない

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

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

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

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

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

29

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

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

•サーバ内に記録されたデータはどうする？

•データベース

•セッション情報

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

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

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

30

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

クラウド時代の考え方

•サーバの設計方法も合わせていこう！

•構築や運用が楽になる方法を作る

•システム全体のデータの記録方法を見直す

31

クラウドのメリットは、考え方を整理することで最大化します！

「メリハリ」を付けよう

• Statelessサーバ

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

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

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

• Statefulサーバ

•データベース、ログ

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

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

32

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

Statelessサーバの指針

• Twelve-Factor App

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

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

33

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

http://12factor.net/ja/

Twelve-Factor App

I. コードベース

II. 依存関係

III. 設定

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

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

VI. プロセス

34

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

VIII. 並行性

IX. 廃棄容易性

X. 開発/本番一致

XI. ログ

XII. 管理プロセス

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

Twelve-Factor AppI. コードベース

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

• 1つのコードベース

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

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

•複数のデプロイ

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

• 全ての変更をきちんと記録・追跡

35

Twelve-Factor AppIII. 設定

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

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

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

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

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

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

•ソースコードを完全に同一にできる

36

Twelve-Factor AppXI. ログ

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

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

•アプリは吐き出すだけで、自分でファイルとかに保存しない

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

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

37

Twelve-Factor App

I. コードベース

II. 依存関係

III. 設定

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

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

VI. プロセス

38

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

VIII. 並行性

IX. 廃棄容易性

X. 開発/本番一致

XI. ログ

XII. 管理プロセス

じゃあ、Statefulサーバは？

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

1. スケールアップで対応（金の弾丸）

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

2. 分散DB

• Cassandra、HBase、MongoDBとかとか

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

• Amazon DynamoDBやGoogle BigQuery

39

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

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

40

•どれかが犠牲になる

•可用性バルスできない

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

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

可用性

一貫性ネットワーク

分断性

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

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

• Statelessサーバ

•アプリを動かす

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

• Statefulサーバ

•データを保存

•気合い入れて頑張る

41

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

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

•いかに迅速に動作確認するか

42

Blue-Green Deployment

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

43

ｃ

L

B

サーバー

サーバー

サーバー

サーバー

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

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

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

DB

共通環境

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

万能じゃない

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

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

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

•脆弱性チェックの自動化ツール：Vulshttps://github.com/future-architect/vulsCVSSスコアで危険なものだけ通知できる

44

https://www.ipa.go.jp/security/vuln/CVSS.html

https://github.com/future-architect/vuls

CVSS v2の基準

•基本評価基準 (Base Metrics)

•脆弱性そのものの特性

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

•現状評価基準 (Temporal Metrics)

•今どれぐらいやばいか

•環境評価基準 (Environmental Metrics)

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

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)

46

クラウドの管理

•コントロールパネル

•ブラウザで人がログイン

•マウスでクリッククリッククリック……

•つらい

•人間は必ずミスをする

•そもそも人の意志決定の余地は少ない

47

APIによるアクセス

•サーバ環境をAPIで操作可能

• APIの認証情報（アクセスキー）を利用

•コントロールパネルとほぼ同じ操作が可能

• APIの利用

• APIを利用するライブラリやCLIコマンド

• REST API

•自動処理が可能に！

48

クラウドの最大の特長です！

Discussion #2API操作ならではのリスクって？

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

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

• APIでさらに作りやすい

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

49

オフレコ

50

オフレコ

51

APIが万能である故の問題

• APIの認証情報があれば何でもできてしまう

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

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

52

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

クラウドの管理

•適切なアクセス制御

•本当にその人に必要な作業しか実行させない

•最小権限の原則

•操作内容の監査（記録）

•誰がその作業をしたのかを記録

•あやしい行動をチェックできる

53

最小権限の原則

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

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

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

•社外のIPアドレスから操作する権限は本当に必要？

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

• 1時間1400円もするサーバを作成する権限は(同上)

54

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

AWS Identity and Access Management （IAM）

•アクセス権限を管理する仕組み

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

•ユーザやグループを作成して、権限を細かく割り当て可能

•より抽象化した「ロール」への割り当てもできる

•アクセス元IPアドレスなども設定可能

55

AWS CloudTrail

•操作内容を記録する

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

•別のAWSアカウントにも送り込める

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

56

ユーザの管理

•何も考えないとすぐに崩壊

•システムの数だけID

•システムの数だけパスワード

• (ノ゜Д゜)ノ ==== ┻━━┻

•管理コスト

•どこかでパスワードが一度漏洩すると全て変更してまわる

•入社時のアカウント作成（だいたい漏れる）

•退社時のアカウント削除（だいたい漏れる）57

ID連携

•社内のID基盤（ログインシステム）と連携

• ID基盤にログインできたユーザは、AWSのコンソールにそのままログイン可能（シングルサインオン）

• ID基盤を作り込むことで、特定のプロジェクトに参加している正社員だけ連携、といったことも容易

• AWS IAMのユーザでは無く「ロール」に紐付けられる

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

58

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

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

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

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

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

• Shadow IT

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

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

•ダメ、ゼッタイ！

59

オフレコ

60

オフレコ

61

オフレコ

62

オフレコ

63

オフレコ

64

ここまでのまとめ

•クラウドコンピューティング

•ペットから家畜へ、StatelessサーバとStatefulサーバ

• APIの利用

• IDと権限の管理

65

IaaSの例

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

•さくらのクラウド

• Amazon Web Services （AWS）

66

基本的な機能は一緒

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

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

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

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

•ファイアウォール

•ロードバランサー

67

違う点

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

68

69

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

違う点

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

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

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

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

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

70

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

個人情報とかの保存

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

71

個人情報とかの保存

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

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

• ISO 27018 クラウド上での個人情報管理に関する規定大手クラウド事業者がこぞっと取得

72

安全なデータの保存

•権限管理

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

•暗号化

• データベースの暗号化

•通信路等の保護

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

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

•これらみなパブリッククラウドでもできます！

73

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



• 1時間あたりXXXXX万円（1分あたりYYYYY万円）

74

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




•ピークタイム（稼ぎ時）

•期間限定イベントのラストスパート

•月初（キャリア決済の限度額がクリア）

•年始めのおみくじ代わり

75

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

76

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

•機密性 Confidentiality

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

•完全性 Integrity

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

•可用性 Availability

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

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

77

「情報セキュリティマネジメント」分野とインフラ領域は切っても切り離せません。

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

•個人情報漏洩

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

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

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

•それ以後の機会損失

78

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

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

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

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

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

79

リスク評価

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

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

80

突き詰めれば無限に対策ができてしまうが故にリスク評価で割り切ることが重要です。

小さな例も考えてみよう

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

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

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

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

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

81

小さな例も考えてみよう

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

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

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

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

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

82

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

リスク評価

•リスクの可視化

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

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

83

「サイバーノーガード戦法」、そろそろ死語でしょうか……。

抑止防止検知回復

• 事前（予防）

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

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

• 事後

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

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

• 全部大事だよ

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

84

抑止・防止

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

•対外的なアピール

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

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

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

• 責務の分離

• 最小権限

85

いわゆる「割れ窓理論」とかも、分かりやすい抑止策の一つですね。

検知

•侵入検知

• → 検知トラック

•操作の監査

• AWS CloudTrail

•監査ログの分析

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

86

検知できなければ、何の対策もできません。

回復

•影響の封じ込め

•特に情報流出

•サービスの素早い復帰

•そのた各種事後報告

•プレスリリースとか

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

87

ビジネスでは、事業の「回復」も重要です。明日もご飯が食べられますように。

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

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

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

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

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

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

88

セキュリティはビジネスとの対立ではない

•リスク・脆弱性の対応

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


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

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

•適切なセキュリティへの「投資」と捉えよう

89

ビジネス上のリスクを減らす(守る)だけでなく、利益を増やす(攻める)ことにもなります。

演習

•クラウド体験

•クラウドのAPI操作

• IAM＋CloudTrailsでの監査

• LBを挟んだ無停止のパッチあて

•クラウドっぽい活用

• RDSとS3でStatelessなサーバを作ってみる

90

単にサーバを作った消したでは意味が無いので、APIで下のレベルで見てもらう演習です。

渡す環境

• AWSのIAMユーザ

•ログイン用URL

• ID

•パスワード

注意事項

• AWSアカウントには制限が掛かっていません！

•無料枠と表示されているt2.microだけ使ってください。

•こちらのアカウントは後ほど削除します。

クラウド破産こわい(((( ;ﾟДﾟ))))AWSさん無料枠ありがとうございます！！！

ログインチェック

• 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

96

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-1Default 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

※本来は接続元を制限するのが良いです。


•サーバを立てるサブネットのIDを検索

• SubnetIdを探す

• APIでサーバ作成・起動

• エラーが出なければ、表示内容のInstanceIdを検索「i-ffffffff」形式

100

aws ec2 run-instances --image-id ami-374db956 ⇒--instance-type t2.micro --key-name ＜キーペア名＞ ⇒--subnet-id ＜サブネットID＞

aws ec2 describe-subnets


•起動したサーバのステータスを確認

• PublicIpを探す

• Stateの中のNameが「running」になるのをまつ

•ここまできたらec2-user ユーザでSSH接続

•接続先は上の PublicIp

101

aws ec2 describe-instances --instance-id ＜インスタンスID＞

監査ログを見てみよう

•コンソールのサービス一覧から「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システムについて

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

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

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


• 機密情報の保存

•演習

105

Technology

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