More Related Content Similar to IoT時代のセキュアなクラウドインフラ構築術 #seccamp (20) More from Masahiro NAKAYAMA (20) IoT時代のセキュアなクラウドインフラ構築術 #seccamp2. 講師プロフィール
• 仲山 昌宏
• 株式会社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
ソーシャルゲーム
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
↓
36. 「メリハリ」を付けよう
• Statelessサーバ 🐖🐓
• アプリケーションを動かすサーバ
• データを中に一切保存せず、コピーすれば動くレベル
• いつでも追加/削除しやすい状態を保つ
• Statefulサーバ 🐕🐈
• データベース、ログ
• 追加/削除がしづらいので死ぬ気で守る
• スペックアップや分散DBの利用でスケーラビリティ確保
36
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. 管理プロセス
42. Twelve-Factor App
I. コードベース
II. 依存関係
III. 設定
IV. バックエンドサービス
V. ビルド、リリース、実行
VI. プロセス
42
VII. ポートバインディング
VIII. 並行性
IX. 廃棄容易性
X. 開発/本番一致
XI. ログ
XII. 管理プロセス
44. クラウド時代のサーバ設計
• Statelessサーバ 🐖🐓
• アプリケーションを動かすサーバ
• データを中に一切保存せず、コピーすれば動くレベル
• いつでも追加/削除しやすい状態を保つ
• Statefulサーバ 🐕🐈
• データベース、ログ
• 追加/削除がしづらいので死ぬ気で守る
• スペックアップや分散DBの利用でスケーラビリティ確保
44
45. クラウド時代のサーバ設計
• Statelessサーバ 🐖🐓
• アプリケーションを動かすサーバ
• データを中に一切保存せず、コピーすれば動くレベル
• いつでも追加/削除しやすい状態を保つ
• Statefulサーバ 🐕🐈
• データベース、ログ
• 追加/削除がしづらいので死ぬ気で守る
• スペックアップや分散DBの利用でスケーラビリティ確保
45
47. クラウド時代のサーバ設計
• Statelessサーバ 🐖🐓
• アプリケーションを動かすサーバ
• データを中に一切保存せず、コピーすれば動くレベル
• いつでも追加/削除しやすい状態を保つ
• Statefulサーバ 🐕🐈
• データベース、ログ
• 追加/削除がしづらいので死ぬ気で守る
• スペックアップや分散DBの利用でスケーラビリティ確保
47
50. CVSS v2の基準
• 基本評価基準 (Base Metrics)
• 脆弱性そのものの特性
• 機密性、完全性、可用性への影響、
攻撃のしやすさ(ネットワーク経由の攻撃可否など)
• 現状評価基準 (Temporal Metrics)
• 今どれぐらいやばいか
• 環境評価基準 (Environmental Metrics)
• 二次被害の度合いとかその他の影響範囲
50
57. AWS Identity and Access Management
(IAM)
• アクセス権限を管理する仕組み
• AWSは元々は1アカウント=1認証情報(email/password)
• ユーザやグループを作成して、権限を細かく割り当て可能
• より抽象化した「ロール」への割り当てもできる
• アクセス元IPアドレスなども設定可能
57
81. サーバインフラのコード化
• 「Infrastructure as Code」
• サーバ構成をコード(具体的にはJSONやRubyベースの
DSLなど)で実装し、それをもとにAPIをたたいて展開
• プログラミング的手法で継続的改善が可能
• Git等でのリビジョン管理、レビュー
• デプロイツールの活用
• 自動テスト
81
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
92. 1. フルマネージドなアプリケーション実行環境
• いわゆる「FaaS(Function as a Service)」
• 「関数」と呼ばれる小さなコードを動かすマネージドサービス
• 基本的にはコンテナベースでコードを動かす
• 自動でスケール
• 他のサービスから呼び出されて動く
• APIゲートウェイ(同期)
• イベントストリーム、ストレージ等からのトリガー(非同期)
• 各社「サーバーレス」の中心人物
AWS Lambda、Azure Functions
Google Cloud Functions、Bluemix OpenWhisk
95. 2. コンポーネントを「のり付け」するアーキテクチャ
• 高機能なクラウド上のコンポーネントの活用
• Functional SaaS(Service as as Service)
あるいはBaaS(Backend as a Service)
• コンポーネント自身が高機能化し、様々な「イベント」を生成
• イベントからFaaSを呼び出して連携
• フロント側のネイティブアプリ化/SPA化の波
• アプリから直接データストア等にアクセスできる
• 「ガチャ」のようなブラックボックスだけクラウド側に実装を持つ
• アプリの一部としてクラウドとメッセージング連携
96. 2. コンポーネントを「のり付け」するアーキテクチャ
• クラウド時代の「制御の反転」
• アプリケーションサーバが各コンポーネントを呼び出すのではなく、
各コンポーネントを小さな関数が接続する
• システムアーキテクチャの設計手法の変化
• マイクロサービス化、コレオグラフィ化の流れの一部
• 背景
• 高水準なクラウド上のコンポーネントの登場
• 様々な「イベントトリガ」の整備
• ID基盤のうえでコンポーネント側だけで細かいアクセス認可
• そもそも「餅は餅屋」、自分で作らなくて良い部分が増えている。
100. リアクティブシステム
• メッセージ駆動(手段)
• システム間をキューで非同期に接続する
• 複数のワーカプロセスがキューから取ってきて処理
• 弾力性(要件2)
• メッセージが増えてきたらワーカプロセスを増やせばよい
• 横並びのワーカプロセスに相互依存はないので気軽にスケールアウト・イン
• 耐障害性(要件1)
• コンポーネントで異常が起きたら自爆して、別のワーカが実行
• ずっとおかしいメッセージはDead letter queueに積み替えて例外処理
• 即応性(目的)
• 様々な状況に強いシステムが構築できる
109. IoTとクラウドネイティブ
• そもそもIoTってなんだっけ
• Internet of Things:モノのインターネット
• 機器や通信技術が安価になったので、何でもつなごう!
• つないでデータを集めたらなにかできないか
• 集めたデータを分析した結果が役に立たないか
• その結果をもとに、様々な機器を制御できないか
• 夢は無限に!
• 要するにそれただのインターネットの順調な発展だよね
109
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
120. 2. Event Hubの作成
• 左の+ボタン
• 「モノのインターネット」の「EventHub」のcreate
• 名前:seccamp2017-チーム番号
• リソースグループ:新規作成:seccamp2017
• 場所:東日本
• 右上の🔔通知欄で、終わるのを末
120
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