IoT時代のセキュアなクラウドインフラ構築術 #seccamp
1.4K Views
March 31, 18
スライド概要
2017-08-16 セキュリティ・キャンプ全国大会2017 #seccamp
秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア。 0と1が紡ぐ「ゆるやかなつながり」に魅せられ早20年、 SNSとCGMの力で世界を幸福にするのがライフワーク。 市民、幸福は義務です。 あなたは幸福ですか？
関連スライド
各ページのテキスト
IoT時代の セキュアなクラウドインフラ 構築術 株式会社WHERE IoT基盤センター サービスプロデューサー 兼 情報システム室 インフラエンジニア 仲山 昌宏 ( @nekoruri )
講師プロフィール • 仲山 昌宏 • 株式会社WHERE IoT基盤センター サービスプロデューサー 兼 情報システム室 インフラエンジニア • 秋葉原生まれ大手町育ちの 歌って踊れる江戸っ子インフラエンジニア • @nekoruri 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 大学院ネットワーク管理 • 2004-03～2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用 • 2004-09～2005-10 国際大学GLOCOM (研究アシスタント) SNS CGM • 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 (測位技術スタートアップ) ⬅今ここ ソーシャルゲーム
主なスキルセット • システム設計 • クラウドとIoTデバイス組み合わせて 良い感じのシステム/ソリューション • ウェブアプリの内部アーキテクチャ • アプリケーション開発 • サーバーレス構成なサーバサイド • 普通のサーバサイド（＋フロント） Perl、Ruby、Python、JS、PHP • 過去にはWindowsとかも • 情報システム • 社内ITシステムの設計、運用 • 情報セキュリティマネジメント • サーバ/ネットワーク運用 • サーバHW（特にストレージ）周り • IPネットワーク • 「必要があればなんでもやる」 5
アンケート 1. クラウドってなんとなく知ってる？ 2. サーバ管理ちょっとでもやったことある？ 6
この講義の目的 • IoT時代のクラウド環境について • クラウドネイティブな設計 • IoTとクラウドの連携におけるセキュリティ • ハンズオン • 「RasPi⇒SORACOM⇒Azureでデータ分析」という事例 • 「クラウドネイティブ」についての実感 7
サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ 8
経歴 • 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、AWA • グラブル、デレステ、ガルパ https://www.cyberagent.co.jp/ir/strategy/ 10
サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2017年3Qのゲーム事業売上高：334億円（四半期決算） （2017/04/01～2017/06/30：91日間） 11
サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2017年3Qのゲーム事業売上高：334億円（四半期決算） （2017/04/01～2017/06/30：91日間） • 1時間あたり1,529万円 12
サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2017年3Qのゲーム事業売上高：334億円（四半期決算） （2017/04/01～2017/06/30：91日間） • 1時間あたり1,529万円（1分あたり25万円） 13
サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2017年3Qのゲーム事業売上高：334億円（四半期決算） （2017/04/01～2017/06/30：91日間） • 1時間あたり1,529万円（1分あたり25万円） • ピークタイム（稼ぎ時） • 期間限定イベントのラストスパート • 年始めのおみくじ代わり • 月初（キャリア決済の限度額がクリア） 14
サービスの運用とは • 目的： • ITを使って「お金を稼ぐ」 • 手段： • お客さんにサービスを提供し、その対価を受け取る （直接部門） • 従業員にサービスを提供し、生産性を向上させる （間接部門） 15
サービス運用の価値 • サービスの品質 • サービスの内容がお客さん の期待を満たすこと • • • • 便利、楽しい 需要を満たす 不具合が少ない レスポンスが速い • サービスの稼働率 • 使いたいときに使える （落ちていない）こと • 止まらない ＜時間単価＞ × ＜稼働時間＞ 16
ウェブ業界の特徴 • 「何もかもが速い」 • 流行るのも一瞬 • 廃れるのも一瞬 17
ウェブ業界の特徴 • 「何もかもが速い」 • 流行るのも一瞬 • 廃れるのも一瞬 流行ったらそれを逃さず「伸ばす」 • 状況に応じてシステムを最適化し続けることが重要 • DevOps、継続的デリバリー • 新技術を積極的に投入 • 廃れたら素早く方針転換、もしくは割り切って廃止 18
インフラ的なつらさ • 流行れば大量のサーバがすぐに必要になる • チューニングには時間が掛かり限界もある • とにかくサーバ追加で時間を「稼ぐ」（通称：金の弾丸） • 廃れればどんどん縮小させる • 縮小しきれない過剰投資は「損失」でしかない • 新しい技術導入 • プロジェクトやリリース時期によってサーバ環境がバラバラ 19
それクラウドでできるよ 20
クラウドコンピューティング https://www.ipa.go.jp/files/000025366.pdf 21
クラウドコンピューティング https://www.ipa.go.jp/files/000025366.pdf 22
クラウドコンピューティング • 要点 • 共用されたリソースプールから • いつでもどこからでもネットワーク経由で • 必要な分だけをすぐに利用できる 23
クラウドの特徴 NIST（米国国立標準技術研究所）による基本特徴の整理 1. オンデマンド・ セルフサービス APIでなんでもできる 2. 幅広いネットワークアクセス ネットワーク経由でできる 3. リソースの共用 共用する潤沢なリソースプールがある 4. スピーディな拡張性 すぐに利用可能 5. サービスが 計測可能であること 自らの利用量が適切に計測（されて課金される） 24
クラウドの分類 運用方法による分類 • パブリッククラウド • 大規模な事業者が運用して数多くの利用者が共有 • AWSとかAzureとかいろいろ • プライベートクラウド • 社内で単独で運用 • YahooとかCyberAgentとか 25
パブリッククラウド • 大規模な事業者 • 豊富なリソースにもとづく最適化 • 膨大な開発能力にもとづく多種多様な機能 • 責任共有モデル • ざっくりOSから下は事業者がセキュリティを担保 • 各種セキュリティガイドラインへの準拠 • むしろベストプラクティスが実装された環境 • OSとその上は利用者がセキュリティを自力で担保 26
プライベートクラウド • 既存の自前でデータセンタ借りてサーバ置くモデル • OpenStackなどのクラウドコントローラでクラウド化 • 基本機能はAmazon等と似たようなことができる • 多種多様な機能は少ない • プライベートでの差別化 • 既にノウハウや購買力を持つ場合 • システム間が密結合（消極的理由） • これらを維持しつつ、クラウドや仮想化のメリットを享受 • 社内の「クラウド事業者」部門 27
「所有」から「利用」へ • サーバを所有しない • サービス部門は物理的なサーバを直接持たない • サーバやデータセンター、ネットワークの管理をしない • サーバは利用する • 必要な時間だけ、サーバの利用権を買う（借りる） • その道の匠が設計した素敵なサーバ環境を利用できる • 彼らの考えた「ベストプラクティス」に自分を合わせる 28
「所有」から「利用」へ • そもそも所有するべき技術を絞り込む • クラウド基盤の運用は、自分たちのビジネス領域では無い • 自ら技術者を確保するコストは決して安くない • 「利用」することで、自らのコア事業に集中できる ↔「技術」があることは悪では無い • 内部を知っているほど最適な設定が導き出せる • トラブルシュート（とにかく全方位の能力が問われる） 29
クラウドのサービス分類 サービス形態による分類 • SaaS • 具体的なアプリケーションとして提供される。 • DropboxとかGmailとか • PaaS • アプリケーションが動く環境が用意される。 • Herokuとか • IaaS • サーバ一式が用意される。いわゆるレンタルサーバに近い。 • ネットワーク機能（FW、LB等）も提供されたりする。 30
クラウド(IaaS)でサーバを確保 • 自由なサーバの追加・削除が可能になる • すぐ（数分程度）にサーバが増やせる！ ↔ これまでは最大想定分だけのサーバを事前に用意 ↔ 想定を超えるとすぐに対応ができない • 要らないサーバはいつでも捨てられる！ ↔ 資産の耐用年数（5年程度）を使い切れない ↔ 挑戦的なサービスをリリースできない 31
ポイント1 作ったサーバに環境構築してすぐ本番投入したい • サーバの構築や運用の手間はかわらない • ミドルウェア入れて設定ファイルを変更 • アプリの動作に必要なライブラリも入れる • 最新のアプリケーションをデプロイ（設置） • アプリケーション設定（DB認証情報等）も設置 • アプリケーションのプロセスを起動 32
ポイント2 本番投入中のサーバでもすぐに消したい • サーバ内に記録されたデータはどうする？ • データベース • セッション情報 • アクセスログ、エラーログ、デバッグログ • システムログ（syslog, イベントログ） • 一時的に手で入れたテスト用設定 33
クラウド時代の考え方 • サーバの設計方法も合わせていこう！ • 構築や運用が楽になる方法を作る • システム全体のデータの記録方法を見直す ※物理サーバの考えを引っ張るとむしろ高く付くことも 34
「ペット」から「家畜」へ • これまで：サーバ＝ペット🐕🐈 • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • これから：サーバ＝家畜🐖🐓 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す。慈悲は無い。 35
「メリハリ」を付けよう • Statelessサーバ 🐖🐓 • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ 🐕🐈 • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 36
Statelessサーバの指針 • Twelve-Factor App • http://12factor.net/ja/ • （いくつか宗教的な項目もあるものの） 今までに提起された最適解の「まとめ」 37
Twelve-Factor App I. コードベース VII. ポートバインディング II. 依存関係 VIII. 並行性 III. 設定 IX. 廃棄容易性 IV. バックエンドサービス X. 開発/本番一致 V. ビルド、リリース、実行 XI. ログ VI. プロセス XII. 管理プロセス 38
Twelve-Factor App I. コードベース VII. ポートバインディング II. 依存関係 VIII. 並行性 III. 設定 IX. 廃棄容易性 IV. バックエンドサービス X. 開発/本番一致 V. ビルド、リリース、実行 XI. ログ VI. プロセス XII. 管理プロセス 39
Twelve-Factor App I. コードベース バージョン管理されている1つのコードベースと 複数のデプロイ • 1つのコードベース • アプリケーション全体が一つのレポジトリ • それ以外は、依存ライブラリか参照先の外部システム • 複数のデプロイ • 本番環境、ステージング環境、開発環境 • 全ての変更をきちんと記録・追跡 40
Twelve-Factor App III. 設定 設定を環境変数に格納する • デプロイごとに異なる設定 • DB接続先とかドメイン名とか • アプリ本体に設定を保存しない • 起動時に動的に設定できるようにする • あたらしい種類のデプロイをすぐ作れるようにする • ソースコードを完全に同一にできる 41
Twelve-Factor App I. コードベース VII. ポートバインディング II. 依存関係 VIII. 並行性 III. 設定 IX. 廃棄容易性 IV. バックエンドサービス X. 開発/本番一致 V. ビルド、リリース、実行 XI. ログ VI. プロセス XII. 管理プロセス 42
じゃあ、Statefulサーバは？ 「銀の弾丸」は無いが、現実的な選択肢は増えている。 1. スケールアップで対応（金の弾丸） • 「Fusion-ioは甘え」でもいいじゃないか 2. 分散DB • Cassandra、HBase、MongoDBとかとか 3. すごいストレージサービスを使う • Amazon DynamoDBやGoogle BigQuery 43
クラウド時代のサーバ設計 • Statelessサーバ 🐖🐓 • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ 🐕🐈 • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 44
クラウド時代のサーバ設計 • Statelessサーバ 🐖🐓 • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ 🐕🐈 • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 45
Blue-Green Deployment • もう1セット（Green）作って 古い方（Blue）を捨てよう！ ③問題が無ければ 古い環境（Blue）を廃棄 サーバー サーバー L B ②Greenに アクセス先を 切り替え サーバー ｃ DB 共通環境 サーバー ①新しいバージョン（Green）の 環境を構築 46
クラウド時代のサーバ設計 • Statelessサーバ 🐖🐓 • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ 🐕🐈 • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 47
Statefulサーバのセキュリティ運用 • 本当はつらい脆弱性対応 • その修正バージョン、全く動作同じ？ • 動作確認きちんとやって修正、反映するのはそれなりに手間 • かといって、世の中の脆弱性はたくさん…… 48
脆弱性の評価 • きちんと脆弱性を評価して優先度を決めよう！ • 実際に起こりづらい脅威に対する脆弱性なら優先度低い • 評価のためのフレームワークやツール • 共通脆弱性評価システム：CVSS v2 https://www.ipa.go.jp/security/vuln/CVSS.html • 脆弱性チェックの自動化ツール：Vuls https://github.com/future-architect/vuls CVSSスコアで危険なものだけ通知できる ※同種にOpenVASやAmazon Inspectorなどがある 49
CVSS v2の基準 • 基本評価基準 (Base Metrics) • 脆弱性そのものの特性 • 機密性、完全性、可用性への影響、 攻撃のしやすさ（ネットワーク経由の攻撃可否など） • 現状評価基準 (Temporal Metrics) • 今どれぐらいやばいか • 環境評価基準 (Environmental Metrics) • 二次被害の度合いとかその他の影響範囲 50
Statefulサーバの運用 • 案2：自分で運用しない • クラウド時代の原則：「所有」から「利用」へ • クラウドが運用してくれる「マネージドサービス」を利用 • Amazon RDS • Azure Database for {MySQL|PostgreSQL} • ぜんぶおまかせ！ • 冗長性確保、障害対応 • セキュリティ・パッチ対応 • バックアップ、リストア処理 51
クラウドの管理 • コントロールパネル • ブラウザで人がログイン • マウスでクリッククリッククリック…… • つらい • 人間は必ずミスをする • そもそも人の意志決定の余地は少ない 52
APIによるアクセス • サーバ環境をAPIで操作可能 • APIの認証情報（アクセスキー）を利用 • コントロールパネルとほぼ同じ操作が可能 • APIの利用 • APIを利用するライブラリやCLIコマンド • REST API • 自動処理が可能に！ 53
APIが万能である故の問題 • APIの認証情報があれば何でもできてしまう • 自動化プログラムとかにカジュアルに組み込みやすい • なにかされたことにすぐに気付きにくい • 潤沢なリソースが利用可能 • めっちゃくちゃ速いサーバ • めっちゃくちゃ大きいストレージ • しかも一気にたくさん作れる（リミットはある） 54
クラウドの管理 • 適切なアクセス制御 • 本当にその人に必要な作業しか実行させない • 最小権限の原則 • 操作内容の監査（記録） • 誰がその作業をしたのかを記録 • あやしい行動をチェックできる 55
最小権限の原則 • 情報セキュリティで最も重要な原則 • 必要最小限の権限だけを用意する • 例：アクセスキーの権限を最低限にする • 社外のIPアドレスから操作する権限は本当に必要？ • サンパウロでサーバ作成する権限は本当に必要？ • 1時間1400円もするサーバを作成する権限は(同上) 56
AWS Identity and Access Management （IAM） • アクセス権限を管理する仕組み • AWSは元々は1アカウント＝1認証情報（email/password) • ユーザやグループを作成して、権限を細かく割り当て可能 • より抽象化した「ロール」への割り当てもできる • アクセス元IPアドレスなども設定可能 57
AWS CloudTrail • 操作内容を記録する • Amazon S3（ストレージサービス）に保管 • 別のAWSアカウントにも送り込める • 外部の分析サービスとの連携も可能 58
ここまでのまとめ • クラウドコンピューティング • ペットから家畜へ、StatelessサーバとStatefulサーバ • APIの利用と権限の管理 59
― 休憩 ― 60
ここまでのまとめ • クラウドコンピューティング • ペットから家畜へ、StatelessサーバとStatefulサーバ • APIの利用と権限の管理 61
クラウドネイティブ？ • なんかサーバをクラウドから借りてるだけじゃない？ 62
クラウドネイティブ！ • もっとクラウドらしい使い方を考えよう • サーバの構成管理 • マネージドサービスの活用 • サーバーレスアーキテクチャ 63
サーバの構成管理 • サーバの環境（アプリケーションの実行環境）を管理 • OSの設定 • ミドルウェアの導入 • ミドルウェアの設定ファイルの設置 • アプリケーションの設置に必要な調整 64
サーバ構成管理の歴史 1. 職人芸 2. 手順書 3. シェルスクリプト 4. 構成管理ツール 5. アプリケーションコンテナ＋軽量なツール 6. PaaSの利用 65
構成管理ツール • Puppet、Chef、Ansible • 主な違い • 対象サーバのリストの管理方法 • 対象サーバへのソフトウェア導入要否 （≒SSHだけで遠隔操作できるか） • 構成を記述するDSL Puppet=独自DSL、Chef=内部DSL(Ruby)、Ansible＝YAML • 冪等性の担保（差分を計算して適用） 66
アプリケーションコンテナの登場 • 対象サーバの上で直接アプリケーションを実行 ↓ • 仮想化機能を使って、アプリケーションのパッケージ 「コンテナ」の中でアプリケーションを実行 67
アプリケーションコンテナ • アプリケーションの実行環境をパッケージにしたもの • ファイルシステム一式 • OS環境 • 必要なライブラリ・ミドルウェア • アプリケーション本体 • コンテナ起動時に実行するコマンドライン • 外部に公開する(LISTENする)TCPポート番号 • 外部と共有するファイルシステムのパス 68
Docker • アプリケーションコンテナの実行環境＋α • 仮想化機能の上でアプリケーションを実行 • DockerHubからコンテナイメージを取ってくる • 複数のコンテナを同時に管理する docker-compose • その他様々な管理ツールの集合体 69
コンテナ時代の構成管理 • ゼロからアプリケーションを動かせば良い • 冪等性を考えたりとかしなくて良くなった • 実はそれシェルスクリプトでよくね？ • DB接続先などは、コンテナのイメージとして配るのでは無 く、起動時に設定したい • シェルスクリプト（標準のDockerfile）小さなツール • とにかく「履歴管理」などができればよい 70
アプリケーションPaaS • より汎用な枠組み • アプリケーションの実行環境の準備、運用を、 全て自動化されたPaaSに「おまかせ」 • Heroku、Amazon Beanstalk、Azure Web Apps • Dockerコンテナを動かせたりもする 71
サーバの構成管理 • 「アプリケーションの実行環境」の標準化の歴史 • 自由度←→統一性 • 自分で独自の技術を持とうとしない方向へのシフト 72
クラウドのサービス分類 • いわゆるIaaS • サーバ単位で借りる • いわゆるPaaS • 機能単位で借りる • Heroku、AWS Lambdaのような実行環境 • Amazon RDSやAWS IoTのような具体的な機能 73
IaaSの利用 • サーバを自前で用意せずクラウドで借りる • システム全体の設計を大きく変更することなく、 スケールアップ（性能を上げる） スケールアウト（台数を増やす） のようなメリットを得やすい • あくまでサーバのレンタルに過ぎない 74
マネージドサービス（PaaS）の活用 • 「ありもの」を組み合わせる • 餅は餅屋 • 「EC2使ったら負け」 • システム自体の変化が強いられる • 一見高く見えることも • これまで見えていなかったコスト・リスクの顕在化 • 上手くはまる＝最適化できると画期的なコスト減も 75
マネージドサービスの活用 • 世界で一番大規模なAWSの場合 76
77
マネージドサービスの活用 • 世界で一番大規模なAWSの場合 • 多種多様なマネージドサービスを提供 • Microsoft AzureやGoogle Cloud Platformなども同様 • 各社それぞれ得意な領域がある 78
システムの実現方法の変化 • 基本的なミドルウェアの上にアプリケーションを実装 • MySQL＋Rails＋nginx • PostgreSQL＋Java/Spring＋Glassfish • アプリケーションが主 • 高レベルなサービスを組み合わせてシステムを実現 • ブラウザ上のSPAからデータストアを直接呼び出し • 大量に流れてくるデータを機械学習で特徴抽出 • 既にあるサービスの活用方法が主 79
システムの開発方法の変化 • 「何」を開発するのか • 従来はアプリケーションコード • それ以外は、運用のための基盤 • クラウド時代のシステム開発 • 様々なコンポーネントの「設定」「連携」を管理 • ソフトウェア開発で培った手法はどうする？ 80
サーバインフラのコード化 • 「Infrastructure as Code」 • サーバ構成をコード（具体的にはJSONやRubyベースの DSLなど）で実装し、それをもとにAPIをたたいて展開 • プログラミング的手法で継続的改善が可能 • Git等でのリビジョン管理、レビュー • デプロイツールの活用 • 自動テスト 81
Terraform • AWSやAzureの構成をコード化 • コードに合わせて必要なサーバやコンポーネントを作成 • 不必要になったら削除 • JSONで書く • 信頼と安定のHashicorp 82
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/ 83
Terraformの設定例 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 } 84
Infrastructure as Codeの目的 • 「プログラミングの手法」をインフラ管理に適用 • Git等によるリビジョン管理、Pull-Requestレビュー • テスト駆動 • 再利用しやすいDSL（ドメイン固有言語）による記述 • Terraformでかなりの部分を実現 • AWS自身のCloudFormationなどもある 85
マネージドサービスの活用 • 既にあるサービスを組み合わせて使う • 所有から利用へ • 多種多様なサービスの「ソムリエ」力が求められる （別なスキルへの変化） • 様々なサービスをソフトウェア開発的手法で効率よく管理 86
「サーバーレスアーキテクチャ」？ • 「サーバ」が「無い」アーキテクチャ • FAQ：「でもサーバ有るんでしょ？」 • イメージは人それぞれ • いまだに明確な定義はされていない
サーバーレスアーキテクチャ • 自分で管理する「サーバ」を無くすための二つの方針 1. 管理運用における「サーバ」という粒度を廃した、 フルマネージドなアプリケーション実行環境 2. クラウド上のコンポーネントをイベント駆動で結びつけて 最大限活用していくシステムアーキテクチャ
サーバーレスアーキテクチャ • 自分で管理する「サーバ」を無くすための二つの方針 1. 管理運用における「サーバ」という粒度を廃した、 フルマネージドなアプリケーション実行環境 （FaaS等に乗っかり自分で書くコードを減らす） 2. クラウド上のコンポーネントをイベント駆動で結びつけて 最大限活用していくシステムアーキテクチャ （そもそも自分で用意する機能そのものを減らす）
1. フルマネージドなアプリケーション実行環境 • 「フルマネージドなPaaS」の発展系 • 利用者にとって「サーバ」という管理単位をなくしたい • その筋のプロである「クラウド事業者」が、それぞれの方法 で適切に管理してくれる＝フルマネージド • 使う量（確保量）から使った量（使用量）へのシフト • 事前に「台数」の確保が不要 • 短時間で起動し、必要なだけ拡張 • 実際の実行時間（たとえば100ms単位）で課金される
制約とメリット • アプリケーションのプロセス起動・終了を任せる ⇒ プロセス内にデータを保存することができない 前半の「Stateless」サーバの考え方の徹底 • 「Stateless」という制約を受け入れることで、 「フルマネージド」というメリットが得られる 91
1. フルマネージドなアプリケーション実行環境 • いわゆる「FaaS（Function as a Service）」 • 「関数」と呼ばれる小さなコードを動かすマネージドサービス • 基本的にはコンテナベースでコードを動かす • 自動でスケール • 他のサービスから呼び出されて動く • APIゲートウェイ（同期） • イベントストリーム、ストレージ等からのトリガー（非同期） • 各社「サーバーレス」の中心人物 AWS Lambda、Azure Functions Google Cloud Functions、Bluemix OpenWhisk
1. フルマネージドなアプリケーション実行環境 • いわゆるPaaSとの違い • 明確な定義の違いは無く、スケールのしやすさで区別 https://twitter.com/adrianco/status/736553530689998848 • 実論まわりはFastContainerあたりの議論が分かりやすいです
2. コンポーネントを「のり付け」するアーキテクチャ 一つの大きな「アプリケーションサーバ」 ↓ クラウドが提供するコンポーネントの有効活用 ↓ 細かい「サービス」の組み合わせに分割
2. コンポーネントを「のり付け」するアーキテクチャ • 高機能なクラウド上のコンポーネントの活用 • Functional SaaS（Service as as Service） あるいはBaaS（Backend as a Service） • コンポーネント自身が高機能化し、様々な「イベント」を生成 • イベントからFaaSを呼び出して連携 • フロント側のネイティブアプリ化/SPA化の波 • アプリから直接データストア等にアクセスできる • 「ガチャ」のようなブラックボックスだけクラウド側に実装を持つ • アプリの一部としてクラウドとメッセージング連携
2. コンポーネントを「のり付け」するアーキテクチャ • クラウド時代の「制御の反転」 • アプリケーションサーバが各コンポーネントを呼び出すのではなく、 各コンポーネントを小さな関数が接続する • システムアーキテクチャの設計手法の変化 • マイクロサービス化、コレオグラフィ化の流れの一部 • 背景 • • • • 高水準なクラウド上のコンポーネントの登場 様々な「イベントトリガ」の整備 ID基盤のうえでコンポーネント側だけで細かいアクセス認可 そもそも「餅は餅屋」、自分で作らなくて良い部分が増えている。
サーバーレスアーキテクチャの例 IoTデバイス SORACOM Funnel Kinesis Streams (AWS Lambda) Status Updater (AWS Lambda) Manager App API Gateway 管理者 Amazon S3 最新ステータス Cognito Identity 97
ピタゴラ装置的な例 • Amazon S3に動画ファイルをアップロード ⇒それをトリガにしてフォーマット変換を起動 ⇒変換が終わったら動画一覧を再生成 ⇒生成できたらCDNのキャッシュをクリア ⇒全部終わったら投稿者にメール • 複雑な機能を、連鎖させて作りあげる 98
リアクティブシステム • 目的：即応性 • システム全体として、素早く、かつ安定した応答時間を保つ • 要件１：耐障害性 • 障害が発生しても、それをコンポーネント内部に影響を隔離すること で、システム全体としての即応性を保つ。 • 要件２：弾力性 • 負荷の増減があっても、ボトルネックを排除し、割り当てるリソース を調整することで、即応性を保つ。 • 手段：メッセージ駆動 • 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。
リアクティブシステム • メッセージ駆動（手段） • システム間をキューで非同期に接続する • 複数のワーカプロセスがキューから取ってきて処理 • 弾力性（要件2） • メッセージが増えてきたらワーカプロセスを増やせばよい • 横並びのワーカプロセスに相互依存はないので気軽にスケールアウト・イン • 耐障害性（要件1） • コンポーネントで異常が起きたら自爆して、別のワーカが実行 • ずっとおかしいメッセージはDead letter queueに積み替えて例外処理 • 即応性（目的） • 様々な状況に強いシステムが構築できる
リアクティブアーキテクチャ • 超ざっくり言うと、 • 小さなプログラムを • メッセージ駆動で • 繋いでいく • という非同期型アーキテクチャが良い、という考え方 101
リアクティブアーキテクチャ • 「ペットから家畜へ」を踏まえたアーキテクチャ メッセージ ワーカー ワーカー ワーカー ワーカー ワーカー ワーカー 102
リアクティブアーキテクチャ • 「ペットから家畜へ」を踏まえたアーキテクチャ メッセージ 他の誰かが実行 ワーカー ワーカー ワーカー ワーカー ワーカー ワーカー 103
サーバレス時代のセキュリティ • これまで • 一つの大きなアプリケーションの「中身」に侵入 • アプリケーションの実装方法の脆弱性 • これから • 小さなアプリケーション⇒実装レベルの脆弱性は減少 • コンポーネントの利用方法レベルの脆弱性 • ID管理に基づいたコンポーネント単位の認可がより重要に してほしい… 104
サーバーレスアーキテクチャの本質 • 動かしたいのは「サービス」で「サーバ」ではない • Statelessという制約を受け入れることで、 「サーバ」という単位で管理する必要を無くした • フルマネージドなサービスの活用＝「餅は餅屋」 • 運用コストを、「意志決定により近い領域」に変換 • サービスの実現のためのベストプラクティスの一つ 105
クラウドネイティブとは • クラウドらしい考え方を設計の根幹にすること • マネージドサービスの活用 • サーバーレスアーキテクチャ 106
IoTとクラウドネイティブ • そもそもIoTってなんだっけ • Internet of Things：モノのインターネット 107
IoTとクラウドネイティブ • そもそもIoTってなんだっけ • Internet of Things：モノのインターネット • 機器や通信技術が安価になったので、何でもつなごう！ • つないでデータを集めたらなにかできないか • 集めたデータを分析した結果が役に立たないか • その結果をもとに、様々な機器を制御できないか • 夢は無限に！ 108
IoTとクラウドネイティブ • そもそもIoTってなんだっけ • Internet of Things：モノのインターネット • 機器や通信技術が安価になったので、何でもつなごう！ • つないでデータを集めたらなにかできないか • 集めたデータを分析した結果が役に立たないか • その結果をもとに、様々な機器を制御できないか • 夢は無限に！ • 要するにそれただのインターネットの順調な発展だよね 109
IoTが話題になる理由 1. 脆弱で実際に被害が出ているから • 具体的な話は割愛 • でも、どうして？ 2. たくさんのデータが集められるから • いろんなことができそう！素敵！ • で、そんなヘビーなシステムどうすれば作れるの？ 110
IoTデバイスの脆弱性 • 「安価にインターネットに接続できるようになった」 • CPUの処理性能が低いなど、サバンナインターネットで 安全に暮らすための暗号化処理が厳しい • 想定不足による手抜き • 「大量にインターネットに接続できるようになった」 • 運用上などの理由から、機器を正しく個別管理できない • 共通パスワードとか、クラウド連携時の識別不備とか 111
OWASP Top IoT Vulnerability I1 Insecure Web Interface I2 Insufficient Authentication/Authorization I3 Insecure Network Services I4 Lack of Transport Encryption/Integrity Verification I5 Privacy Concerns I6 Insecure Cloud Interface I7 Insecure Mobile Interface I8 Insufficient Security Configurability I9 Insecure Software/Firmware I10 Poor Physical Security https://www.owasp.org/index.php/Top_IoT_Vulnerabilities 112
データ量の課題 • 古い設計手法では遠回り過ぎる • 普通のウェブアプリや業務アプリのやり方でさばくには 量が多すぎる • クラウドネイティブの活用が必須 • クラウド事業者自身がビッグデータを活用する企業 • 彼らのノウハウをマネージドサービスとして提供 113
ここまでの整理 • デバイスを正しく識別・管理 • デバイスの利用者を正しく認証する（今回は割愛） • デバイスがクラウドに対して正しく認証する • マネージドサービスでデータ処理 • 大量のデータに耐えるサービスを選ぶ • 分析、可視化などをうまく行う 114
IoTデバイスとクラウドの連携 1. デバイス上に認証情報を保存 • AWSやAzureが提供するIoTデバイス管理サービス • 自前で事前鍵や証明書を管理 2. デバイス外に認証情報を保存 • 耐タンパー性のあるセキュアエレメント • 接続回線とのセット（SORACOMやsakura.io） 115
SORACOM • 通信回線 • 3G/4G（NTTドコモのMVNO） • LPWA（LoRaWAN、Sigfox） • クラウド連携機能 116
クラウド連携機能 • 回線接続のレベルで、IoTデバイスを正しく認証 • その認証情報を元に様々な機能を提供 • 通信回線も暗号化されている • 暗号処理のオフロード • デバイスからSORACOMまで平文で投げる • デバイスに紐付いた認証情報を使ってSORACOMが 代理でクラウドに投げる 117
ハンズオン • RasPi → SORACOM → Azure 118
1. Azureへの登録 • https://azure.microsoft.com/ja-jp/ • 「無料で始める」をクリック • 指示に従ってアカウント作成 119
2. Event Hubの作成 • 左の＋ボタン • 「モノのインターネット」の「EventHub」のcreate • 名前：seccamp2017-チーム番号 • リソースグループ：新規作成：seccamp2017 • 場所：東日本 • 右上の🔔通知欄で、終わるのを末 120
2. Event Hubの作成 • 「＋イベントハブ」をクリック • 名前：input • 「作成」 • 終わるのをまつ 121
送信用キーの作成 • 左の共有アクセスポリシーをクリック • ポリシー名：Send • Claim:送信のみ • 作成 • 完了を待って、できた「Send」をクリック • 「主キー」の内容を、仲山あてに連絡 122
受信用キーの作成 • 左の共有アクセスポリシーをクリック • ポリシー名：Receive • Claim:全部チェックを入れる • 作成 • 完了を待って、できた「Receive」をクリック • 「主キー」の内容をメモを取る 123
3. Stream Analytics • 左の＋をクリック • IoTからStream Analytics job • ジョブ名：analytics • リソースグループ：さっき指定したグループ名 • 完成待ち 124
3. Stream Analytics • 左の「入力」を開いて上の「追加」 • エイリアス：input • ソースタイプ：データストリーム • ソース：イベントハブ • インポートオプション：手動で行う • 名前空間：seccamp2017-チーム番号 • 名前：input • ポリシー名：Receive • ポリシーキー：さっきメモしたキー 125
3. Stream Analytics • 左の「出力」を開いて上の「追加」 • エイリアス：output • シンク：Power BI • 先に、下の「サインアップ」をクリックして指示に従い有効化 • 終わったら「承認する」 • データセットめい：seccamp • テーブル名：seccamp • 作成 126
• 「クエリ」 • 以下を入力 SELECT input.payloads.pref AS pref, System.Timestamp AS WindowEnd, COUNT(*) AS Count FROM [input] TIMESTAMP BY DATEADD(millisecond, timestamp, '1970-01-01T00:00:00Z') GROUP BY TUMBLINGWINDOW(minute, 1), input.payloads.pref 127
• 概要タブに戻って、上の「開始」 • しばらくまって、PowerBIを開く • https://app.powerbi.com/ 128
ポイント • 認証情報をデバイスに持たせない • 自分で可能な限りコードを書かない • 分析など厄介な部分はクラウドに任せる 129
まとめ • クラウド時代のWebシステムについて • サーバ設計、構築、運用技術の基礎 • 「クラウドを使う」とはどういうことか • サービスの無停止とスケーラビリティを実現する設計 • クラウドのさらなる活用 • 演習 130
最後に • 特にこの10年のインフラ業界は動きが早いです • クラウドが登場して（まだ）10年間 • 前提が変わり、ベストプラクティスが入れ替わる • 個人的には、 ・この10年で物理サーバからクラウド上の仮想サーバに ・今後10年でサーバという枠組みから解放 と予想しています • ツールレベルの盛衰は、一々取り上げるのも切りが無い • 動きが早い＝面白い！ 131
最後に • すぐに手を動かそう！ • 無料クーポン、無料枠を活用しよう（学生はより有利！） • 大きな機能もちょっとだけなら安くお試しできる！ • とにかくネタと機会を作って情報を発信しよう！ • 情報は活動する人の近くに集まる • ブログ等での情報発信 • 勉強会等での発表 • 同人誌等の制作、頒布 132