AWSの共有責任モデル（shared responsibility model）

AWSの共有責任モデル
（Shared Responsibility Model）

アマゾンデータサービスジャパン株式会社

© 2012 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.

自己紹介
• 片山暁雄
– アマゾンデータサービスジャパン
– 技術統括本部エンタープライズソリューション部
– 部長/ソリューションアーキテクト
• Twitter
– @c9katayama
– #ヤマン
• 好きなAWSサービス
– IAM(Identity and Access Management)
• 好きな第三者認証
– PCI-DSS

AWS クラウドデザインパターン
実装ガイド
• 設計ガイドに続く第二弾
• 実装手順を画面に沿って解説
– コンテンツ配信
– Eコマース
– キャンペーンサイト
• アカウント作成/基本操作も網羅
• ハンズオンにも最適！


Back Net Pattern Ondemand NAT Pattern WAF Proxy Pattern

Operational Firewall Pattern Functional Firewall Pattern


Agenda

1 AWSのセキュリティ方針
2 AWS側のセキュリティ
3 AWS利用者側のセキュリティ

5 Copyright ©2012 Amazon Web Services.Inc

AWSの
セキュリティ
方針

@aes256
6

ＡＷＳのセキュリティ方針

• AWSクラウドのセキュリティ
– セキュリティはAWSにおいて最優先されるべき事項
– セキュリティに対する継続的な投資
– セキュリティ専門部隊の設置

• 共有責任モデルの採用
– AWSと利用者の2者でセキュリティを確保

7

共有責任モデル

• OS • OSファイアウォール
• アプリケーション • ネットワーク設定
• セキュリティグループ • アカウント管理

• ファシリティ • ネットワークインフラ
• 物理セキュリティ • 仮想インフラ
• 物理インフラ

8

AWS側の
セキュリティ

9

AWSにおけるクラウドセキュリティ概要
認定 & 認証評価セキュリティ責任共有モデル

SOX法 Customer/SI Partner/ISV がゲストOS
ISO 27001 認定レベルのセキュリティを制御(パッチ運
用や運用管理含む)
PCI DSS Level I 認定
パスワード管理やロールベースのアクセ
HIPAA 準拠アーキテクチャス権管理を含むアプリケーションレベル
SOC 1/SSAE 16/ISAE 3402/SOC 2 のセキュリティ
FISMA Low ATO 侵入検知/回避システムを含むホストベ
 FISMA Moderate ATO 申請中ースのファイアウォール
 DIACAP MAC II Sensitive 申請中データの暗号化/複合化. ハードウェアセ
 FedRAMP キュリティモジュール
サービスヘルスダッシュボードアクセス権の分離

物理セキュリティ VMセキュリティネットワークセキュリティ
複数レベル、複数要素による制御されて Amazonアカウントへの多要素認証によセキュリティグループ設定によるインス
いるアクセス環境るアクセスタンス毎のファイアウォール設定が可能
管理され必要性に応じたAWS従業員によインスタンスの隔離トラフィックはプロトコル、サービスポ
るアクセス(必要最小限) • ハイパバイザレベルでの顧客にート、ソースIPによって制限できる (個
管理者層による管理者権限アクセスよるファイアウォールの制御別IPまたはindividual IP or Classless
隣にあるインスタンスへのアク Inter-Domain Routing (CIDR)ブロッ
管理ホストへの多要素認証で、管理され •
セスは許可されていないク).
必要性に応じたアクセス
仮想ディスクの管理レイヤがア Virtual Private Cloud (VPC) により、
全てのアクセスのログ収集、監視、そし •
カウントのオーナだけがストレ既存エンタープライズデータセンターと
てレビュー
ージ(EBS)にアクセスすること論理的に隔離された複数のAWSリソース
AWS管理者は顧客VMの中、アプリケーとの間にIPSec VPNでアクセス可能
ションとそのデータなどにはアクセスすを保証する
る権限をもたない APIコールの暗号化のためのエンドポイ
ントのSSLサポート

2012/11/15 update
10

• 物理セキュリティ

• ネットワークセキュリティ

• VMセキュリティ

• 管理者層による管理者権限アクセス

• 認定 & 認証評価


物理セキュリティ
• Amazonは数年間にわたり、大規模なデータセンターを
構築
• 重要な特性:
– 場所の秘匿
– 周囲の厳重な制御
– 物理アクセスの厳密なコントロール
– 2要素認証を2回以上でアクセス
• 完全管理された、必要性に基づくアクセス
• 全てのアクセスはロギングされ、チェックされる
• 職務の分離
– 物理アクセス可能な従業員は論理権限にアクセス不可

13

データセンター設置時のポリシー
• 各データセンターは物理的に隔離
• 洪水面を考慮
• 地盤が安定している場所
• 無停止電源（ＵＰＳ）、バックアップ電源、異なる電源供
給元の確保
• 冗長化されたTier-1ネットワークの接続


ストレージの破棄

• データ消去方法
– DoD 5220.22-M（米国国防総省方式）
• 3回の書き込みでの消去を実施
• 固定値→補数→乱数
– NIST 800-88（媒体サニタイズに関するガイドライン）
• 情報処分に対する体制、運営やライフサイクルに関するガイドライ
ン
• 情報処分に対しする組織的に取り組み
• 物理的に故障した場合は、消磁および破壊を実施して破棄していま
す。
• 参考：
http://www.ipa.go.jp/security/publications/nist/documents/S
P800-88_J.pdf


ネットワークセキュリティ
• DDoS (Distributed Denial of Service):
– 標準的な緩和技術を施行

• MITM (Man in the Middle):
– 全てのエンドポイントはSSLによって保護
– EC2のホストキーはブート毎に生成され更新

• IPスプーフィング:
– ホストOSレベルで不許可

• 許可されていないポートスキャン:
– AWSサービス利用規約違反に該当
– 検知され、停止され、ブロックされる
– インバウンドポートはデフォルトでブロックされているため、事実上無効

• パケット・スニッフィング:
– プロミスキャス・モードは不許可
17 – ハイパーバイザーレベルで制御

ネットワークトラフィックフローセキュリティ

• セキュリティグループ
• インバウンドのトラフィックはプロトコ
ル、ポート、セキュリティグループによ
り明示的に指定。
• VPCはアウトバウンドのフィルタも追加
する

• ネットワークACL:

Security Group

OS Firewall
Network ACL
• VPC はインバウンドとアウトバウン
ドのステートレスフィルタも追加す
る

• サブネット・ルーティングテー
ブル・ゲートウェイ：
• VPCで作成可能

• これらの機能を提供

18

多階層セキュリティアプローチの実例
Web Tier

Application Tier

Database Tier

80または443ポート
のみをインターネッ
ト側で受け付ける

エンジニアがAP層にssh
アクセスを行う

オンプレミスDBとの同期 Amazon EC2
Security Group
Firewall
その他のインターネット経由の
アクセスは全てデフォルトで拒否
19

Amazon EC2のインスタンス独立性

Customer 1 Customer 2 … Customer n

Hypervisor

Virtual Interfaces
Customer 1
Security Groups
Customer 2
Security Groups … Customer n
Security Groups

Firewall

Physical Interfaces

21

VMセキュリティ
• ハイパーバイザー（ホストOS）
– AWS管理者の拠点ホストからの個別のSSHキーによるログイン
– 全てのアクセスはロギングされ、監査されます
• Firewall
– AWS利用者設定に従い、トラフィックをコントロール
– 設定しない通信は不可

• ゲストOS（EC2インスタンス）
– 顧客による完全なコントロール (顧客がルート/管理者権限を保有)
– AWS管理者はログイン不可能
– 顧客が生成したいキーペアを使用

22

仮想メモリとローカルディスク
• AWSのディスク管理により、
あるインスタンスがその他
のインスタンスのデータを
読み取るのを防護

• ディスクは作成されるたび
にワイプされる Encrypted
File System

Encrypted
Swap File

• ディスクはAWS利用者が自
由にフォーマット可（暗号
化が可能）

23

管理者権限アクセス・変更管理

• AWSサービスに対する全ての変更は、社内システムで管
理されます
– 認証
– ロギング
– テスト
– 承認

• 職務の分離
– 物理アクセス可能な従業員は論理権限にアクセス不可

• 顧客に影響を与えないよう、影響範囲を確認しながら段
階的にデプロイされます

25

レポート、認定、第三者認証
• AWSは以下のような第三者認証を取得済み
– SSAE 16/ISAE 3402基準、SOC1レポート（旧SAS70)
– SOC2レポート
– ISO 27001 Certification
– PCI DSS Level 1 Service Provider
Certified
– FISMA moderate
– Sarbanes-Oxley (SOX)

• AWSにシステムをデプロイし、第三者認証を取得する
ことも可能
– HIPAA (医療関係)
– ASP・SaaS安全・信頼性に係る情報開示認定制度

27

SSAE16/ISAE3402 SOC1レポート

• AWSの内部統制に関する保証報告書

• AWSの各サービスにおけるセキュリティ、変更管理、
運用等の情報を保証報告書という形式でお客様に提供

• NDAベースでSOC1レポートをご提示可能

28

SOC 1 Type II – Control Objectives

• Control Objective 1: セキュリティ組織、体制
• Control Objective 2: 従業員の雇用ライフサイクル
• Control Objective 3: 論理的なセキュリティ
• Control Objective 4: 安全なデータの取り扱い
• Control Objective 5: 物理的なセキュリティ
• Control Objective 6: 環境的なセーフガード
• Control Objective 7: 変更管理
• Control Objective 8: データの完全性、可用性、冗長性
• Control Objective 9: インシデント管理


SOC2レポート
• 受託会社の財務報告に関連する内部統制以外の要望に
応えるための報告書

• Trustサービスの基準に従って客観的に評価
– セキュリティ
– 可用性
– 処理のインテグリティ
– 機密保持
– 個人情報の保護（プライバシー）

• AWSのセキュリティに関して透明性をもたらす内容
30

PCI DSS Level1 Service Provider
• PCI DSS 2.0 コンプライアンス準拠
• コアなインフラストラクチャとサービスをカバー
– EC2, EBS, S3, VPC, RDS, ELB, IAM
• 標準で、特に変更のない設定を使用して認定
• 認定セキュリティ評価機関(QSA)のタスクを利用
• AWSはビジネスでの利用が可能で、Qualified
Incident Response Assessors (QIRA)として設計
– フォレンジック調査をサポートする事が可能
• 全てのリージョンで認定
• アップデートはこちらをご覧ください。
– http://aws.amazon.com/security/pci-dss-level-1-compliance-faqs/

31

AWS側のセキュリティのまとめ
• セキュリティはトッププライオリティ事項

• AWS責任範囲は、物理論理問わず徹底し
た対策を実施

• 実施内容を裏付ける第三者認証も取得

• AWS利用者は、責任部分だけに作業を集
中できる

セキュリティに関する情報の提供


AWS Security Center
(http://aws.amazon.com/security/)

• セキュリティホワイトペーパー
• セキュリティとプライバシーの回答
• 半年に1度アップデート
• セキュリティ速報
• 顧客によるペネトレーションテストのポリシ
• セキュリティベストプラクティス
• AWS Identity & Access Management (AWS IAM)
• AWS Multi-Factor Authentication (AWS MFA)

34

CSA-Consensus Assesments Initiative Questionnaire-
• CSA Consensus Assessments Initiative
Questionnaire には、クラウド使用者およびクラウド
監査人がクラウドプロバイダに要求すると CSA が想
定している質問を記載。クラウドプロバイダの選択や
セキュリティの評価など、幅広い用途に使用可能。
• セキュリティ、統制、およびプロセスに関する一連の
質問にAWSは回答済み。

*CSAの詳細はhttp://aws.amazon.com/jp/security/ AWS リスクとコンプライアンスのホワイトペーパーを参照

36

金融機関向けAWS対応セキュリティリファレンス
• FISC安全対策基準（第8版）へのAWSの準拠状況を調査した資料を一
般公開
• SCSK、NRI(野村総合研究所)、ISID(電通国際情報サービス)3社が共
同で調査。AWSも調査に協力
• AWSと利用者で責任分担することで、FISC安対基準を満たせるとの
見解

37

AWS利用者側の
セキュリティ

38

責任共有モデル


• ファシリティ今までのセキュリティ
• ネットワークインフラ
• 物理セキュリティポリシーを実装できる
• 仮想インフラ

39

AWS独自ですべきセキュリティ対策

• Amazon VPC(Virtual Privete Cloud)の利用

• MFA(Muti Factor Authentication)デバイスの利用

• IAM(Identity and Access Management)の利用

40

Amazon VPC
• AWS上に、好きなネットワーク体系の論理的なネット
ワークを構築できるサービス
– ネットワーク上にEC2等のAWSサービスを配備

41

VPCでしか使えないもの
– インバウンドとアウトバウンド両方の指定
– セキュリティグループの動的な追加/削除

• ネットワークACL
– セキュリティグループに加え、ステートレスなフィルターを使用
可能

• ENI(Elastic Network Interface)
– EC2に追加のネットワークカードを付与
• VPN/専用線接続


VPCでしか使えないもの
– インバウンドとアウトバウンド両方の指定
– セキュリティグループの動的な追加/削除
VPC != VPN
• ネットワークACL
– セキュリティグループに加え、ステートレスなフィルターを使用
VPN接続や専用線接続を使用しなくて
可能

• も、VPCを利用したほうが利点が多い
ENI(Elastic Network Interface)
– EC2に追加のネットワークカードを付与
• VPN/専用線接続


MFAデバイスの利用
• AWSマネジメントコンソールは守るべき対象
• MFAを使うと、ログイン時に、ユーザーID、パスワード
の他に、デバイスに表示される数値を入力して認証する
• S3の削除時や、APIコール時にも利用可能
– S3 delete protection, MFA protected API call


AWS Identity and Access
Management (IAM)
• AWSを操作するためのユーザとグループの作成

• 各グループ・ユーザーごとに、操作権限の付与が可能
• 例えば「EC2の停止ができないユーザー」が作れる

• ユーザーごとにID/Passwordなどの認証情報を発行でき
る
• MFAもユーザーごとに設定可能

• AWS SDKをEC2上で使用する場合は、「IAM Role」を
使用可能
• EC2に認証情報を置かずにAPIコールが可能に
45




47


・共有責任モデルを理解し、必要なところだけに注力する
・既存のセキュリティポリシーを適用

・AWS独自部分は、提供機能をしっかり利用

48

49

AWSの共有責任モデル（shared responsibility model）

More Related Content

What's hot

Viewers also liked

Similar to AWSの共有責任モデル（shared responsibility model）

More from Akio Katayama

AWSの共有責任モデル（shared responsibility model）