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.

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

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


• 片山暁雄

– アマゾンデータサービスジャパン

– 技術統括本部エンタープライズソリューション部

– 部長/ソリューションアーキテクト

• Twitter – @c9katayama

– #ヤマン

• 好きなAWSサービス

– IAM(Identity and Access Management)

• 好きな第三者認証

– PCI-DSS

自己紹介


AWS クラウドデザインパターン実装ガイド

• 設計ガイドに続く第二弾

• 実装手順を画面に沿って解説

– コンテンツ配信

– Eコマース

– キャンペーンサイト

• アカウント作成/基本操作も網羅

• ハンズオンにも最適！


Back Net Pattern Ondemand NAT Pattern

Functional Firewall Pattern

WAF Proxy Pattern

Operational Firewall Pattern

5 Copyright ©2012 Amazon Web Services.Inc 5

Agenda

AWSのセキュリティ方針

AWS側のセキュリティ

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

1 2

3

6 @aes256

AWSの

セキュリティ

方針


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

• AWSクラウドのセキュリティ

– セキュリティはAWSにおいて最優先されるべき事項

– セキュリティに対する継続的な投資

– セキュリティ専門部隊の設置

• 共有責任モデルの採用

– AWSと利用者の2者でセキュリティを確保

7


共有責任モデル

8

• ファシリティ

• 物理セキュリティ

• 物理インフラ

• ネットワークインフラ

• 仮想インフラ

• OS

• アプリケーション

• セキュリティグループ

• OSファイアウォール

• ネットワーク設定

• アカウント管理

9

AWS側の

セキュリティ


認定 & 認証評価

SOX法

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

サービスヘルスダッシュボード

セキュリティ責任共有モデル

Customer/SI Partner/ISV がゲストOSレベルのセキュリティを制御(パッチ運用や運用管理含む)

パスワード管理やロールベースのアクセス権管理を含むアプリケーションレベルのセキュリティ

侵入検知/回避システムを含むホストベースのファイアウォール

データの暗号化/複合化. ハードウェアセキュリティモジュール

アクセス権の分離

物理セキュリティ

複数レベル、複数要素による制御されているアクセス環境

管理され必要性に応じたAWS従業員によるアクセス(必要最小限)

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

管理ホストへの多要素認証で、管理され必要性に応じたアクセス

全てのアクセスのログ収集、監視、そしてレビュー

AWS管理者は顧客VMの中、アプリケーションとそのデータなどにはアクセスする権限をもたない

AWSにおけるクラウドセキュリティ概要

VMセキュリティ

Amazonアカウントへの多要素認証によるアクセス

インスタンスの隔離

• ハイパバイザレベルでの顧客によるファイアウォールの制御

• 隣にあるインスタンスへのアクセスは許可されていない

• 仮想ディスクの管理レイヤがアカウントのオーナだけがストレージ(EBS)にアクセスすることを保証する

APIコールの暗号化のためのエンドポイントのSSLサポート

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

セキュリティグループ設定によるインスタンス毎のファイアウォール設定が可能

トラフィックはプロトコル、サービスポート、ソースIPによって制限できる (個別IPまたはindividual IP or Classless Inter-Domain Routing (CIDR)ブロック).

Virtual Private Cloud (VPC) により、既存エンタープライズデータセンターと論理的に隔離された複数のAWSリソースとの間にIPSec VPNでアクセス可能

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/SP800-88_J.pdf


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

17

• DDoS (Distributed Denial of Service): – 標準的な緩和技術を施行

• MITM (Man in the Middle):

– 全てのエンドポイントはSSLによって保護 – EC2のホストキーはブート毎に生成され更新

• IPスプーフィング:

– ホストOSレベルで不許可

• 許可されていないポートスキャン:

– AWSサービス利用規約違反に該当

– 検知され、停止され、ブロックされる

– インバウンドポートはデフォルトでブロックされているため、事実上無効

• パケット・スニッフィング:

– プロミスキャス・モードは不許可

– ハイパーバイザーレベルで制御


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

• セキュリティグループ • インバウンドのトラフィックはプロトコ

ル、ポート、セキュリティグループにより明示的に指定。

• VPCはアウトバウンドのフィルタも追加する

• ネットワークACL: • VPC はインバウンドとアウトバウンドのステートレスフィルタも追加する

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

•これらの機能を提供

OS

Fire

wal

l

Net

wo

rk A

CL

18

Secu

rity

Gro

up


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

Web Tier

Application Tier

Database Tier

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

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

その他のインターネット経由のアクセスは全てデフォルトで拒否

オンプレミスDBとの同期 Amazon EC2 Security Group Firewall

19


Firewall

Physical Interfaces

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

Customer 1 Customer 2 Customer n

Hypervisor

…

… Virtual Interfaces

Customer 1 Security Groups

Customer 2 Security Groups

Customer n Security Groups

21


VMセキュリティ

• ハイパーバイザー（ホストOS）

– AWS管理者の拠点ホストからの個別のSSHキーによるログイン

– 全てのアクセスはロギングされ、監査されます

• Firewall

– AWS利用者設定に従い、トラフィックをコントロール

– 設定しない通信は不可

• ゲストOS（EC2インスタンス）

– 顧客による完全なコントロール (顧客がルート/管理者権限を保有)

– AWS管理者はログイン不可能

– 顧客が生成したいキーペアを使用

22


仮想メモリとローカルディスク

• AWSのディスク管理により、あるインスタンスがその他のインスタンスのデータを読み取るのを防護

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

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

23

Encrypted File System

Encrypted Swap File


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

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

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

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

25


レポート、認定、第三者認証

• AWSは以下のような第三者認証を取得済み

– SSAE 16/ISAE 3402基準、SOC1レポート（旧SAS70)

– SOC2レポート

– ISO 27001 Certification

– PCI DSS Level 1 Service Provider

– FISMA moderate

– Sarbanes-Oxley (SOX)

• AWSにシステムをデプロイし、第三者認証を取得することも可能

– HIPAA (医療関係)

– ASP・SaaS安全・信頼性に係る情報開示認定制度

27

Certified


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

http://aws.amazon.com/security/pci-dss-level-1-compliance-faqs/













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

http://aws.amazon.com/security/


CSA-Consensus Assesments Initiative Questionnaire-

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

• セキュリティ、統制、およびプロセスに関する一連の質問にAWSは回答済み。

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

36

http://aws.amazon.com/jp/security/


金融機関向けAWS対応セキュリティリファレンス

• FISC安全対策基準（第8版）へのAWSの準拠状況を調査した資料を一般公開

• SCSK、NRI(野村総合研究所)、ISID(電通国際情報サービス)3社が共同で調査。AWSも調査に協力

• AWSと利用者で責任分担することで、FISC安対基準を満たせるとの見解

37

http://aws.amazon.com/solution-providers/si/scsk-corporation

http://aws.amazon.com/jp/solutions/solution-providers/isid/

http://aws.amazon.com/jp/solutions/solution-providers/nri/

38

AWS利用者側の

セキュリティ


責任共有モデル

39






• OS






今までのセキュリティポリシーを実装できる


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でしか使えないもの

• セキュリティグループ – インバウンドとアウトバウンド両方の指定

– セキュリティグループの動的な追加/削除

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

• ENI(Elastic Network Interface) – EC2に追加のネットワークカードを付与

• VPN/専用線接続

VPC != VPN

VPN接続や専用線接続を使用しなくても、VPCを利用したほうが利点が多い


MFAデバイスの利用

• AWSマネジメントコンソールは守るべき対象

• MFAを使うと、ログイン時に、ユーザーID、パスワードの他に、デバイスに表示される数値を入力して認証する

• S3の削除時や、APIコール時にも利用可能

– S3 delete protection, MFA protected API call


• AWSを操作するためのユーザとグループの作成

• 各グループ・ユーザーごとに、操作権限の付与が可能

• 例えば「EC2の停止ができないユーザー」が作れる

• ユーザーごとにID/Passwordなどの認証情報を発行できる

• MFAもユーザーごとに設定可能

• AWS SDKをEC2上で使用する場合は、「IAM Role」を使用可能

• EC2に認証情報を置かずにAPIコールが可能に

AWS Identity and Access Management (IAM)

45

まとめ



47






• OS








48






• OS






・共有責任モデルを理解し、必要なところだけに注力する

・既存のセキュリティポリシーを適用

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

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

Technology