進むクラウドセキュリティ

https://www.cloudsecurityalliance.jp/Copyright © 2018 Cloud Security Alliance Japan Chapter
進むクラウドセキュリティ
（グローバル企業に求められるネットワー
クプラットフォーム）
一般社団法人日本クラウドセキュリティアライアンス
業務執行理事諸角昌宏
CCSP, CCSK, CSAリサーチフェロー
2020年1月23日

https://www.cloudsecurityalliance.jp/Copyright © 2018 Cloud Security Alliance Japan Chapter www.cloudsecurityalliance.orgCopyright © 2018 Cloud Security Alliance Japan Chapter
1.Cloud Security Allianceについて
2.クラウドセキュリティの現状
3.クラウドセキュリティの基本とCSAの役
割
4.クラウド集中からクラウド分散へ
5.クラウドネットワークにおける考慮事項
6.クラウドとゼロトラスト
7.まとめ

CSA本部：グローバルな非営利活動法人
創立：2009年
会員数
個人会員 9万人以上
地域支部 90以上(日本を含む）
企業会員 400社以上
33のワーキンググループと調査研究プロジェクト
政府、研究機関、専門家団体、企業との戦略的パートナー
シップ
次世代ITのための実践規範の構築
調査研究と普及啓発
“クラウドコンピューティングにおけるセキュリティ保証に向けた実践
規範活用の促進と、クラウド利用のための教育を通じてあらゆるコン
ピュータ利用のセキュリティを高めるための活動への取組み

目的
Cloud Security Alliance(CSA)の開発するガイドラインやツール
を日本で展開・活用するための取組みを中心に活動
CSAの活動の活発化、世界的プレゼンスの向上
各国での支部の設立、法人化の進行
ますます浸透するクラウドの活用とそのセキュリティ課題の重
要性に対応
経緯
2010年6月に任意団体として発足
2013年12月にCSA日本支部を法人化（一般社団法人へ）
日本におけるクラウドセキュリティへの取組みの中心を担う
べく、法人化し、活動基盤の強化充実を図る
会員数
企業会員：36社（2019年11月1日時点）
個人会員：約140名

https://www.cloudsecurityalliance.jp/Copyright © 2018 Cloud Security Alliance Japan Chapter 6
ISO27001/ISO27010/
HIPAA/ HITECH Ac/
AICPA/COBIT/ENISA
/ FedRAMP/ PCI
DSS
WGや研究活動
他の
基準との連結
6

 企業におけるクラウド利用状況
（出典）総務省「通信利用動向調査」
 クラウドを利用する理由
効率化、コストカット
セキュリティ対策

引用：政府情報システムにおけるクラウドサービスの利用に係る基本
方針（2018年6月7日）
「クラウド・バイ・デフォルト原則、
すなわち、政府情報システムを整備
する際に、クラウドサービスの利用
を第一候補とすることとされ、…
「政府情報システムにおけるクラウ
ド・バイ・デフォルトの基本的な考え
方、各種クラウド（パブリッククラウ
ド、プライベートクラウド等）の特徴、
クラウド利用における留意点等を整理
する」

 クラウドサービスを利用しない理由
（出典）総務省「通信利用動向調査」
セキュリティに対する懸念
 クラウドに対する期待
• 従来の「IT予算の削減」は、過年
度調査と比較して優先順位が大
幅に低下
• クラウド導入の促進要因として
「ITセキュリティの強化」を最も
重要視
（出典）IDC Japan クラウドに関わるユーザー動向調査「CloudView 2017」

クラウドの利用における最大の懸念は引き続
き「セキュリティ」
クラウドの利用に対する最大の期待は「セ
キュリティ」の強化
背景
セキュリティ人材の不足
企業独自のセキュリティ確保は限界
クラウド・プロバイダーのセキュリティ
強化
セキュリティをソフトウエアで解決
（出典）経済産業省「 IT人材の最新動向
と将来推計に関する調査結果について」

https://www.cloudsecurityalliance.jp/Copyright © 2018 Cloud Security Alliance Japan ChapterCopyright © 2018 Cloud Security Alliance Japan Chapter https://cloudsecurityalliance.jp/
1. 重要なのはセキュリティのベースラインを上げること
企業、個人レベルで立ち向かうことは不可能
可用性、堅牢性は圧倒的にクラウドが優位
2. プロバイダの透明性を有効活用
欧米中のプロバイダは自社のセキュリティ状況を積極的に公開
例： CSA STAR認証では、プロバイダのセルフアセスメントの
結果を公開。200社以上が登録
セキュリティはプロバイダの差別化要因
プロバイダのセキュリティレベルを判断できるリテラシーは必須
3. セキュリティのソフトウエア化（サービス化）
セキュリティの人材不足はソフトウエアが解決
クラウドは、様々なセキュリティのソフトウエア化が可能
12

クラウドのセキュリティ（特にパブリック）を考えるときに重要な
概念
NIST定義の採用（SP800-145）
SPIモデル
Software as a Service
Platform as a Service
Infrastructure as a Service
14
（クラウドコンピューティングのためのセキュリティ
ガイダンス V4.0から引用）

SaaSにおいてはクラウド
事業者が、IaaSにおいて
はクラウド利用者がより
多くのリスクを管理する
クラウド利用者は、リス
クを所管する最終的な責
任を負っており、クラウ
ド事業者にはリスクマネ
ジメントの一部を転嫁し
ているに過ぎない
15
（クラウドコンピューティングのためのセキュリティガイダンス V3.0から引用）
責任共有モデル
クラウド事業者は、一定のリスクに対する責任を負い、クラウド利用者
はその先のすべてに責任を持つ

クラウド利用によるリスク・アセスメントとリスク対応方
針の策定
ベースは組織としてのリスク管理。クラウドはその延長
利用者/プロバイダーの責任範囲の明確化
責任境界の認識。どちらも責任範囲がゼロになることはない
責任範囲を超えた部分の管理
利用者：プロバイダーに確認、必要に応じてSLA/契約化
注意点：最終責任/説明責任は必ず利用者側
プロバイダー：セキュリティ情報の公開、透明性
有効なツール
CCM（Cloud Control Matrix）、CAIQ（Consensus Assessment Initiative
Questionnaire）
ISO/IEC 27017
第三者監査の結果
16

クラウド利用者/事業者のためのセキュリティガイダンス
１４の領域に分けて、クラウドセキュリティについて記述
CCM、CAIＱに基づいたクラウド事業者の認証登録制度
ガイダンスの実装基準として、ガイダンスの14領域におけるセキュ
リティコントロールのフレームワーク、他の国際標準、業界標準な
どとの対応付け
17

クラウドセキュリティを系
統的に理解することが重要
14のドメインで解説
アーキテクチャ
法律、コンプライアンス、ガ
バナンス
技術的管理と対策
18

https://www.cloudsecurityalliance.jp/Copyright © 2018 Cloud Security Alliance Japan ChapterCopyright © 2018 Cloud Security Alliance Japan Chapter https://cloudsecurityalliance.jp/ 19
Domain 1 クラウドコンピューティングのコンセプトとアーキテクチャ
Domain 2 ガバナンスと経営リスク管理
Domain 3 法的課題、契約および電子証拠開示
Domain 4 コンプライアンスと監査マネジメント
Domain 5 情報ガバナンス
Domain 6 管理画面と事業継続
Domain 7 インフラストラクチャ・セキュリティ
Domain 8 仮想化とコンテナ技術
Domain 9 インシデントレスポンス
Domain 10 アプリケーションセキュリティ
Domain 11 データセキュリティと暗号化
Domain 12 アイデンティティ管理、権限付与管理、アクセス管理 (IAM)
Domain 13 Security as a Service
Domain 14 関連技術

クラウドサービスに必要なコントロール（管理策・統
制）とその実装方針の提示
情報セキュリティ上の管理策（ISMSなど）
ITガバナンス上の統制項目（SOC2など)
適用対象の明示
コントロールとアーキテクチャレイヤの対応付け（コンピュー
ト、ネットワークなど）
コントロ－ルとクラウドサービスモデルの対応付け
（SaaS,PaaS,IaaS）
コントロールと対象となる実施者（事業者、利用者）の明示
各種標準との対応付け
既存の国際標準、業界標準、政府標準における同種コントロールとの
対応付け
CSAガイダンスのドメインとの対応(双方向参照）

クラウド事業者のセキュリティとガバナンスを可視化する取り組み
22
STAR認証レベル
STARセキュリティ認
証
STARプライバシー認証

レベル1
自己評価
レベル2
第三者認証
レベル3
継続的モニタ
リング/監査
透明性と高い保
証を実現

CSA-JC 2019 https://www.cloudsecurityalliance.jp/ 24
外部の
ガバナンス
標準
法制
慣行
仕様
分野ごと
の規制
(銀行、
公的機関)
要求事項
と管理策
CCMマッピング
ギャップ分析
新しい管理策
の開発
新しい管理策
の追加
既存のCCM
管理策を
直接活用
照合
EU-SECの
要求事項と
管理策の
リポジトリ
その他、FedRAMP
ISO/IEC 27017、
ISO/IEC 27018、
C5など、様々な基
準に対応。包括的
に、グローバルの
基準に対応。
クラウドサービ
スの安全性評価
とのマッピング
を予定

IaaS
資産を持たない
既存のオンプレ・システムをクラウドに移行
新規システムをクラウド上で開発・運用
PaaS
新規システムの早期立ち上げ
迅速な開発
SaaS
ビジネスの迅速な開始
クラウド上のサービスを直接利用
効率化、コストカットを目的とした利用
オンプレ or クラウドの選択  クラウド集中型
26

マルチクラウド
複数のクラウド（オンプレを含む）を組み合わせた最適な利用
エッジコンピューティング
5G
IoTなど、よりデバイスに近いところで処理
リアルタイム性の追求
サービスのプラットフォーム化
適材適所のコンポーネントの配備
開発から配備まで一貫した管理
クラウド分散型への移行
27

コンテナ
OSのリソースを共有し活用する、OSの中で稼動するコード実行
環境
28
引用：https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/00761/
Kubernetes
自動配備、スケーリング、操作するためのプラットフォーム

サーバレスコンピューティング
クラウド利用者が下層のハードウェアあるいは仮想マシンを何も
管理せず、単に外部に提示される機能にアクセス
例：Amazon Lambda
インフラの設定、容量の計画、サーバ管理は、フルマネージド
サービスとしてクラウドプロバイダーが実施
利用者がインフラについて悩む必要がない
必要に応じてスケーリング可能
アプリを自由に作成、管理、配備可能
マイクロサービス
疎結合型のソフトウエア開発
29

DevOps、DevSecOps
開発から配備までを一貫して実施。
ソフトウエアにより開発から配備までの一貫した管理
（Infrastructure a Code）
変更無用（immutable）なワークロード
パッチを当てたりあるいは他の変更を加えたりはしない
30

31
モノリシックな三層型
アーキテクチャから
自律サービスの疎結合型
プラットフォームへ
出典：ヘルスケアクラウド研究会（2015年11月）を基に作成
• クラウド分散化におけるプラット
フォーム・セキュリティの考慮事
項
• コンポーネントのユーザー認証／認可
• コンポーネント間通信のセキュリティ
• コンポーネントの完全性保証
• サードパーティアプリケーションとの通
信のセキュリティ
• デバイス／センサー自体のセキュリティ
• デバイス／センサーとプラットフォーム
間通信のセキュリティ
• 開発環境（特にマルチテナント環境）の
セキュリティ
• 利用者側の監査／コンプライアンスへの
対応
コンシューマードリブンなビジネスモデルはXaaSからマイ
クロサービスのプラットフォームへ（例：Fintechサービス）

1. クラウドネットワーク通信のセキュリティ
2. クラウドネットワークのアクセス管理
3. 接続デバイスの認証・管理
4. 仮想ネットワークの監視・管理
5. セキュアリモートアクセス（VPN) の課題
33

信頼できないネットワーク環境でのデータ送受信の機密性、
完全性の確保
クラウド外とクラウド内との通信
オンプレ、インターネット環境<->クラウド間通信
クラウド内通信
サービス間通信、仮想マシン間通信
マルチテナント環境
プロバイダ間通信
プロバイダごとのサービス間通信
プロバイダ間データ通信
• インターネット上のデータ送受信の暗号化
• マルチテナント環境でのデータ送受信の暗号化
34

NISTのクラウドの５つの特徴の定義の１つ
幅広いネットワークアクセス（Broad network access）
あらゆるデバイス、あらゆるネットワーク
既存のロールベースのアクセス制御では不十分
クラウドサービスごとのアクセス権の設定
場所、デバイスに基づくより粒度の高いアクセス方法の設定
• 標準のIDフェデレーション、プ
ロビジョニングの利用
SAML, OpenID Connect,
SCIMなど
• IDaaSの検討

クラウドに接続してくるデバイスの
信頼性の確保
「のらIoT」問題
正しい接続相手デバイス、正しいサー
ビスの発見、管理
大量のデバイスの管理
安全なファームウェアイメージのデバ
イスへの配布と更新
接続APIの安全性の確保
プライバシー対応
PKIやBlockchain技術を用いたデバ
イス認証・管理
36
引用：「IoTセキュリティのためのブロックチェーン技
術の活用」

クラウドの仮想ネットワーク環境では、物理ネットワークを直接的
に管理・監視できない
一般的なネットワークセキュリティは、物理的な通信経路の制御とセキュリ
ティアプライアンスの設置。クラウドではこれができない
インライン型の仮想アプライアンス、あるいはインスタンスにインストール
されるソフトウェアエージェントの利用
仮想アプライアンスの課題
ボトルネックの可能性や障害時のフェール
オープンが難しい
ソフトウエアエージェントの課題
プロセッサの負荷を増やす可能性
クラウドプラットフォームの統合管理と
SDNの組み合わせ
• 仮想ネットワーク間の隔離
• セキュリティグループ（クラウドファイアウォール）
• その他
37

セキュアリモートアクセスの現在の解決策： VPN！
信頼できないネットワーク間で安全なプライベートネットワーク接続
を確立
以下のように幅広く利用
安全なリモートアクセス
安全なサイト間通信
異なる企業間通信
課題
IT管理者は複数の場所にまたがってVPNおよびファイアウォールポリ
シーを設定・同期する必要がある
全てのユーザのトラフィックを企業のネットワークに集中した場合の
レイテンシー、単一障害点、バンド幅に伴うコストの問題
VPNサーバ自体インターネット上のサービスとして公開。VPNサーバ
に脆弱性が存在すると攻撃者によって悪用される可能性
38

「あらゆるデータ侵害は『信
頼する』としたネットワーク
モデルのほころびから生じて
いる。データ侵害をなくすに
は『ゼロトラスト（信頼しな
いこと）』が必要」（引用：
キンダーバグ氏
“https://enterprisezine.jp/article/detail/11575”）
データが置かれている場所を
信頼しないことを前提
アクセスする際にデバイスや
アクセス認証を実施し、セ
キュリティを担保する
40

ネットワーク型の防御
アイデンティティ型の防御
41

リクエスト/レスポンス型
リクエストを受け取るための口
を常に開けている
安全なリモートアクセスの問題
アクセスが許可されている人も
許可されていない人もアクセス
が可能
空いているポートの情報から脆
弱性を狙った攻撃が可能
DDoS攻撃が簡単に実現可能
42

ゼロトラスト下の3原則
1. 場所に関係なく、全てのリソースが安全にアクセスできることを
保証する
2. 全てのトラフィックのログを調査する
3. 最小権限の原理を維持・強化する
ゼロトラストの対策
アクセスが許可される前は、全ての内部/外部（inside/outside
perimeter）の接続要求を信用しない
誰がアクセスしてきたが分かるまでは、ネットワークを閉じておく
認証されるまではIPアドレス、デバイスなどのアクセスを許可しな
い
43

例： Software Defined Perimeter (SDP)
サーバーとは別のところで、認証およびデバイスの検証を行い、信頼された
デバイスおよび信頼できるユーザーのみがサーバーに接続
アクセスが許可される前は、全ての内部/外部（inside/outside perimeter）の
接続要求を信用しない
誰がアクセスしてきたが分かるまでは、ネットワークを閉じておく
認証されるまではIPアドレス、デバイスなどのアクセスを許可しない
44
引用：「SDP利用シナリオ集」
https://cloudsecurityalliance.jp/site/wp-content/uploads/2019/04/SDP%E5%88%A9%E7%94%A8%E3%82%B7%E3%83%8A%E3%83%AA%E3%82%AA%E9%9B%86
%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E7%89%88-v1.0.pdf

SDPワークフロー
1. SDP コントローラがオンラインとなる
2. Accepting hostは、SDP ControllerとセキュアなVPN接続を確立
3. Initiating hostは、SDP ControllerとセキュアなVPN接続を確立
4. SDP Controllerは、Initiating hostから送られてきたデバイスと本人情報に基づいて認証。接続依頼先
にAccepting hostが存在するかを確認
5. 接続依頼が正しい場合、SDP Controllerは、Accepting hostに対して、Initiating hostからの接続要求
を送信
6. SDP Controllerは、Initiating hostに対して、アクセスが可能なAccepting hostのネットワーク情報を
送信
7. Initiating hostは、アクセスが許可されたAccepting hostに対して双方向暗号の通信を開始
2つのコンポーネント
SDP Hosts
SDP Controller
SDP Hostsは、Initiaiting Hosts(IH) と Accepting
Hosts(AH)で構成され、SDP Controllerによって管
理される。
45
出典「クラウド時代に求められる最新
の認証方式」

1. クラウドセキュリティの基本は責任共有モデル
2. 柔軟性を考慮したネットワーク/システム設計
3. ゼロトラストではアイデンティティ型の防御、認
証されるまではアクセスを許可しない
47

ありがとうございました
https://cloudsecurityalliance.jp
info@cloudsecurityalliance.jp
CSAの活動 == 「場」の提供！
様々なワーキンググループ活動の
「場」
自由な情報発信の「場」

進むクラウドセキュリティ

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

Similaire à 進むクラウドセキュリティ

Similaire à 進むクラウドセキュリティ (20)

Dernier

Dernier (8)

進むクラウドセキュリティ

Notes de l'éditeur