AWS Summit 2017_2017-06-01

2017/06/01 は以下に参加

  • マイクロソフトアーキテクチャの最適化
  • AWSのEdgeサービス入門
  • AWS Shield とAWS Lambda@Edge で構築するセキュアで柔軟性の高いアプリケーション
  • AWSのNoSQL入門
  • AWSで実現するセキュリティオートメーション
  • Amazon EC2 Systems Managerによるハイブリッド環境の管理

以下，とてつもなく読みづらいので，時間あったら整形

マイクロソフトアーキテクチャの最適化

12:00-

前提と目標

前提条件

  • Active Direcotry / SQL Serverなどマイクロソフトアーキテクチャの設計・構築に関する知識

セッションのゴール

  • マイクロソフトアーキテクチャをAWS情に展開するための最適な設計
  • AWSのマネージドサービスを利用するメリットについて

リージョンとAZ

  • リージョン=複数のAZ
  • AZ=データセンタ
    複数のAZを用いることで、耐障害性を高めることができる

EC2

インスタンス : 仮想コンピューティング, 1h単位の従量課金

WindowsワークロードのためのAWS

  • DevOps: AWS Elastic Beanstalk, CodeDeploy, CloudFormation

マイクロソフトアーキテクチャ例

VPC内に複数AZ

Remote Desktop Gateway

  • VPN接続なしにセキュアで暗号化された接続を確立
  • AZ障害時には他のAZにフェールオーバしたリソースにアクセス可能

AWS Identify and Access Management(IAM)

AWSコンソールへのフェデレーション

  • ADFSとAWSを連携できる
  • SAML2.0

AWS CloudFormation

  • EC2やELBといったAWSリソースの環境構築を設定ファイルを基に自動化できるサービス
  • テンプレートを自由に作成できるため、自分好みのシステム構成を自動的に構築できる

CloudFormation

テンプレート(JSON) → CloudFromation(FW) → スタック(AWSサービスの設定)

CloudFormation Designer

  • テンプレート内のリソースを仮想化
  • DDで対応可能

クイックスタートリファレンス

acitve Directory
SQL Server
Sharepoint Server
Exchenge Server

Active Direcotry on AWS

  • デスクトップや社内アプリケーションへのシングル・サインオン
  • アプリケーションやリソースへのアクセス管理
  • グループポリシーによるコンピュータのポリシー管理

クラウドワークロードのためのActive Directory ドメインサービス

シナリオ1 新規のADDSをAWSに展開

EC2にAD DSを新しくする場合は、
AZ-a – Private Subnet – DC/GC/DNS x1
AZ-c – Private Subnet – DC/GC/DNS x1
一方に機能をまとめないと、AZ障害時に死ぬ

バックアップ

Volume Shadow Copy サービス -> AD サービスへの起動中にバックアップを取ることが可能
バックアップツールも利用可能

リストア

  • DCのシステム全体のスナップショットを取得しないこと
    • USNロールバックを誘発する
    • ロールバックが発生したDCはドメイン環境から隔離され複製パートナーとみなされない
  • ディレクトリサービス復元モード(DSRM)を利用する
    • DCをDSRMでブートし、権限のあるリストアを実行

シナリオ2 オンプレミスのADDSをAWSへ

  • シナリオ1に加えて、VPN or Direct Connectして、オンプレ(DC)と連携

サイトのトポロジ

  • AWSではアベイラビリティゾーンをサイトとみなす
  • サイト内のPCやメンバーサーバーは同じサイトにあるDCに優先的にリクエストを投げる
  • サイト間レプリケーション

シナリオ3 AD DSをAWS Directory Service でAWS

  • EC2 ではなく、 AWS Directory Serviceを利用
  • Microsoft AD
    • フルマネージドのディレクトリサービス
      AZ-a – private Subnet – AWS Directory Service
      AZ-c – private Subnet – AWS Directory Service
      オンプレミスとは”信頼関係”を結ぶ

Active Directory フェデレーションサービス

  • セキュリティで保護されたID連携とWebシングルサインオンを提供

ADFS リファレンスアーキテクチャ

SQL Server on AWS

Amazon RDS for SQL Server

  • ビジネスバリューのタスク
  • ハイレベルのチューニングタスク
  • スキーマの最適化
  • 自動バックアップ
  • Database Expart が自社にいない場合

SQL Server on Amazon EC2

  • フルコントロールが必要
  • AlawaysOn 可用性グループ

    SQL Server on EC2

  • ライセンスのオプション
    • SQLserver込のAMI
    • Windows AMI にSQLServer(BYOL)

SQLServerの高可用性と災害対策

  • 複数のAZ利用
    • Enterprise Edition : AlwaysOn 可用性グループ
    • Standard Edtiion : サードパーティのストレージレプリケーション

自動フェイルオーバーのシナリオ

Muti-Region AlwaysOn 可用性グループ

Amazon RDS for SQL Server

  • AD との統合
  • 自動フェイルオーバー
  • 自動バックアップ

SQLServerのネイティブバックアップと復元

  • SQLServerのネイティブバックアップを保管し、S３

ローカルタイムゾーン対応

Multi-AZ SQL Server on Amazon RDS

  • マネージドサービスで実現可能

AWSのEdgeサービス入門

13:00-

想定と目的

想定するオーディエンス:

  • Webサイトの高速化やセキュリティに興味がある

目的:

  • Edgeサービスとは何か、概要とメリット
  • どのようなシステムに活用できるか

AWSのEdgeサービス

  • AWSのエッジロケーションから提供されるサービス
  • ユーザーが最初にアクセスするサービスをユーザーに近い場所から提供
    • DNS,CDN,WAF,DDoS対策

エッジロケーション

  • ユーザーに少ない待ち時間でサービスを提供するためグローバルに多くのエッジロケーションを配置

Webアクセスの仕組み

  1. ブラウザからURLを指定してアクセス要求、
  2. 名前解決を行ない、
  3. インターネット経由でWebサーバに接続し、
  4. コンテンツを取得、ブラウザでレンダリングして表示

インターネットの仕組み

  • ネットワークのネットワーク
    • 品質は常に一定でない
    • 距離の離れた通信は遅延の影響を受けやすい
  • 誰からでもアクセス可能
    • 誰からでも攻撃される可能性がある
    • アプリ脆弱性をついた攻撃、DDoS攻撃も多い

レスポンスの遅延、不安定なレスポンス

  • ネットワーク遅延は、距離に依存
  • コンテンツの元サーバーが遠いと、応答に時間がかかる
  • 応答時間の多くがネットワーク転送の待ち時間を占める場合も

大量アクセスへの対応

  • 大量のアクセスを捌くためには、不要なトラフィックをOriginに到達させない効率的な仕組みが必要
  • Webコンテンツにはあまり変化しない静的なデータが多く含まれる
  • ネットワーク帯域、サーバーリソースの無駄な消費

アプリケーションのセキュリティ対策

  • 社会的信用の失墜、サイト閉鎖による機会損失などを防ぐ
    • Webアプリケーションへの攻撃に対する対策が必要

DDoS攻撃の対策

AWSのEdgeサービスによる解決

CloudFront

  • 大容量キャパシティを持つ地理的に分散したサーバー群(エッジ)からコンテンツをキャッシュしたり代理配信するサービス
    • 配信を高速化
    • Originの負荷をオフロード

WAF

  • アプリケーションレベルでパケットを解析
  • 不正なアクセスを遮断し、正しいアクセスのみを許可する

Shield

  • Amazonのノウハウを詰め込んだDDoS攻撃を緩和するサービス
  • デフォルトで有効になっており無料で利用できる

CloudFront

  • 高性能な分散配置
  • 高いパフォーマンス
  • キャパシティアクセスからの解法
  • ビルドインのセキュリティ機能
  • 設定が容易で即時利用可能
  • 充実したレポーティング
  • 完全従量課金

機能

  • 動的コンテンツの配信
  • 暗号化通信
  • プライベートコンテンツ提供(署名付きURL/Cookie)
  • GZIP圧縮
  • アクセス元地域の制限
  • エラーベージの配信
  • IPv6 サポート(Originは対応しなくても良い)
  • HTTP/2 サポート(Originは対応しなくても良い)

AWS WAF

  • お客様の要望に応じてAWSが実現したマネージドWAFサービス

WAFを使う理由

ファイヤウォールやIPS/IDSで保護できないアプリへの攻撃や難読化された攻撃から保護するためにWAFを利用

  • SQLインジェクション、クロスサイトスクリプティング

リクエストの判定条件

  • クロスサイトスクリプティング
  • IPアドレス
  • サイズ制限
  • SQLインジェクション

WAF ACLを動的に更新して制御可能

  • バッドリクエストをよこすIPアドレスをブロック
    • エラーリクエスト数を記録し、エラーが一定数を越えたIPアドレスからのリクエストをブロックするようにWAF ACLを更新

AWS Shield とAWS Lambda@Edge で構築するセキュアで柔軟性の高いアプリケーション

14:00-

デザイン上の考慮点

  • セキュリティ
  • 可用性
  • 性能
  • 通知とモニタリング

AWSの活用

  • 柔軟性を失わずにアプリケーション構築
    • 高いセキュリティ
    • 高い可用性
    • 拡張性の高い

CloduFrontで配信する静的コンテンツ

  • エンタープライズ級のCDN
    • 高い可用性
    • アプリケーション高速化
    • AWS連携
    • 費用効果

動的コンテンツのための復旧能力

  • ビジネスロジック
  • 0秒または低いTTL
  • 高いセキュリティ

Route53 – CloudFront – ElasticLoadBalancer

  • エンドユーザの近くでTLSの終端
  • セキュアの全二重通信のコネクション
  • EdgeとELB間のコネクションの最適化
  • 短い時間のキャッシュでもリクエスト急増時の耐性を大幅に増加

パーソナライズされたコンテンツ

  • すべてのエンドユーザにカスタマイズされたコンテンツ
  • 拡張性が重要
  • 遅延の低さが重要

AWS Lambdaの利点

  • サーバ管理が不要
  • 継続的スケーリング
  • 料金

Lambda@Edge

  • AwsのエッジロケーションでNode.js

ビジターの検証

  • Botの処理
  • 有効なセッションを確認
  • 認証とアクセス管理
    X回の記事を読んだあとは、有料を案内する
  • レスポンスの生成
  • A/Bテスト
    • ユーザーごとに表示されるコンテンツのバージョンをコイントスで決める
    • Cookieで同じコンテンツになるように
  • HTTS
  • コンテンツのカスタマイズ
    • ユーザーの属性を基に配信するコンテンツを選択
    • クライアントのデバイスの属性

エッジでコンテンツのパーソナライズ

  • Route53 – CloudFront – Elastic Load balancer

キャッシュ不可なAPI

  • Route 53 – (CloudFront, API Gateway, Lambda@Edge) – Lambda, ELB

セキュリティはShield

  • DDoS
    • HTTP フラッド
  • アプリケーション攻撃
    • SQLインジェクション
  • 不正なボット
    • クローラ

DDoS古い対策

  • DDoS攻撃が来たらDDoSスクライビングセンターを起動して、動作させる
  • 緩和策の有効化まで時間がかかる
  • 常時作動でないため、
  • インラインでないため、津城ユーザーに影響

Edgeの防御

  • CloduFront
  • AWS Shield
    • ネットワーク層
    • アプリケーション層
  • WAF
    • アプリケーションロジック

Shield

  • ALB,CLB,CF,Route53
  • AWSサービスと連携/常時稼働の検知と緩和/経済的/柔軟性
  • StandardProtection, AdvancedProtection(有償)

AWS WAF

  • 柔軟なルール定義
    • 素早いインシデント対応
    • 1分以内に緩和策を提供
  • 事前設定された保護
    • SQLインジェクション, XSS, IPレピュテーションリスト
  • 高度なセキュリティの自動化
    • サーバログからLambda経由でWAF更新

AWSのNoSQL入門

15:00 –

目的

  • NoSQLを用いて可用性の高いシステム
  • NoSQLの主要なユースケース

NoSQLとは

  • 従来のRDBMSでは解決できない課題を解決するためのDBの総称
  • RDBMS
    • 正規化/リレーショナル
  • NoSQL
    • 非正規化/階層化
    • 高速なパフォーマンス
    • 高いスケーラビリティ
    • ユースケースに応じた様々なDB形式
    • トランザクション処理は苦手
    • クラスタの運用負荷

NoSQLの指向

  • キーバリューストア / redis
    • 超高速なパフォーマンス
    • RDBMSに比べ読み書きが高速
  • カラム指向 / hbase
    • カラム指向のデータ構造
    • ログなど大量データ解析向き
    • RDBMSに比べ書き込みが高速
  • ドキュメント指向 / mongoDB
    • jSONやXMLなどの不定形なデータ構造に対応
    • 複雑なデータモデリングを容易に実現可能
  • グラフ指向 / titanDB
    • データ間を相互に結びつけてデータ同士の関係をグラフで表わす
    • 複雑な関係性を表わすのを得意とする
      • SNSのフレンドの関連性

NoSQLのメリット

  • 低レイテンシ、高スループット、シンプルなAPI
  • WEBセッション管理
  • pubsubモデル,イベント処理
  • JSON形式データの格納

NoSQLマネージドサービス

  • DynamoDB(NoSQL)
    • キーバリューストア
    • ドキュメント指向
    • グラフ指向
  • RDS(RDB)
  • ElastiCache(インメモリキャッシュ)
    • キーバリューストア
  • Redshift(データウェアハウス)

ElasticCache

  • キャッシュをマネージドで提供するNoSQLサービス
    • Redis, memcached エンジン
    • 構築/運用の自動化
    • アプリケーションキャッシュサーバ
    • Redisの機能をマネージドに使う
    • バックアップ
    • 監視
    • 自動検知/復旧

KVSエンジンの選択

  • ElastiCacheの2つのエンジンはどちらもKVS
Memcached
  • マルチスレッド
  • 非永続化
  • 単純なデータタイプ
  • メンテナンスが楽
  • 垂直分散が楽
Redis
  • シングルスレッド
  • 永続化
  • 多数のデータタイプ
  • Atomic処理
  • pub/subメッセージング
  • リードレプリケーション/フェイルオーバー

運用の改善

  • フェイルオーバ、バックアップ、スケーリング

フェイルオーバ

  • レプリケーション機能を使ったフェイルオーバ(Redis)
  • スナップショットバックアップが可能
    • スケジュール/世代数が設定可能

ElasticCache

  • 複雑な計算が必要とされるケース

DynamoDB

  • フルーマネージドで高信頼性
  • 単一障害点(SPOF)がない
  • データは3AZに保存される
  • プロビジョンドスループット
    • ユーザーの需要に合わせてキャパシティをスケール
  • ストレージ容量制限なし
  • データの柔軟性
    • パーティションキーとソートキーでしか検索できない
  • DynamoDB : TTL
    • 一定期間が好きたアイテムを削除
  • VPC DynaoDB
  • DynamoDB Acceralator DAX
    • キャッシュクラスタ

AWSで実現するセキュリティオートメーション

16:00 –

ポイント

  • オートメーションは戦略策定の礎
  • セキュリティ・オートメーションを前提に設計されたAWSサービス
  • セキュリティ戦略基盤となるAWSクラウド環境

自動化の価値

  • 効率化
  • 戦略革新
    – 「やること」と「やらないこと」を決められる

オートメーションがもたらすもの

  • データ集約
  • 可視化と効果測定
  • 分析による意思決定

セキュリティオートメーション

  • 何を自動化するべきか
    • 対策主体
    • 人による、組織による、技術による対策
    • 対策対象
      • サーバー、ネットワーク、クライアント対策
    • 対策場所
      • 入口、内部、出口対策
  • 適応型セキュリティアーキテクチャ
    • 防御 → 検知 → 対応 → 予測(サイクルを回す)
      • 標的型攻撃の台頭で100%防御は不可能
      • 高い検知精度/イベントを相関分析したインシデント特定/重要なインシデントの判別・優先順位つけ
      • 一次対応の早さ・損害額の最小化/事後調査を意識したログ設計/恒久的な対応は仕組み化して事故の再発防止
      • 異常に気づくための定常状態の把握/次の防御策を選択するためのリスク分析

IPブラックリストをAWS WAFに自動反映

スケールアウトによる問題の抑制と通知

  • 非ブラックIPからの大量トラフィック
  • スケールアウトによる自動トラフィック分散
  • スケーリング通知
  • Amazon Lambdaで任意アクションの実行

端末自動隔離とバックアップ

  • Inspectorでセキュリティ評価の実行
  • Inspectorで脆弱性診断
  • 診断結果の通知
  • Lambda NACL/SGのポートブロックによる端末隔離
  • VPC FLow Logsに表示/ブロックログ
  • バックアップ取得(事後調査の可能性)
  • バックアップログ保存(CloudTrail)

CroudTrailの監査対象

セキュリティ・ダッシュボード

Domain Generation Algorithms

リスクベースのセキュリティ戦略

リスクに基づいたセキュリティ対策の意思決定

  • リスク分析
    • 脅威分析
      • 異常検知
      • ヒューリスティック分析
      • 脅威インテリジェンス
    • 脆弱性分析
      • 脆弱性スキャン
      • ベンチマーク評価
      • パッチ管理
    • 情報資産分析
      • ユーザー振る舞い分析
      • 情報漏えい防止
      • 機械学習

Amazon EC2 Systems Managerによるハイブリッド環境の管理

17:00-

前提条件

  • EC2/S3/VPC/IAM
  • WIndows/Linux
  • AWS CLI

ゴール

  • EC2 Systems manager の概要と使い方
  • 代表的なシナリオ

課題

  • 從來のツールによるクラウドとハイブリッド環境の管理は複雑で高コスト

Amazon EC2 Systems Manager

  • Amazon EC2またはオンプレミスで実行されるWindows/Linuxに対して
    • システムの自動構成と継続的な管理を可能にする一連のサービス

デプロイ、構成および管理

  • RunCommand
  • State Manager

共有コンポーネント

  • Maintenance Windows
  • Parameter Store

トラッキングとアップデート

  • Inventory
  • Patch Manager
  • Automation

利用イメージ

  • Amazon EC2, ハイブリッド環境のシステム管理
    • RUnCOmmnaのみでコマンド実行、管理
    • 情報はInventory,Patch Manager で管理
  • 認証情報の保存、取り出し
    • Parameter Store を使ってバッチ処理

EC2 Systems Managerの前提条件

  • OS制限あり
  • インターネットへのアクセスができること
    • SSM Agentが各種APIへアクセスするため
    • VPCにNAT-Gatewayを設置していても良い

Run Command

  • 管理作業をリモートから実行
    • リモートから任意のコマンド事項が可能
    • JSONベースのドキュメントでコマンド、タスクを定義
    • 実行結果はS3,実行状態に合わせてSNSを使って通知
    • SSH, RDPの接続ポートを閉じることでセキュアに運用

SSM Agent

  • 管理対象に常駐し、各種サービスからの要求を実行
  • Amazon Linux は別途インストールが必要

State Manager

  • OSとアプリケーションの設定を定義、状態を維持する
    • 事前に定義しておいた状態にOSを設定
    • JSONベースのドキュメントを使用してポリシーを定義する
    • 構成を適用するEC2, オンプレサーバを個別、タグで管理

利用シナリオ

  • エンタープライズシステムのパッチ管理の課題
    • うんざりするくりかえしによる時間の浪費
    • 既存のソリューションではスケーラビリティが不安
    • エンタープライズのパッチ管理はマニュアルかつ複雑
    • エラーによるダウンタイムとセキュリティ問題

Patch Manager

  • ベースラインを定義してWindowsのパッチを適用
    • 許可するパッチの定義(Patch Baseline)
    • インスタンス群にパッチをスケジュール(Maintenance Window)
    • パッチを適用
    • 結果を確認(Patch Compliance)

利用シナリオ

  • AMIの作成
    • パッチ適用、ハードニング、アプリケーションの更新などによるトリガー
    • 終わりのないプロセス
    • 時間の消費、特にビルド失敗時
    • ビルドサービスを管理すつための手間がかかる

Automation

  • シンプルなワークフローを遣って一般的なタスクを自動化
    • AMIの作成と管理に最適
    • Automationドキュメントの作成
      • 予め定義されたAutomationドキュメントを利用可能
    • Automationの実行
    • モニタリング
      • CloudWatch Eventsを設定

まとめ

  • ハイブリッド環境でシステムの自動構成と継続的な管理を実現
  • 利用料は無料