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