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）

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (10)

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

Similaire à AWSの共有責任モデル（shared responsibility model） (20)

Plus de Akio Katayama

Plus de Akio Katayama (20)

Dernier

Dernier (9)

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