第20回 関西情報セキュリティ団体合同セミナー登壇資料
TRANSCRIPT
はじめに
⾃⼰紹介久保 智夫
所属株式会社サーバーワークス クラウドインテグレーション部
ソリューションアーキテクト
エンタープライズAWS導⼊のアーキテクト、プリセールス、PM等
⼤阪オフィス(新⼤阪)勤務
経歴ISP向けバックボーンサービス開発＠通信キャリア
SI(NI)／プライベートクラウド／ネットワークセキュリティ＠ISP社会⼈⼈⽣の⼤半をここで過ごす
情シス 兼 インフラグループマネージャー＠B2B専業EC
等を経て今年から現職
JNSAとの関わりは2013年から（⻄⽇本⽀部）
サーバーワークスについて
AWS（AmazonWebServices）専業のクラウドインテグレータ・MSPパブリッククラウドに特化
取り扱うシステムは企業の基幹システム等堅めのところから、ECやコーポレート系等のフロント系まで
最近ではビッグデータやIoT向け分析基盤なども
APN(AWSPartnerNetwork)PremierConsulKngPartner（国内5社）の1社JNSA会員企業でPremierConsulKngPartnerはTIS様と当社の2社
“エンタープライズAWS”を標榜する企業として、セキュリティを⾮常に重視
本⽇の内容について
パブリッククラウドでのセキュリティの考え⽅を広く解説することを⽬的としており、あまり技術的なトピックには触れません
久保の業務上、最も詳細を理解しているAWS（AmazonWebServices）の内容を例にとって説明する場⾯がどうしても多くなりますが、特定の企業及びサービスを皆様に推奨する意図はありません
本⽇発表する内容について、アマゾンウェブサービスジャパン株式会社は関知しておりません。内容に関するご質問は久保宛てにお寄せ下さい
クラウドを使う企業、使わない企業
会場の皆さんに質問
「皆さんの会社ではクラウド使ってますか？？」
国内のクラウド普及状況
クラウドサービスを利⽤しているか？
全社的に利⽤している
⼀部の事業所⼜は部⾨で利⽤している
利⽤していないが、今後利⽤する予定がある
利⽤していないし、今後も利⽤する予定もない
クラウドサービスについてよく分からない
全社的もしくは⼀部で利⽤している企業は全体の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）
0102030405060708090100
クラウドの導⼊に伴う既存シ
ステムの改修コストが⼤きい
クラウドの導⼊によ
て⾃社
コンプライアンスに⽀障をき
たす
通信費⽤がかさむ
ニー
ズに応じたアプリケー
シ
ンのカスタマイズができ
ない
ネ
トワー
クの安定性に対す
る不安がある
情報漏洩などセキ
リテ
に
不安がある
法制度が整
ていない
必要がない
メリ
トが分からない、判断
できない
その他
無回答
パブリッククラウドに対する不安の声（クラウド事業者の）中の⼈がデータ抜いたらどうするの？どんな体制で運営されているの？
別のユーザにデータが漏洩してしまうことはないの？
情報が物理的にどこに存在するか分からないから怖い
インターネット越しに利⽤するのが何となく怖い
データ格納場所が抽象化されることへの不安
クラウド事業者⾃⾝のコンプライアンスへの不安
リソース共有型サービスに対する不安
通信経路（インターネット）に対する不安
本⽇の⽬的
ここから、クラウドサービスにおけるセキュリティの考え⽅を解説します
“パブリッククラウドって怖くないんだ！“と
実感していただくことと、
“パブリッククラウドでのセキュリティの考え⽅”を理解していただくことが本⽇のゴールです
クラウドのおさらい
クラウドの定義
NIST（⽶国国⽴上旬技術研究所）によるクラウドコンピューティングの定義
クラウドコンピューティングは、共⽤の構成可能なコンピューティングリソース（ネットワーク、サーバー、ストレージ、アプリケーション、サービス）の集積に、どこからでも、簡便に、必要に応じて、ネットワーク経由でアクセスすることを可能とするモデルであり、最⼩限の利⽤⼿続きまたはサービスプロバイダとのやりとりで速やかに割当てられ提供されるものである。このクラウドモデルは 5つの基本的な特徴と 3つのサービスモデル、および 4つの実装モデルによって構成される。
出展：独⽴⾏政法⼈ 情報処理推進機構https://www.ipa.go.jp/files/000025366.pdf
オンデマンド・セルフサービス
幅広いネットワークアクセス リソースの共⽤ スピーディな
拡張性サービスが計測可能であること5つの特徴
3つのサービスモデル IaaS PaaS SaaS
4つの実装モデル
プライベートクラウド
コミュニティクラウド
パブリッククラウド
ハイブリッドクラウド
3つのサービスモデル
IaaSInfrastructureasaservice
PaaSPlaVormasaservice
SaaSSoWwareasaservice
演算機能等のコンピューティングリソース・ストレージ・ネットワーク等をネットワーク越しに提供するサービ
ス。
⼀般的に仮想化されたサーバを借りるため、ミドルウェアより上層レイヤーについては⾃由に触ることができる。
例：Amazon EC2、Azure VM、Google Compute Engine等
3つのサービスモデル
IaaSInfrastructureasaservice
PaaSPlaVormasaservice
SaaSSoWwareasaservice
ユーザが開発（もしくは購⼊）したアプリケーションを実装するための基盤をネットワーク越しに提供するサービ
ス。
ユーザはアプリケーションの開発に専念することが出来る。PaaSの動作⾔語と⾃社の開発⾔語がマッチすれば導⼊
が容易。
例：AWS Elastic Beanstalk、Azure Cloud Services、Google App Engine
等
3つのサービスモデル
IaaSInfrastructureasaservice
PaaSPlaVormasaservice
SaaSSoWwareasaservice
クラウドのインフラストラクチャ上で稼働しているプロバイダ由来のアプリ
ケーションサービス。
多くの場合完全に定型化されたサービスであるため、アプリケーションに⾃社固有のカスタマイズを施すことは出
来ない。
例：Office 365、Google Apps等
ここまでのおさらい
クラウドサービスの提供形態は⼤きく分けてIaaS／PaaS／SaaSの3つが存在する
提供形態によって利⽤者側に与えられる⾃由度が異なる
クラウドのサービスモデルと責任範囲について
AWSの共有責任モデル（AWSSecurityWhitepaperより⼀部抜粋）…AWSisresponsibleforsecuringtheunderlyinginfrastructurethatsupportsthecloud,andyou’reresponsibleforanythingyouputonthecloudorconnecttothecloud.Thissharedsecurityresponsibilitymodelcanreduceyouropera=onalburdeninmanyways,andinsomecasesmayevenimproveyourdefaultsecurityposturewithoutaddi=onalac=ononyourpart.
詳細は 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&AccessManagement）という権限管理の仕組みを提供している
IAMアカウント毎に実⾏できる操作や、操作できるリソースをポリシーとして定義
普段の業務にはrootアカウントは⽤いず、IAMアカウントを使⽤する
IAMアカウントの認証にMFA（多要素認証）を使⽤する
クラウドではこれらの機能を使って⾃社の環境をセキュアに維持する必要がある
注意点：パブリックなサービスの存在
多くのパブリッククラウドが⾃社ネットワークとのプライベート接続が可能
しかし⼀部のサービスにはパブリック（≒グローバルIPアドレスを持ちインターネットにルーティングされ、アクセス可能）なものが存在する
これらのサービスへの接続ポイントを“エンドポイント”と呼ぶ
対策：ネイティブの機能でアクセスを制限
各サービスのエンドポイントはSSL/TLSでの接続が利⽤可能
エンドポイントへのアクセスは、特定アカウント・特定IPアドレスに限定したアクセス権の付与により保護することが可能
クラウド側から提供されているこれらのツールを活⽤することで⼗分に保護可能
まとめ
本⽇のまとめ
パブリッククラウドだからといって特別に不安視する必要はない
その反対に、オンプレミスに⽐べ特に⼿を抜けるわけでもない
パブリッククラウド基盤は⾃社単独ではとても真似できないレベルの施策をあらゆるレイヤにおいて施している
クラウド独⾃の従来にないユーティリティはしっかり押さえ、使いこなす必要がある（それを前提にした作り）
本⽇のまとめ
パブリッククラウド、安⼼して使っていきましょう！！
※使うことによるメリットを詳しく知りたい⽅は久保まで
ご静聴有難うございました