クラウドセキュリティ基礎＠セキュリティ・ミニキャンプ in 東北 2016...

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

株式会社WHERE

IoT基盤センターサービスプロデューサー兼情報システム室インフラエンジニア

仲山昌宏 ( @nekoruri )

＠セキュリティ・ミニキャンプ in 東北 2016

講師プロフィール

•仲山昌宏

•いわゆるインフラエンジニア

•秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア

•株式会社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

↓

経歴

• 2003-09～2005-03 大学院ネットワーク管理



• 2005-08～2008-09 AIP

• 2008-10～2009-12 KBB, I&D

• 2010-01～2013-06 Xtone


• 2016-02～現職 WHERE (測位技術スタートアップ) ⬅今ここ

SNS

CGM

ソーシャルゲーム

主なスキルセット

• システム設計

• クラウドとIoTデバイス組み合わせて良い感じのシステム

• ウェブアプリの内部アーキテクチャ

• アプリケーション開発

• メインはサーバサイドPerl、Ruby、Python、JS、PHP

• 過去にはWindowsとかも

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

• 情報システム

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

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

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

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

• IPネットワーク

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

5

アンケート

1. クラウドってなんとなく知ってる？

2. サーバ管理ちょっとでもやったことある？

6

この講義の目的

•クラウド時代のWebシステムについて

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

• 「クラウドを使う」とはどういうことか

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

•クラウドのさらなる活用

•演習

7

サービスの運用とは

• 1時間サービスが止まったときの被害はおいくら？

8

経歴

• 2003-09～2005-03 大学院ネットワーク管理



• 2005-08～2008-09 AIP

• 2008-10～2009-12 KBB, I&D

• 2010-01～2013-06 Xtone


• 2016-02～現職 WHERE ⬅今ここ

学生

社会人

1999-04

↓

2006-03

2006-03

↓

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

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

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

•半分が広告事業

• 広告の配信システム

• 広告の代理業

•残りの半分がゲーム＋メディア

• 「グラブル」「デレステ」

• アメブロ、AbemaTV

10

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



• 2016年4Qのゲーム事業売上高：345億円（四半期決算）（2016/07/01～2016/09/30：92日間）

• 1時間あたり1,563万円（1分あたり26万円）

11

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



• 2016年4Qのゲーム事業売上高：345億円（四半期決算）（2016/07/01～2016/09/30：92日間）

• 1時間あたり1,563万円（1分あたり26万円）

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

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

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

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

12

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


•目的：

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

•手段：

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

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

13

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

サービス運用の価値

•サービスの品質

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

•サービスの稼働率

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

14

＜時間単価＞ × ＜稼働時間＞

サービス運用の価値

•サービスの品質

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

•サービスの稼働率

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

15

＜時間単価＞ × ＜稼働時間＞

• 便利、楽しい• 需要を満たす• 不具合が少ない• レスポンスが速い

• 止まらない

ウェブ業界の特徴

•「何もかもが速い」

•流行るのも一瞬

•廃れるのも一瞬

16

ウェブ業界の特徴

•「何もかもが速い」

•流行るのも一瞬

•廃れるのも一瞬

•状況に応じてシステムを最適化し続けることが重要

• DevOps、継続的デリバリー

•新技術を積極的に投入

•廃れたら素早く方針転換、もしくは割り切って廃止

17

流行ったらそれを逃さず「伸ばす」

インフラ的なつらさ

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

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

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

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

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

•新しい技術導入

•プロジェクトやリリース時期によってサーバ環境がバラバラ

18

もちろん「金の弾丸」にも限界はあります

それクラウドでできるよ

19

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

20

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

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

クラウドの分類

運用方法による分類

•パブリッククラウド

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

• AWSとかAzureとかいろいろ

•プライベートクラウド

•社内で単独で運用

• YahooとかCyberAgentとか

24

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

パブリッククラウド

•大規模な事業者

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

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

•責任共有モデル

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

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

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

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

25

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

プライベートクラウド

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

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

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

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

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

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

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

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

• 社内の「クラウド事業者」部門

26

「所有」から「利用」へ

•サーバを所有しない

•サービス部門は物理的なサーバを直接持たない

•サーバやデータセンター、ネットワークの管理をしない

•サーバは利用する

•必要な時間だけ、サーバの利用権を買う（借りる）

•その道の匠が設計した素敵なサーバ環境を利用できる

27

これが「クラウド」による変化の本質です。

クラウドのサービス分類

サービス形態による分類

• SaaS

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

• DropboxとかGmailとか

• PaaS

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

• Herokuとか

• IaaS

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

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

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

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

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

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

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

29

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

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

↓

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

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

30

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

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

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

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

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

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

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

31

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

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

•データベース

•セッション情報

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

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

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

32

クラウド時代の考え方

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

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

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

※物理サーバの考えを引っ張るとむしろ高く付くことも

33

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

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

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

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

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

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

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

•おかしくなったら殺す

34

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

「メリハリ」を付けよう

• Statelessサーバ 🐖🐓

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

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

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

• Statefulサーバ 🐕🐈

•データベース、ログ

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

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

35

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

Statelessサーバの指針

• Twelve-Factor App

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

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

36

http://12factor.net/ja/

Twelve-Factor App

I. コードベース

II. 依存関係

III. 設定

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

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

VI. プロセス

37

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

VIII. 並行性

IX. 廃棄容易性

X. 開発/本番一致

XI. ログ

XII. 管理プロセス

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

Twelve-Factor AppI. コードベース

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

• 1つのコードベース

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

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

•複数のデプロイ

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

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

38

Twelve-Factor AppIII. 設定

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

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

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

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

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

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

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

39

じゃあ、Statefulサーバは？

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

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

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

2. 分散DB

• Cassandra、HBase、MongoDBとかとか

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

• Amazon DynamoDBやGoogle BigQuery

40

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

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









41

Blue-Green Deployment

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

42

ｃ

L

B

サーバー

サーバー

サーバー

サーバー

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

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

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

DB

共通環境

動作が怪しかったらすぐ戻せるのが最大の特長緊急の脆弱性対応にも有用

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









43

Statefulサーバのセキュリティ運用

•本当はつらい脆弱性対応

•その修正バージョン、全く動作同じ？

•動作確認きちんとやって修正、反映するのはそれなりに手間

•かといって、世の中の脆弱性はたくさん……

44

脆弱性の評価

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

•実際に起こりづらい脅威に対する脆弱性なら優先度低い

•評価のためのフレームワークやツール

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

•脆弱性チェックの自動化ツール：Vulshttps://github.com/future-architect/vulsCVSSスコアで危険なものだけ通知できる※同種にOpenVASやAmazon Inspectorなどがある

45

セキュリティの運用は、いかに「人の判断」をシステムに落とし込んで

自動化するかが大事です。

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

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

CVSS v2の基準

•基本評価基準 (Base Metrics)

•脆弱性そのものの特性

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

•現状評価基準 (Temporal Metrics)

•今どれぐらいやばいか

•環境評価基準 (Environmental Metrics)

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

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)

47

クラウドの管理

•コントロールパネル

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

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

•つらい

•人間は必ずミスをする

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

48

「人間の操作の数＝意志決定した数」であるべきで、それ以外は余計なのです。

APIによるアクセス

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

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

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

• APIの利用

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

• REST API

•自動処理が可能に！

49

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

オフレコ（APIの悪用事例）

50

APIが万能である故の問題

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

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

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

•潤沢なリソースが利用可能

•めっちゃくちゃ速いサーバ

•めっちゃくちゃ大きいストレージ

•しかも一気にたくさん作れる（リミットはある）

51

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

クラウドの管理

•適切なアクセス制御

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

•最小権限の原則

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

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

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

52

最小権限の原則

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

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

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

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

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

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

53

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

AWS Identity and Access Management （IAM）

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

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

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

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

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

54

AWS CloudTrail

•操作内容を記録する

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

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

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

55

前半のまとめ

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

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

• APIの利用と権限の管理

56

― 休憩 ―

57

後半の目的

•前半

•クラウドでサーバを借りて上手くやる

•後半

•より深くクラウドらしい使い方

•みんなだいすき演習

58

クラウドのサービス分類

•いわゆるIaaS

•サーバ単位で借りる

•いわゆるPaaS

•機能単位で借りる

• Heroku、AWS Lambdaのような実行環境

• Amazon RDSやAWS IoTのような具体的な機能

59

IaaSの利用

•サーバを自前で用意せずクラウドで借りる

•システム全体を大きく帰ることなく、スケールアップ（性能を上げる）スケールアウト（台数を増やす）

のようなメリットを得やすい

60

PaaSの活用

•「ありもの」を組み合わせる

•餅は餅屋モデル

•「EC2使ったら負け」

•システム自体の変化が強いられる

•一見高く見えることも

•これまで見えていなかったコスト・リスクの可視化

•上手くはまる＝最適化できると画期的なコスト減も

61

Amazon Web Services (AWS)

•世界で一番大規模なクラウド事業者

•対抗馬はMicrosoft Azure

•シェアはまだ大きな差がある

•機能面では追いつきつつある（部分的に先行）

62

63

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

AWSのポイント

•責任共有モデル

• OSから上を利用者が責任を持つ（アマゾンは責任を持たない）

• OSから下はアマゾンが責任を持つ

•独特な冗長化設計

•リージョンとアベイラビリティゾーン

64

リージョンとアベイラビリティゾーン

•リージョン（Region）

•一つの地域に置かれ、システム的に独立したまとまり

•「東京」「オレゴン」「北カリフォルニア」

•アベイラビリティゾーン（AZ）

• 1つのリージョン内に複数設置されたまとまり

•一つの故障が複数のAZで併発しないように分離

•個別のデータセンターを想定

65

AWSにおける冗長化の基本

同じ役割のサーバを、各AZで半々に設置

66

ap-northeast-1a ap-northeast-1c

Web Web

DBDB

ap-northeast-1

SLAでみる冗長化設計

複数のAZにまたがってサーバ置いていないと、落ちても知らないよ？

67

サービス利用者がインスタンスを実行している複数のAvailability Zoneが、

サービス利用者にとって「使用不能」となること

＝

https://aws.amazon.com/jp/ec2/sla/

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

AWSでの冗長化の基礎

•「サーバ」という枠がないもの

• Amazon S3 （ファイルストレージ）

• Elastic Load Balancer（ロードバランサー）

• DynamoDB（NoSQLデータベース）

•などなど

•これらはAZを意識せずに冗長化されている

•これらの活用が運用を楽にする勝利の鍵

68

サーバインフラのコード化

•「Infrastructure as Code」

•サーバ構成をコード（具体的にはJSONやRubyベースのDSLなど）で実装し、それをもとにAPIをたたいて展開

•プログラミング的手法で改善が可能

• Git等でのリビジョン管理、レビュー

•デプロイツールの活用

•自動テスト

69

Terraform

• AWSやAzureの構成をコード化

•コードに合わせて必要なサーバやコンポーネントを作成

• 不必要になったら削除

• JSONで書く

•信頼と安定のHashicorp

70

HashiCorp

•クラウドを管理するツールの開発会社

• OSSでツールを提供

• Vagrant、Packer、Terraform、Serf、Consul、Vault……

• Hashicorpのビジョン「The Tao of HashiCorp」

•原文: https://www.hashicorp.com/blog/tao-of-hashicorp.html

•日本語訳: http://pocketstudio.jp/log3/2015/03/14/the-tao-of-hashicorp/

71

Hashicorpのビジョンは、「クラウドと自動化」を語る上で

たいへん参考になるものです。ぜひご一読。

https://www.hashicorp.com/blog/tao-of-hashicorp.html

http://pocketstudio.jp/log3/2015/03/14/the-tao-of-hashicorp/

Terraformの設定例

72

resource "aws_instance" "bastion" {tags { Name = "bastion" }ami = "${data.aws_ami.bastion.id}"instance_type = "t2.micro"vpc_security_group_ids = [

"${aws_security_group.internal.id}","${aws_security_group.bastion.id}“

]subnet_id = "${aws_subnet.shared-vpc-subnet-a.id}"associate_public_ip_address = true

}

Infrastructure as Codeの目的

•「プログラミングの手法」をインフラ管理に適用

• Git等によるリビジョン管理、Pull-Requestレビュー

•テスト駆動

•再利用しやすいDSL（ドメイン固有言語）による記述

• Terraformでかなりの部分を実現

• AWS自身のCloudFormationなどもある

•サーバ「内部」の管理は……？

73

サーバの構成管理

•サーバの環境（アプリケーションの実行環境）を管理

• OSの設定

•ミドルウェアの導入

•ミドルウェアの設定ファイルの設置

•アプリケーションの設置に必要な調整

74

サーバ構成管理の歴史

1. 職人芸

2. 手順書

3. シェルスクリプト

4. 構成管理ツール

5. アプリケーションコンテナ＋軽量なツール

75

構成管理ツール

• Puppet、Chef、Ansible

•主な違い

•対象サーバのリストの管理方法

•対象サーバへのソフトウェア導入要否（≒SSHだけで遠隔操作できるか）

•構成を記述するDSLPuppet=独自DSL、Chef=内部DSL(Ruby)、Ansible＝YAML

•冪等性の担保（差分を計算して適用）

76

アプリケーションコンテナの登場

•対象サーバの上で直接アプリケーションを実行

↓

•仮想化機能を使って、アプリケーションのパッケージ「コンテナ」の中でアプリケーションを実行

77

アプリケーションコンテナ

•アプリケーションの実行環境をパッケージにしたもの

•ファイルシステム一式

• OS環境

• 必要なライブラリ・ミドルウェア

• アプリケーション本体

•コンテナ起動時に実行するコマンドライン

•外部に公開する(LISTENする)TCPポート番号

•外部と共有するファイルシステムのパス

78

Docker

•アプリケーションコンテナの実行環境＋α

•仮想化機能の上でアプリケーションを実行

• DockerHubからコンテナイメージを取ってくる

•複数のコンテナを同時に管理する docker-compose

•その他様々な管理ツールの集合体

79

コンテナ時代の構成管理

•ゼロからアプリケーションを動かせば良い

•冪等性を考えたりとかしなくて良くなった

•実はそれシェルスクリプトでよくね？

• DB接続先などは、コンテナのイメージとして配るのでは無く、起動時に設定したい

•シェルスクリプト（標準のDockerfile）小さなツール

80

アプリケーションPaaS（aPaaS）

•より汎用な枠組み

•アプリケーションの実行環境の準備、運用を、全て自動化されたaPaaSに「おまかせ」

• Heroku、Amazon Beanstalk、Azure Web Apps

• Dockerコンテナを動かせたりもする

81

サーバレスアーキテクチャ

•最近流行りのキーワード

• Question: サーバ「レス」とは？

82

二つのサーバレスアーキテクチャ

•アプリケーション実行環境としてのサーバレス

•システム全体における役割としてのサーバレス

サーバレスなアプリケーション実行環境

•「フルマネージドなPaaS」の発展系

•利用者にとって「サーバ」という管理単位をなくしたい

•その筋のプロである「クラウド事業者」が、それぞれの方法で適切に管理してくれる＝フルマネージド

•使う量（確保量）から使った量（使用量）へのシフト

•事前に「台数」の確保が不要

•短時間で起動し、必要なだけ拡張

•実際の実行時間で課金される「確保量から使用量へ」は「所有から利用へ」の先にあるものです。

サーバレスなアプリケーション実行環境

•基本的には、高度に発達したアプリケーションPaaS

• AWS Lambdaの例

• 1プロセスが利用する最大メモリ量を指定（例：256MB）

• 100ミリ秒単位で、実際に消費した時間を課金

•呼び出し頻度に応じて、自動的にプロセス起動数を管理

85

制約とメリット

•アプリケーションのプロセス起動・終了を任せる⇒プロセス内にデータを保存することができない前半の「Stateless」サーバの考え方の徹底

•「Stateless」という制約を受け入れることで、「フルマネージド」というメリットが得られる

86

「何でもできる」ことは良いとは限らず、「良い制約」にうまく乗っかることが重要です。

システム全体における役割としてのサーバレス

一つの大きな「アプリケーションサーバ」

↓

クラウドが提供するコンポーネントの有効活用

↓

細かい「マイクロサービス」の組み合わせに分割

通信形態の大きな変化

•従来：リクエスト・レスポンスなどの同期型通信

•リクエストを受けたプログラムが、データベースへの読み書きなど、レスポンスを返すまで全ての処理を担当

•今後：非同期型通信が普及

•スマホアプリやWebSocket等の普及で、ブラウザまで含めて非同期なシステムを作ることが増えてきた

88

LINE BotやIoT×ビッグデータ解析のようなシステムも、本質的に非同期にできています。

サーバレスアーキテクチャの例

89

IoTデバイス

SORACOM

FunnelKinesis

Streams

(AWS Lambda)

Status Updater

最新ステータス

API Gateway

Cognito Identity

Amazon S3

(AWS Lambda)

Manager App

管理者

複雑なパターン

•Amazon S3に動画ファイルをアップロード

⇒それをトリガにしてフォーマット変換を起動

⇒変換が終わったら動画一覧を再生成

⇒生成できたらCDNのキャッシュをクリア

⇒全部終わったら投稿者にメール

•複雑な機能はピタゴラ装置のように作る

90

リアクティブアーキテクチャ

リアクティブ宣言：近代的なシステムを実現するための設計原則

1. 即応性（実現したい価値）

• システム全体として素早く、かつ安定した応答時間を保つ。

2. 耐障害性（非機能要件）

• 障害が発生しても、それをコンポーネント内部に影響を隔離することで、システム全体としての即応性を保つ。

3. 弾力性（非機能要件）

• 負荷の増減があっても、ボトルネックを排除し、割り当てるリソースを調整することで、即応性を保つ。

4. メッセージ駆動（アーキテクチャ構成要件）

• 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。


•超ざっくり言うと、

•小さなプログラムを

•メッセージ駆動で

•繋いでいく

•という非同期型アーキテクチャが良い、という考え方

92


•「ペットから家畜へ」を踏まえたアーキテクチャ

93

メッセージ

ワーカー

ワーカー

ワーカー

ワーカー

ワーカー

ワーカー


•「ペットから家畜へ」を踏まえたアーキテクチャ

94

メッセージ

ワーカー

ワーカー

ワーカー他の誰かが実行

ワーカー

ワーカー

ワーカー

サーバレス時代のセキュリティ

•これまで

•一つの大きなアプリケーションの「中身」に侵入

•アプリケーションの実装方法の脆弱性

•これから

•小さなアプリケーション⇒実装レベルの脆弱性は減少してほしい…

•コンポーネントの利用方法レベルの脆弱性

• ID管理に基づいたコンポーネント単位の認可がより重要に

95

サーバレスアーキテクチャの本質

•動かしたいのは「サービス」で「サーバ」ではない

• Statelessという制約を受け入れることで、「サーバ」という単位で管理する必要を無くした

•フルマネージドなサービスの活用＝「餅は餅屋」

•サービスの実現のためのベストプラクティスの一つ

96

クラウドの活用方法のおさらい

•冗長化

•サーバインフラのコード化

•アプリケーションコンテナ（Docker）

•サーバレスアーキテクチャ

97

演習

• AWSで実際にサービスを立ててみよう

1. マネジメントコンソールへのログインを確認

2. Amazon S3にファイルをアップロードして公開

3. SSH鍵対を作成してAWSに登録

4. Amazon EC2でサーバを構築

5. 構築したサーバをCLIから見てみよう

6. 構築したサーバにログインしてAPIサーバを構築

7. S3に置いたHTMLからAPIを叩いてみる

8. ここまでの操作ログを見てみよう

98

1. マネジメントコンソールへのログインを確認

1. お渡ししたログイン情報のURLを開く

2. IDとパスワードを入力

3. マネジメントコンソールにログインできることを確認

4. 右上が「オレゴン」など東京以外になっていたら、プルダウンメニューから東京に切り替え

99

2. Amazon S3にファイルをアップロードして公開

ここではAPIでの操作に触れてもらいます。

1. コマンドプロンプトからaws configure を実行し、以下のように入力

2. aws s3 mbコマンドでバケット（ファイルの置き場所）を作成

3. aws s3 cpコマンドでファイルをアップロード（index.htmlは適当に用意）

4. 以下のURLをブラウザで開いて、アップロードされたことを確認http://s3-ap-northeast-1.amazonaws.com/seccamp1126-＜自分の名前＞/index.html

100

AWS Access Key ID [None]: ＜アクセスキーID＞AWS Secret Access Key [None]: ＜シークレットアクセスキー＞

Default region name [None]: ap-northeast-1Default output format [None]: json

aws s3 mb s3://seccamp1126-＜自分の名前＞

aws s3 cp index.html s3://seccamp1126-＜自分の名前＞/ --acl public-read

3. SSH鍵対を作成してAWSに登録 (1)

1. スタートメニューから、「PuTTYgen」を起動

2. 「Generate」をクリックし、マウスぐりぐりしながら待機

3. Key commentに自分の名前をアルファベットで入力Key passphraseとすぐ下のConfirmに自分が覚えるパスフレーズを入力

4. Save private keyをクリックし、ドキュメントに秘密鍵を保存

5. 保存した秘密鍵をダブルクリックして、パスフレーズを入力

6. 上のテキストボックス（Public key for pastingなんちゃら）に表示されている公開鍵をメモ帳に張り付けて、ドキュメントに保存

101

PuTTY版


1. デスクトップから、「TeraTerm」を起動

2. 設定メニューからSSH鍵生成を起動

3. 「生成」をクリックし、マウスぐりぐりしながら待機

4. パスフレーズとすぐ下のConfirmに自分が覚えるパスフレーズ入力コメントに自分の名前をアルファベットで

5. 秘密鍵を保存をクリックし、ドキュメントに秘密鍵を保存

6. 公開鍵を保存をクリックし、ドキュメントに公開鍵を保存

102

TeraTerm版


1. マネジメントコンソールの左上から、EC2を開く

2. 左メニューの「キーペア」を開く

3. 「キーペアのインポート」をクリック

4. ファイル選択で先ほど保存した公開鍵のファイルを選択

5. キーペア名に名前をアルファベットで入力

103

4. Amazon EC2でサーバを構築 (1)

1. マネジメントコンソールの左上から、EC2を開く

2. 左メニューの「インスタンス」を開く

3. マシンイメージ（OSインストール済みのディスクデータ）を聞かれるので、一番上の「Amazon Linux AMI」を選ぶ

4. インスタンスタイプは、t2.microを選ぶ

5. 「自動割り当てパブリック IP」が有効になっていることを確認して次の手順へ

6. ストレージの追加はそのまま次の手順へ

104


1. 「Add Tags」の画面で、Nameに名前をアルファベットで入力

2. セキュリティグループの設定で以下のように設定

• 新しいセキュリティグループを作成する

• 元からある行を以下のように設定タイプ：SSH 送信元：マイIP

• ルールの追加をクリックし、追加された行を、タイプ：HTTP 送信元：カスタム 0.0.0.0/0

3. 確認と作成をクリックし、次の確認画面で「作成」を実行

4. キーペアとして、先ほど登録した自分の名前のものを選択してインスタンスの作成

105


1. 「次のインスタンスの作成が開始されました: i-99999999 」のように表示されるので、i- ではじまるインスタンスIDをクリック

2. ステータスチェック欄が「✔」になるまで待機右上の丸い矢印をクリックすると再読込します。

106

5. 構築したサーバをCLIから見てみよう

1. コマンドラインから以下のコマンドでEC2のインスタンス一覧が見られます。

107

aws ec2 describe-instances


1. 「パブリックIP」に表示されたIPアドレスをメモ

2. PuTTYを起動し、上のIPアドレスを入力して接続

3. 「login as:」でログインユーザ名を聞かれるので「ec2-user」を入力

4. SSHで正しくログインできたことを確認

5. sudo yum update -y && sudo yum install httpd –y

sudo service httpd startを実行してApacheをインストール

6. http://＜IPアドレス＞/ をブラウザで見られることを確認

7. sudo chown ec2-user /var/www/html

108

PuTTY版


1. 「パブリックIP」に表示されたIPアドレスをメモ

2. TeraTermを起動し、上のIPアドレスを入力して接続

3. ログインユーザ名を聞かれるので「ec2-user」を入力し、その下にパスフレーズを入力「RSA/DSA/ECDSA/ED25519鍵を使う」を選択し、秘密鍵ボタンで、さきほど保存した秘密鍵ファイルを指定

4. SSHで正しくログインできたことを確認

5. sudo yum update -y && sudo yum install httpd –y

sudo service httpd startを実行してApacheをインストール

6. http://＜IPアドレス＞/ をブラウザで見られることを確認

7. sudo chown ec2-user /var/www/html 109

TeraTerm版


1. API結果を想定したJSONファイルを保存

/var/www/html/api.json

2. クロスオリジン対策の設定ファイルを保存

sudoedit /etc/httpd/conf.d/cors.conf

3. sudo service httpd restart

110

{"message":"Hello, Cloud!"}

<Directory "/var/www/html">Header append Access-Control-Allow-Origin: "*"

</Directory>

7. S3に置いたHTMLからAPIを叩いてみる

1. 配布した index.html の中のIPアドレスをサーバのものに変更

2. これまでの手順を参考に、S3にアップロード

3. S3上にアップロードしたHTMLを開いてAPIが呼ばれたことを確認http://s3-ap-northeast-1.amazonaws.com/＜バケット名＞/index.html

111

8. ここまでの操作ログを見てみよう

1. 左上のサービス一覧からCloudTrailを選択

2. 今までの操作履歴がどのように記録されているのかを確認する

112

演習のおさらい

• EC2を使って、サーバを立ててみました

•クラウドのサービス分類ではIaaSと呼ばれる

• awsコマンドを使ってAPI経由で操作することも可能

• S3を使って、より楽にウェブサーバを立てました

•サービス分類としてはPaaS

•便利でしょ？

•どんな記録が残るのか見てみました

113

まとめ

•クラウド時代のWebシステムについて

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

• 「クラウドを使う」とはどういうことか

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

•クラウドのさらなる活用

•演習

114

最後に

•特にこの10年のインフラ業界は動きが早いです

•クラウドが登場して（まだ）10年間

•前提が変わり、ベストプラクティスが入れ替わる

•個人的には、・この10年で物理サーバからクラウド上の仮想サーバに・今後10年でサーバという枠組みから解放と予想しています

•ツールレベルの盛衰は、一々取り上げるのも切りが無い

•動きが早い＝面白い！115

最後に

•すぐに手を動かそう！

•無料クーポン、無料枠を活用しよう（学生はより有利！）

•大きな機能もちょっとだけなら安くお試しできる！

•とにかくネタと機会を作って情報を発信しよう！

•情報は活動する人の近くに集まる

•ブログ等での情報発信

•勉強会等での発表

•同人誌等の制作、頒布

116

クラウドセキュリティ基礎 ＠セキュリティ・ミニキャンプ in 東北 2016...

Technology

クラウドセキュリティ基礎＠セキュリティ・ミニキャンプ in 東北 2016...