Skip to content

Instantly share code, notes, and snippets.

@2no

2no/aws-summit-tokyo-2016.md

Last active June 4, 2016 08:21
Show Gist options
  • Save 2no/be374370902eb6624419a55a2235c621 to your computer and use it in GitHub Desktop.
Save 2no/be374370902eb6624419a55a2235c621 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
aws-summit-tokyo-2016.md

AWS Summit Tokyo 2016 2016/06/02

Security by Design 〜AWS で実現する機能的で信頼性の高いガバナンスモデル〜

高田智己

  • セキュリティと監査における現在の課題と解決へのアプローチ
  • Security By Design の紹介
  • AWS Enterprixse Accelerator Quick Start - Compliance

セキュリティと監査における現在の課題と解決へのアプローチ

システムの複雑性の増加がリスクとセキュリティの管理及び統制の証明を困難にしている。

セキュリティ対策における柔軟性と複雑性の現実

規制要件は何か？
スコープに含まれるもの、含まれないものは何か？
どのように標準に準拠していることを検証するか？

  • セキュリティ・統制環境の一貫性、品質の向上
  • 監査作業や統制実施の自動化
  • 透明性・可視性の改善

Software Defined Infrastructure による解決

的確なセキュリティポリシーを反映したアーキテクチャを実装・維持し、要求される統制をクラウドの機能によって可能なかぎり自動化

Security By Design の紹介

https://aws.amazon.com/jp/compliance/

基になっている考え方
Quality by Design - QbD

AWS アカウントの設計の規格化、セキュリティ制御の自動化、及び監査の合理化のためのセキュリティ保証アプローチ

アプローチ

  1. お客さまの要件を把握する
  • セキュリティポリシーの確認
  • AWS の IT 環境内で実施したいセキュリティルールの特定
  • AWS 環境内で実施するコントロールの文書化

セキュリティのベンチマークというのがある。

  1. お客さまの要件と実装に合致するセキュアな環境を構築する
  • AWS 環境内の設定値の定義（暗号化、アクセス管理、ログなど）
  • セキュリティコントロールの標準化とアーキテクチャーの作成
  • 自動化のために AWS CloudFormation によるテンプレート化

Amazon CloudFormation
テンプレートを元に、EC2 や ELB といった AWS リソースの環境構築を自動化

  1. テンプレートの使用を要求する
  • サービスカタログを有効にしてテンプレートを使用するように要求
  • 作成済みのセキュアな環境を使用するように制限

AWS Service Catalog

  1. 検証アクティビティを実行する AWS CloudTrail
    操作ログなどを取得するサービス

AWS Config
変更履歴、構成履歴

Amazon CloudWatch
各種リソース監視

SbD の狙い

お客さまのガバナンスポリシーを技術的にスクリプト化する など

AWS Enterprise Accelerator Quick Start の紹介

https://aws.amazon.com/jp/quickstart/ 続々コンプライアンスに対応していっている

様々なテンプレートが用意されている。

例えば、
セキュアな Amazon S3 の設定
セキュアな AWS CloudTrail の設定
AWS CloudWatch による監視の設定
Config Rules の活用

まとめると、

  • SbD: お客さまのガバナンスポリシーのコード化
  • 効果: 運用及び管理統制の信頼できる実装と強制
  • AWS の利点: SbD の実現を支える API とサービス群の提供

エッジサービスのセキュリティ戦略と有効利用法

概要: 何故セキュリティが重要か

  • 顧客の信頼
  • 企業コンプライアンス
  • データ・プライバシー
  • 保護

殆どの攻撃はインフラへの攻撃
AWS で守れる

  • メンテナンス用の踏み台サーバ
  • 二要素認証
  • 暗号化
  • 隔離をより有効にするための分離
  • テストや指標の監視

AWS インフラの DDoS 緩和

備え付きの保護機能

  • Edge Services (CloudFront/Route53) は、レイヤー3, 4 の攻撃を防御
  • 常にインラインで稼働
  • コモディティ・ハードに利用
  • ターゲット型とヒューリスティック型緩和

利点

  • 低いMTTR
  • 遅延をマイクロ秒単位に抑える

DDos 攻撃は、AWS DDoS 緩和の対応されてインラインで通信される

DDoS 緩和のテクニック

基本的な確認

  • IP チェックサム
  • 有効な TCP フラグ
  • UDP ペイロードの長さ
  • DNS リクエストの認証

トラフィックの優先順位付け

  • ソース IP
  • ソース ASN
  • トラフィック量
  • 認証済みの送信元

Distribution のシグネチャー

  • 個別の Distribution を区別する

高度なトラフィックエンジニアリング

  • 自動的に攻撃のトラフィックを検知
  • 攻撃と通常トラフィックのルーティングを別ける

AWS API Gateway

CloudFront は、自動的に転送中のデータを保護する

  • HTTPS で配信
  • HTTPS でユーザは CloudFront を認証する
  • オリジンを認証

高度な SSL/TLS 機能

セキュリティの向上
SSL パフォーマンス

導入事例

MapBox

  • ハーフブリッジ型 TLS 終端
    • オリジンまでのコネクションをすべて HTTPS 化
    • CloudFront 設定の [Match Viewer] を選択
  • フルブリッジ型 TLS 終端

署名付き URL

  • URL のクエリストリングに署名を追加
  • URL が署名の箇所で変わる

署名付き Cookies

  • Cookie に署名を追加
  • URL は変わらない

AWS WAF

WAF で Bot をブロック
Lambda と連携

AWS CloudTrail

  • セキュリティ分析
  • リソースの変更管理
  • コンプライアンスの監査

ハッカーは CloudFront を迂回して直接オリジンにアクセスできる

Amazon S3

Origin Access Identify (OAI)

  • Amazon S3 バケットへの直接のアクセスを防ぐ
  • すべてのお客さまにとってパフォーマンス面での利点がある

カスタム Origin

IP アドレスのブロック

オリジンのベスト・プラクティス

  1. Match Viewer Origin Protocol ポリシー
  2. セキュリティグループや Shared Secret を使ってアクセスを制限する
  3. SHA256 の証明書を使う
  4. ELB で独自証明書を利用する
  5. ELB 事前定義ポリシーを利用する
  6. HSTS ヘッダーを送る

現在の設定内容を検証する方法

https://www.ssllabs.com

AWS Summit Tokyo 2016 2016/06/03

Docker だらけの FRESH! な動画配信プラットフォーム

Akinori Yamada

  • FRESH! とは
  • 配信プラットフォームとして目指した価値
  • MIcroservices
  • FRESH! と docker
  • docker と Amazon EC2 container Services でのサービス構築パターン
  • Blue Green Deployment
  • Docker を検討されている皆様へ

配信プラットフォームとして目指した価値

可用性とスケーラビリティ

  • サービス全停止でのメンテナンスを極力しない
  • デプロイに夜ダウンタイムを作らない
  • 仮に一部分が障害を起こしても、動画配信・視聴というユーザーにとっての絶対的主目的は守りぬく

スケーラビリティ

  • 人気番組・特番次のキャパシティっ不足、視聴品質劣化を起こさない

  • 容易にスケール出来るシステム構成であること

  • Microservices

  • Docker + Immutable Infrastructure

  • Blue Green Deployment

Microservices

  • システムを解決すべきドメイン領域によって切り分けるパターン
  • FRESH! の例 (一部)
    • User API
    • Broadcast
    • Chat
    • Timeline
    • Tracking

Microservices と可用性

  • Amazon RDS の再起動や、時間の掛かるスキーマチェンジの運用課題

  • Service 別に DB を持つため、システム全体を止めてのメンテナンスを回避できる

  • 呼び出し側の Service でのケアを用意しておく

    • (例) Disable XXXX Service Mode
    • (例) 〜の機能は現在利用できません。

    Docker 利用のモチベーション

    • Immurable Infrastructure との親和性、ポータビリティの高さ
    • イメージ作ってしまえば、コンテナ上げるだけ
    • Provisioning でインフラの面倒を続けるより、コンテナの面倒を見るほうが敷居が低いのでは？と言う仮説
    • コンテナを簡単に増やせる仕組みさえアレばスケール出来る

    FRESH! と Docker

    • Amazon EC2 Container Services の東京リージョンリリースから利用
    • ホスト OS は Ubuntu
    • Docker 1.10.3
    • ecs-agent 1.9.0
    • 軽量化を図るため、Alpine Linux

コンテナ化方針

  • 基本的にはデータストア以外はコンテナ化
    • インフラとアプリケーションがコンテナによってセットで扱うことが出来るメリットは大きい
  • ログはホストにボリュームマウントし、fluentd で Amazon S3 や Elasticserch で転送する
  • アプリケーションの設定や、ミドルウェアの設定は環境変数で設定

コンテナ化、結局何が美味しい？

  • 環境最問題からの脱却
    • A の環境では動くが、B の環境では動かない的なあるある問題
    • 環境再現のしやすさ
  • インフラのメンテコストの軽減
    • Provisioning ほとんど要らない (clout-init だけ)

  • 環境別の設定ファイルは Docker にはそぐわない
  • 環境変数変更だけで挙動を変えられてこそのポータビリティ
  • 環境変数ベース
    • アプリケーションの設定変更にビルド不要
    • 環境変数を変えてのデプロイで済む

Amazon ECS と設定管理

  • github.com/stormcat24/ecs-formation
  • docker-compose ライクの Amazon ECS クラスタ構成管理ツール
  • Blue Green Deployment もサポート

FRESH! が Docker 化しているもの

  • REST ALP (Go)
  • Job Worker (Go)
  • React (Node.js)
  • Chat (node.js)
  • 独自 Cron (Java)

..etc

クラスタを役割で分ける

  • 役割等で ECS Cluster を分ける方式

  • 分かり易い

  • FRESH ではこの方式

  • スケールが必要な役割のものは AutoScaling Group と併用

  • 役割で１つの Microservices

  • ECS クラスタ単位

Public な Service (第一段階)

  • Public に公開するものは Nginx を前段に
  • Nginx + API が Task
  • ELB からは各 Task の HTTP ポートにリクエストを振り分ける

Public な Service (第二段階)

  • この段階で実用的
  • ログは fluentd で転送
  • EC2 Slave 群を参照するために HAProxy を利用

HAProxy のコンテナ利用

  • 各 Task に HAProxy を入れてしまおう
  • essential 設定では HAProxy が落ちれば他コンテナも落ちる

Public な Web + API

React

assets の扱い

  • assets は Node コンテナに属する
  • assets 類は Nginx から直接配信したい
  • コンテナ館ボリュームマウント(volume_form)

Internal Service

  • Internal ELB 経由で、別の Service を利用
  • REST API ベース (gRPC の選択肢もある)

Job Worker

  • Enqueue/Dequeue 型の Job Worker
  • Amazon SQS
  • 重めの処理を担当
  • 定時ジョブは独自 Cron から Enqueue
  • Task 増やすだけでスケール

Wowza Streaming Engine

  • 動画配信サーバ
  • 配信は RTMP
  • 視聴は HLS (HTTP Live Streaming)
  • Amazon S3
  • Amazon CloudFront

基本的に Service 群の組み合わせ

運用・開発体制

  • サーバサイドx6 + インフラx1, Not Two Pizza Team
  • サービス：開発者 = N:N
  • 各サービス毎に主担当は居るが、他のメンバーも面倒が見れるようにしている
  • Microservices Map の様な俯瞰できるドキュメントの作成
    • 構成図や、ポート対応表
  • 現状、複雑性より可用性を優先している

今後の課題

  • HTTP2 対応
  • リソースの最適化
  • Circuit Breaker Pattern
  • Service 粒度の最適化
  • 多くの Microservices を運用するチーム・開発体制

Blue Green Deployment

  • 稼動系インフラにアプリケーションをデプロし直すのではなく、インフラ毎新しく構築して切り替えてしまう
  • 休憩等から新系統にロードバランサを切り替える

2Auto Scaling Group Pattern

  • Blue と Green の Auto Scaling Group を用紙

  • ELB を付け替える

  • デプロイの安心感

    • 致命的な状態を含んだ成果物が出ることを防止

  • *.amebafresh.tv -> *.abemafresh.tv の悲しみのドメイン変更

    • サービス名変更でドメイン変えることに
    • すべての Service をダウンタイムゼロで移行成功

  • 運用経験がない

  • 何となく感じがちな、得体のしれない怖さ

    • 本当にちゃんと動くの?
    • 地雷いっぱいあるんでしょ？

  • クラスタの管理方法

  • Docker ポータビリティは、そもそも環境を問わない実行環境を目指したもの

  • 既に開発環境で利用しているなら、本番でも動くよ

  • 地雷もだいぶ踏み尽くされてきた

開発環境のみの利用は勿体無い

ドワンゴが AWS でメディアストレージ基盤を開発してみた

http://qiita.com/namusyaka/items/e805d1098827a4bd6835

  • 画像ファイル
  • PDF ファイル
  • 音声ファイル
  • 動画ファイル

アップロード・変換処理を一手に引き受ける

ジョブ

DynamoDB を使って管理
すべての処理はこのジョブという概念をベースに行われる

Ruby 製 DynamoDB ORM dinamo
https://github.com/namusyaka/dinamo

メディアストレージ基盤が採用している OSS

Grape (API)
dinamo (ORM)
rabl (View)
shoryuken (SQS)
aws-sdk-ruby (All)

Lambda 以外は全て Ruby

Lambda を使い、メディアタイプにより処理を切り替える

SoR と IoT で SoE を実現する日立のサービスプラットフォーム

中村 輝雄

人により、IoT の考え方が異なる

IoT: Internet of Things
SoE: Systems of Engagement
SoI: systems of Intelligence
SoR: Systems of Record (従来型)
DevOps: Development+Operations

OT (Physical)
IoT (SoE)
IT (SoR)

IT + OT = IoT

IoT プラットフォーム「Lumada」

ビジネスと IT の融合、IoT など最新テクノロジーによる社会/事業の変革が急激に進展

テクノロジー

仮想通貨：ブロックチェーンの実証や研究活発化
人工知能：囲碁でトップ棋士と対戦し勝利

センチメント (市場心理) 分析システム (SoE)
株式売買システム (SoR)

つぶやき分析システム (SoE)
配車システム (SoR)

電車の遅延情報に関しては、JR さんなどは API を公開していないので、Twitter などのつぶやきから分析する

センサー情報 -> ビッグデータ解析:稼働分析システム (SoE) -> 保守管理システム (SoR) -> 建設機械

センサー情報 -> 走行・車両状態の解析:自動車モニタリングシステム (SoE) -> コールセンターシステム (SoR) -> 自動車

Application Layer (-> SaaS 含む)
IaaS Layer
Physical Layer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment