第20回 関⻄情報セキュリティ団体合同セミナー
パブリッククラウドとセキュリティ
株式会社サーバーワークス 久保智夫	
<kubo@serverworks.co.jp>
はじめに
⾃⼰紹介
久保 智夫	
所属	
株式会社サーバーワークス クラウドインテグレーション部	
ソリューションアーキテクト	
エンタープライズAWS導⼊のアーキテクト、プリセールス、PM等	
⼤阪オフィス(新⼤阪)勤務	
経歴	
ISP向けバックボーンサービス開発@通信キャリア	
SI(NI)/プライベートクラウド/ネットワークセキュリティ@ISP	
社会⼈⼈⽣の⼤半をここで過ごす	
情シス 兼 インフラグループマネージャー@B2B専業EC	
等を経て今年から現職	
JNSAとの関わりは2013年から(⻄⽇本⽀部)
サーバーワークスについて
AWS(Amazon	Web	Services)専業のクラウドインテグレータ・MSP	
パブリッククラウドに特化	
取り扱うシステムは企業の基幹システム等堅めのところから、ECやコーポレート系
等のフロント系まで	
最近ではビッグデータやIoT向け分析基盤なども	
APN(AWS	Partner	Network)	Premier	ConsulKng	Partner(国内5社)の1社	
JNSA会員企業でPremier	ConsulKng	PartnerはTIS様と当社の2社	
“エンタープライズAWS”を標榜する企業として、セキュリティを⾮常に重視
本⽇の内容について
パブリッククラウドでのセキュリティの考え⽅を広く解説することを⽬的とし
ており、あまり技術的なトピックには触れません	
久保の業務上、最も詳細を理解しているAWS(Amazon	Web	Services)の内容を
例にとって説明する場⾯がどうしても多くなりますが、特定の企業及びサービ
スを皆様に推奨する意図はありません	
本⽇発表する内容について、アマゾンウェブサービスジャパン株式会社は関知
しておりません。内容に関するご質問は久保宛てにお寄せ下さい
クラウドを使う企業、使わない企業
会場の皆さんに質問
「皆さんの会社ではクラウド使ってますか??」
国内のクラウド普及状況
クラウドサービスを利⽤しているか?
全社的に利⽤している
⼀部の事業所⼜は部⾨
で利⽤している
利⽤していないが、今
後利⽤する予定がある
利⽤していないし、今
後も利⽤する予定もな
い
クラウドサービスにつ
いてよく分からない
全社的もしくは⼀部で利⽤している企業は全体の40%弱
出展:総務省 平成26年通信利⽤動向調査より
(http://www.e-stat.go.jp/SG1/estat/List.do?
bid=000001061335&cycode=0)
クラウドを採⽤しない理由
クラウド⾃体にセキュリティ⾯で不安を感じている企業、クラウド導⼊により
コンプライアンスが脅かされると考えている企業が少なからず存在する
出展:総務省 平成26年通信利⽤動向調査より
(http://www.e-stat.go.jp/SG1/estat/List.do?
bid=000001061335&cycode=0)
0	
10	
20	
30	
40	
50	
60	
70	
80	
90	
100	
ク
ラ
ウ
ド
の
導
⼊
に
伴
う
既
存
シ
ス
テ
ム
の
改
修
コ
ス
ト
が
⼤
き
い
ク
ラ
ウ
ド
の
導
⼊
に
よ
て
⾃
社
コ
ン
プ
ラ
イ
ア
ン
ス
に
⽀
障
を
き
た
す
通
信
費
⽤
が
か
さ
む
ニ
ー
ズ
に
応
じ
た
ア
プ
リ
ケ
ー
シ
ン
の
カ
ス
タ
マ
イ
ズ
が
で
き
な
い
ネ
ト
ワ
ー
ク
の
安
定
性
に
対
す
る
不
安
が
あ
る
情
報
漏
洩
な
ど
セ
キ
リ
テ
に
不
安
が
あ
る
法
制
度
が
整
て
い
な
い
必
要
が
な
い
メ
リ
ト
が
分
か
ら
な
い、
判
断
で
き
な
い
そ
の
他
無
回
答
パブリッククラウドに対する不安の声
(クラウド事業者の)中の⼈がデータ抜いたらどうするの?どんな体制で運営
されているの?	
別のユーザにデータが漏洩してしまうことはないの?	
情報が物理的にどこに存在するか分からないから怖い	
	
	
インターネット越しに利⽤するのが何となく怖い	
データ格納場所が抽象化されることへの不安
クラウド事業者⾃⾝のコンプライアンスへの不安
リソース共有型サービスに対する不安
通信経路(インターネット)に対する不安
本⽇の⽬的
ここから、クラウドサービスにおけるセキュリティの考え⽅
を解説します	
	
	
“パブリッククラウドって怖くないんだ!“と	
実感していただくことと、	
“パブリッククラウドでのセキュリティの考え⽅”	
を理解していただくことが本⽇のゴールです
クラウドのおさらい
クラウドの定義
NIST(⽶国国⽴上旬技術研究所)によるクラウドコンピューティングの定義	
クラウドコンピューティングは、共⽤の構成可能なコンピューティングリソース(ネッ
トワーク、サーバー、ストレージ、アプリケーション、サービス)の集積に、どこから
でも、簡便に、必要に応じて、ネットワーク経由でアクセスすることを可能とするモデ
ルであり、最⼩限の利⽤⼿続きまたはサービスプロバイダとのやりとりで速やかに割当
てられ提供されるものである。このクラウドモデルは 5	つの基本的な特徴と 3	つのサー
ビスモデル、および 4	つの実装モデルによって構成される。
出展:独⽴⾏政法⼈ 情報処理推進機構
https://www.ipa.go.jp/files/000025366.pdf
オンデマンド・	
セルフサービス
幅広いネット
ワークアクセス
リソースの共⽤
スピーディな	
拡張性
サービスが計測
可能であること
5つの特徴
3つの
サービスモデル
IaaS PaaS SaaS
4つの
実装モデル
プライベート	
クラウド
コミュニティ	
クラウド
パブリック	
クラウド
ハイブリッド	
クラウド
3つのサービスモデル
IaaS	
Infrastructure	as	a	service
PaaS	
PlaVorm	as	a	service
SaaS	
SoWware	as	a	service
演算機能等のコンピューティングリ
ソース・ストレージ・ネットワーク等
をネットワーク越しに提供するサービ
ス。
⼀般的に仮想化されたサーバを借りる
ため、ミドルウェアより上層レイヤー
については⾃由に触ることができる。
例:Amazon EC2、Azure VM、
Google Compute Engine等
3つのサービスモデル
IaaS	
Infrastructure	as	a	service
PaaS	
PlaVorm	as	a	service
SaaS	
SoWware	as	a	service
ユーザが開発(もしくは購⼊)したア
プリケーションを実装するための基盤
をネットワーク越しに提供するサービ
ス。
ユーザはアプリケーションの開発に専
念することが出来る。PaaSの動作⾔語
と⾃社の開発⾔語がマッチすれば導⼊
が容易。
例:AWS Elastic Beanstalk、Azure
Cloud Services、Google App Engine
等
3つのサービスモデル
IaaS	
Infrastructure	as	a	service
PaaS	
PlaVorm	as	a	service
SaaS	
SoWware	as	a	service
クラウドのインフラストラクチャ上で
稼働しているプロバイダ由来のアプリ
ケーションサービス。
多くの場合完全に定型化されたサービ
スであるため、アプリケーションに⾃
社固有のカスタマイズを施すことは出
来ない。
例:Office 365、Google Apps等
ここまでのおさらい
  クラウドサービスの提供形態は⼤きく分けてIaaS
/PaaS/SaaSの3つが存在する	
  提供形態によって利⽤者側に与えられる⾃由度が
異なる
クラウドのサービスモデルと
責任範囲について
AWSの共有責任モデル(AWS	Security	Whitepaperより⼀部抜粋)	
…	AWS	is	responsible	for	securing	the	underlying	infrastructure	that	supports	the	cloud,	and	you’re	
responsible	for	anything	you	put	on	the	cloud	or	connect	to	the	cloud.	This	shared	security	responsibility	
model	can	reduce	your	opera=onal	burden	in	many	ways,	and	in	some	cases	may	even	improve	your	
default	security	posture	without	addi=onal	ac=on	on	your	part.		
詳細は h@ps://d0.awssta=c.com/whitepapers/Security/AWS_Security_Whitepaper.pdf	参照	
Azureの共有責任モデル(同社ホワイトペーパーより⼀部抜粋)	
安全を保証する技術の実装や運⽤プロセスについてはマイクロソフトが⼀部負担しますが、お客
様が⾃社のセキュリティ基準に従ってサービスを管理する ために必要なツールと柔軟性はお客様
に提供されます。	
詳細は
h@p://download.microsoE.com/download/6/E/4/6E47A6FA-12DE-4D1D-A5A9-6396A1A9E5B8/
Qualifica=on%20Guideline%20-%20MicrosoE%20Azure.pdf	参照	
クラウド事業者のセキュリティモデル
クラウドではサービスモデルごとにクラウド事業者側と利⽤
者側で分界点を設け、利⽤者と責任を折半している
利⽤者側の⾃由度が⾼くなれば、利⽤者側が負うべき責任
範囲も広くなる!!
⾃由度と責任範囲の関係
OS
ミドルウェア	
・ライブラリ
アプリケーション
データ
オンプレミス
(ハイパーバイザ)
SaaS
⾃由度⾼
責任範囲広
ネットワーク
サーバ	
クラウド事業
者の責任範囲
利⽤者の	
責任範囲
ファシリティ
ストレージ	
OS
ミドルウェア	
・ライブラリ
アプリケーション
データ
ハイパーバイザ
ネットワーク
サーバ	
ファシリティ
ストレージ	
OS
ミドルウェア	
・ライブラリ
アプリケーション
データ
(ハイパーバイザ)
ネットワーク
サーバ	
ファシリティ
ストレージ	
OS
ミドルウェア	
・ライブラリ
アプリケーション
データ
(ハイパーバイザ)
ネットワーク
サーバ	
ファシリティ
ストレージ	
PaaS IaaS
ファイアウォールファイアウォール
クラウド事業者のスタンス
事業者側の責任範囲については	
責任をもって運営する
利⽤者側の責任範囲についてはセキュリティを担保
するためのツールを⽤意する	
ツールを使ってシステム全体のセキュリティを管理
するのは利⽤者の責任である
クラウド事業者の取り組み
(1)クラウドサービスの運営
第三者認証とホワイトペーパー
クラウドサービスの運営にあたり、各社は数々の厳しい認
証を取得・維持しながら事業展開している。
また、各社それぞれに⾃社のセキュリティ・コンプライア
ンスに関するホワイトペーパーを公開している。
※”AWSコンプライアンス”より
⼀つ⽬の不安に対する答え
(クラウド事業者の)中の⼈がデータ抜いたらどう
するの?どんな体制で運営されているの?	
•  事業者⾃⾝が厳格な運営ポリシーを設け、それを
ホワイトペーパーとして公開している	
	
•  運営の厳格さは数々の第三者機関が保証している
(2)インフラストラクチャ
クラウド側は何をやっているのか
•  データセンター
•  場所の秘匿
•  物理アクセスのコントロール
•  ⼆要素認証の複数関⾨
•  全物理アクセスを記録&チェック
•  アクセスを必要とする職務の分離
•  24時間体制での監視
ファシリティ
•  DDoS対策
•  テナント間論理NW分離
•  NW機器の脆弱性対策
•  通信経路の暗号化
•  攻撃対策・攻撃予兆対策
•  ポートスキャン
•  スニッフィング
•  etc...
ネットワーク
•  テナント毎の論理
•  論理ディスク削除時の確実なワイプ処
理
•  物理ディスク破棄時の物理破壊
ストレージ
•  管理作業アクセスの監査
•  管理特権の動的割当
ハイパーバイザー
各社以下に⽰すような仕組み・技術の組み合わせにより物
理的・論理的な漏洩・窃取を防いでいる。
※各社ホワイトペーパーからの抜粋・要約
⼆つ⽬の不安に対する答え
別のユーザにデータが漏洩してしまうことはない
の?	
•  物理的な脅威は物理的なコントロールによって厳
格に対策されている	
•  仮想化技術(サーバ/ネットワーク)によってテ
ナントごとの論理的独⽴性を担保している
(3)データの保存場所
クラウドとデータの所在
ほとんどのクラウドサービスでデータセンターの所在地
(住所)は公開していない	
不特定多数に公開することによる物理的な脅威を避けるため	
⼀⽅、どのリージョン(地域)にデータを置くかという選
択肢は利⽤者に与えられている	
クラウド事業者が利⽤者の許可無くデータを別のリージョ
ンに複製することはない(利⽤者の任意で複製することは
可能)
三つ⽬の不安に対する答え
情報が物理的にどこに存在するか分からないから怖
い	
•  物理的な所在を隠蔽することで安全を確保して
いる(場所が知られていることの⽅が危険)	
•  IDCの具体的な場所までは公開されていないが、
利⽤者が保管したデータが利⽤するリージョン
を越えた場所に“勝⼿に”コピーされることはな
い(利⽤者の意図によってコピーすることは出
来る)
(4)通信経路
クラウドとのプライベート接続
以下、主にIaaSに関して	
前提として、多くのパブリッククラウドは社内プライベートネットワーク
の⼀部として相互に接続・ルーティング出来る仕組みになっている	
接続⽅法も要件に応じてIPsecVPNから専⽤線による閉域接続を選ぶことが
可能(AzureのExpressRouteやAWSのDirectConnect等)	
キャリアによってはあたかもクラウド環境を⼀つの拠点のようにアクセス
回線を接続することも可能	
	 パブリッククラウド
社内NW
専⽤線やIPsecVPNに
よるLAN2LAN接続
三つ⽬の不安に対する答え
インターネット越しに利⽤するのが不安	
•  パブリッククラウドといえどキャリアの専⽤線
で社内NWと閉域接続することが可能	
•  つまり従来のWAN接続型IDCと何ら変わりなく利
⽤することが可能	
•  (もちろんインターネット経由での利⽤も可
能)接続⽅法は⾮常に⾃由度が⾼い
利⽤者側でやるべきこと
利⽤者側でやるべきこと
(当たり前ですが)サービスモデルに応じた責任範囲について責
任を持つこと!	
各層においてなすべきことは、オンプレミスと何ら変わらない	
SaaS
OS
ミドルウェア	
・ライブラリ
アプリケーション
データ
ハイパーバイザ
ネットワーク
サーバ	
ファシリティ
ストレージ	
OS
ミドルウェア	
・ライブラリ
アプリケーション
データ
(ハイパーバイザ)
ネットワーク
サーバ	
ファシリティ
ストレージ	
OS
ミドルウェア	
・ライブラリ
アプリケーション
データ
(ハイパーバイザ)
ネットワーク
サーバ	
ファシリティ
ストレージ	
PaaS IaaS
•  OSの脆弱性対応	
•  アカウント管理	
•  権限管理	
•  設定管理	
•  etc…
•  ミドルウェアの脆
弱性対応	
•  設定管理	
•  etc…
•  アカウントの管理	
•  etc…
•  アプリケーションの脆
弱性対応	
•  セキュアコーディング	
•  アクセス記録、監査	
•  etc…
ファイアウォール
•  通信ポリシーの管理
具体的に何ができるか(⼀例)
※これらをやったからといって万全というわけではないけれど…	
データ (SaaS・PaaS・IaaS・オンプレ共通)	
アプリケーションの上に乗せるデータの管理	
データにアクセスするためのアカウント管理、各種権限管理など	
SaaSの場合管理すべき範囲は狭くなるが、アカウント管理が脆弱だといく
らインフラがしっかりしていても何ら意味は無い	
アプリケーション(PaaS・IaaS・オンプレ共通)	
脆弱性を極⼒⽣まないセキュアコーディング	
定期的な診断と対策	
アプリケーションの操作ログ管理・監査	
アプリケーションファイアウォールの導⼊と運⽤(運⽤が⼤事)	
記憶領域(ストレージ、DBのカラム等)やクエリの暗号化
具体的に何ができるか(⼀例)
ミドルウェア・OS(IaaS・オンプレ共通)	
そもそもの設計(不要なバナー応答、過剰なsudo権限…)	
脆弱性対策(情報収集、対策検討、対策実⾏)	
適切なログ記録、監査etc	
などなど	
全て皆さんがこれまで続けてきたことと同じです	
(続けてますよね?)
ここまでのおさらい
  サービスの⾃由度が上がれば、利⽤者側で担わな
ければならない責任範囲も広くなる	
  サービスとして提供されている層よりも上位レイ
ヤーへのセキュリティ施策は、オンプレもクラウ
ドも変わらない
クラウド特有の注意点
例:管理コンソールに権限が集中!
ほとんどクラウドが管理コンソールで⼤半の操作が出来て
しまう(APIやCLIから操作するものもある)	
サーバを起動/停⽌/新規構築/廃棄(廃棄したら⼆度と復活でき
ません)	
管理⽤アカウントを追加/削除/パスワード変更/権限変更	
操作履歴の閲覧	
etc…	
⾃然と管理コンソールへのログイン管理や権限管理、認証
周りの整備が重要になってくる	
	
※右はAWSのマネジメントコンソール
対策:ネイティブの機能で権限を管理
多くのクラウドサービスで、アカウント毎に操作・管理で
きる範囲を設定することが出来る	
たとえば、AWSではIAM(IdenKty	&	Access	Management)と
いう権限管理の仕組みを提供している	
IAMアカウント毎に実⾏できる操作や、操作できるリソースをポリシーとし
て定義	
普段の業務にはrootアカウントは⽤いず、IAMアカウントを使⽤する	
IAMアカウントの認証にMFA(多要素認証)を使⽤する	
クラウドではこれらの機能を使って⾃社の環境を	
セキュアに維持する必要がある
注意点:パブリックなサービスの存在
多くのパブリッククラウドが⾃社ネットワークとの
プライベート接続が可能	
しかし⼀部のサービスにはパブリック(≒グローバルIP
アドレスを持ちインターネットにルーティングされ、ア
クセス可能)なものが存在する	
これらのサービスへの接続ポイントを“エンドポイン
ト”と呼ぶ
対策:ネイティブの機能でアクセスを制限
各サービスのエンドポイントはSSL/TLSでの接続が利⽤可能	
エンドポイントへのアクセスは、特定アカウント・特定IPア
ドレスに限定したアクセス権の付与により保護することが
可能	
クラウド側から提供されているこれらのツールを活
⽤することで⼗分に保護可能
まとめ
本⽇のまとめ
パブリッククラウドだからといって特別に不安視する必要
はない	
その反対に、オンプレミスに⽐べ特に⼿を抜けるわけでも
ない	
パブリッククラウド基盤は⾃社単独ではとても真似できな
いレベルの施策をあらゆるレイヤにおいて施している	
クラウド独⾃の従来にないユーティリティはしっかり押さ
え、使いこなす必要がある(それを前提にした作り)
本⽇のまとめ
パブリッククラウド、	
安⼼して使っていきましょう!!
※使うことによるメリットを詳しく知りたい⽅は久保まで
ご静聴有難うございました

第20回 関西情報セキュリティ団体合同セミナー登壇資料