クラウド重大セキュリティ脅威対策- DevSecOps のユースケース -一般社団法人 日本クラウドセキュリティアライアンス（CSA ジャパン）
クラウドセキュリティワーキンググループ

Copyright © 2021 Cloud Security Alliance Japan Chapter目次
1.

はじめに .............................................................................. 52.

検討指針 .............................................................................. 6

2.1. 目的 ................................................................................. 6
2.2. 前提 ................................................................................. 63.

ユースケース(クラウド重大セキュリティ脅威 11 の悪質な脅威) ............................. 7

3.1. ケース 1: データ侵害 .................................................................. 7
3.2. ケース 2 設定ミスと不適切な変更管理 .................................................. 123.3. ケース 3 クラウドセキュリティアーキテクチャと戦略の欠如 .............................. 16
3.4. ケース 4 ID・資格情報・アクセス・鍵の不十分な管理 .................................... 21
3.5. ケース 5 アカウントハイジャック ...................................................... 25
3.6. ケース 6 内部者の脅威 ................................................................ 29
3.7. ケース 7 安全でないインターフェースと API ............................................ 33
3.8. ケース 8 弱い管理プレーン ............................................................ 37
3.9. ケース 9 メタストラクチャとアプリストラクチャの障害 .................................. 39
3.10. ケース 10 クラウド利用の可視性の限界 ................................................ 43
3.11. ケース 11 クラウドサービスの悪用・乱用・不正利用 .................................... 47
4.

参考・引用文献 ....................................................................... 51

Copyright © 2021 Cloud Security Alliance Japan Chapter

2

CSA ジャパン成果物の提供に際しての制限事項
日本クラウドセキュリティアライアンス（CSA ジャパン）は、本書の提供に際し、以下のことをお断りし、またお願いします。以下の内容に同意いただけない場合、本書の閲覧および利用をお断りします。
１．

責任の限定

CSA ジャパンおよび本書の執筆・作成・講義その他による提供に関わった主体は、本書に関して、以下のことに対する責任を負いません。また、以下のことに起因するいかなる直接・間接の損害に対しても、一切の対応、是正、支払、賠償の責めを負いません。
(1) 本書の内容の真正性、正確性、無誤謬性(2) 本書の内容が第三者の権利に抵触しもしくは権利を侵害していないこと(3) 本書の内容に基づいて行われた判断や行為がもたらす結果(4) 本書で引用、参照、紹介された第三者の文献等の適切性、真正性、正確性、無誤謬性および他者権利の侵害の可能性
２．

二次譲渡の制限

本書は、利用者がもっぱら自らの用のために利用するものとし、第三者へのいかなる方法による提供も、行わないものとします。他者との共有が可能な場所に本書やそのコピーを置くこと、利用者以外のものに送付・送信・提供を行うことは禁止されます。また本書を、営利・非営利を問わず、事業活動の材料または資料として、そのまま直接利用することはお断りします。
ただし、以下の場合は本項の例外とします。
(1) 本書の一部を、著作物の利用における「引用」の形で引用すること。この場合、出典を明記してください。
(2) 本書を、企業、団体その他の組織が利用する場合は、その利用に必要な範囲内で、自組織内に限定して利用すること。
(3) CSA ジャパンの書面による許可を得て、事業活動に使用すること。この許可は、文書単位で得るものとします。
(4) 転載、再掲、複製の作成と配布等について、CSA ジャパンの書面による許可・承認を得た場合。この許可・承認は、原則として文書単位で得るものとします。
３．

本書の適切な管理(1) 本書を入手した者は、それを適切に管理し、第三者による不正アクセス、不正利用から保護するために必要かつ適切な措置を講じるものとします。
(2) 本書を入手し利用する企業、団体その他の組織は、本書の管理責任者を定め、この確認事項を順守させるものとします。また、当該責任者は、本書の電子ファイルを適切に管理し、その複製の散逸を防ぎ、指定された利用条件を遵守する（組織内の利用者に順守させることを含む）ようにしなければなりません。
(3) 本書をダウンロードした者は、CSA ジャパンからの文書（電子メールを含む）による要求があった場合には、そのダウンロードしまたは複製した本書のファイルのすべてを消去し、削除し、再生や復元ができない状態にするものとします。この要求は理由によりまたは理由なく行われることがあり、この要求を受けた者は、それを拒否できないものとします。
Copyright © 2021 Cloud Security Alliance Japan Chapter3(4) 本書を印刷した者は、CSA ジャパンからの文書（電子メールを含む）による要求があった場合には、その印刷物のすべてについて、シュレッダーその他の方法により、再利用不可能な形で処分するものとしま
す。
４．

その他

その他、本書の利用等について本書の他の場所に記載された条件、制限事項および免責事項は、すべてここに記載の制限事項と並行して順守されるべきものとします。本書およびこの制限事項に記載のないことで、本書の利用に関して疑義が生じた場合は、CSA ジャパンと利用者は誠意をもって話し合いの上、解決を図るものとします。
その他本件に関するお問合せは、info@cloudsecurityalliance.jp までお願いします。
本書執筆編集メンバー
井上 淳
釜山 公徳
平鹿 一久
森田 翔
※五十音順
l

変更履歴
日付

版数

2021 年 10 月 25 日

1.0

変更内容
初版発行

Copyright © 2021 Cloud Security Alliance Japan Chapter41. はじめにパブリッククラウド(以下クラウド)において、民需にて市民権を得るだけでなく、「政府情報システムにおけるクラウドサービスの利用に係る基本方針」にてクラウド・バイ・デフォルトの原則が公開されている通り、パブリックセクターにおいてもクラウドの利用を促進していることが伺える。
なぜ、クラウドか。
クラウドには NIST SP800-146 に記載がある通り未解決の問題があるが、それを補って余る多大なメリットがあり、ビジネスアジリティの向上、バリュークリエイションの実現に欠かせない存在となっている。ただし、ただ単にクラウドを利用するだけではクラウドメリットの享受は極小的になり、デメリットが前面にでてしまう事
態が散見され、例えば、移行戦略で rehost を選択する場合、オンプレミスのサーバー群をそのまま IaaS へと移行するといった手段だ。これでは、ハードウェアにおけるメンテナンスフリーは実現できるものの、責任共有モ
デルでいうところの OS レイヤー以上の責任部分は利用者にあたるため、運用・管理・監視がオンプレミスとク
ラウドとで二重苦になり、クラウドの利用で不幸を事案が発生することは少なくない。
クラウドメリットを最大限享受するためには、PaaS や SaaS といった抽象度の高いサービスモデルであらゆる負荷を軽減し、体制として開発(Dev)と運用(Ops)を最適化し、継続的な改善と価値創造を実現する DevOps に専念すべきである。
ここで留意すべき点は、セキュリティだ。
クラウドは総じてセキュアとは言えるが、責任共有モデルが示す通り、どのサービスモデルにおいても利用者側には責任が生じる。DevOps により継続的な改善と価値創造を実現しても、攻撃者によりシステムやサービスの停止、最悪の場合は顧客情報や機密情報等の漏洩に繋がり、信頼の失墜や収益の激減にいたることが懸念される。
このためには DevSecOps(SecDevOps)が有効だと考えるが、DevSecOps を実現させるための情報が乏しい。
実現の課題を解決するため、クラウドセキュリティ WG では、クラウドセキュリティアライアンスの成果物である「クラウドの重大セキュリティ脅威 11 の悪質な脅威」を用いて、脅威を起点としたユースケースを整理し、利用者がよりイメージをつきやすくする一助となるドキュメントの作成に踏み切った。
DevSecOps の実現を容易にすることに寄与できれば幸甚である。

日本クラウドセキュリティアライアンス
クラウドセキュリティワーキンググループ
リーダー 釜山 公徳
Copyright © 2021 Cloud Security Alliance Japan Chapter

52. 検討指針
2.1. 目的
Cloud Security Alliance (CSA) において、クラウドコンピューティングのためのセキュリティガイダンス(以下、ガイダンス)において DevSecOps の重要性を説いている。現状、実環境へ DevSecOps を落とし込むにあた
り、公開されている具体的な情報が少ない。ここで、ユースケース毎に DevSecOps を当て嵌め、実現性の向上に寄与する。

2.2. 前提
以下 3 事項を前提とする。
① 記載の方針
ガイドラインの要約、ならびにワーキンググループにて独自に解釈したものとする。
② DevSecOps における解釈の正確性
現状、知り得る範囲で考察して執筆しているため、正確性の保証はない。
③ 全体の記載粒度
ケース毎に担当を割り振り、執筆者のパッションを重視しているため、粒度に相違を許容している。
[DevSecOps を踏まえた対処] の記載内容は、ケース毎に完結することを前提とし、同じ項目でもケースが異なれば概要と対応例が異なる。ただし、他ケースの引用する場合はその限りでは無い。
④ 対応例の内容
具体性を出すため、プロダクトやクラウドサービスを記載するが、全ての対応例に一律に記載するのではなく、必要に応じて記載することとする。
クラウドサービスは執筆時点での名称とし、利用可能なリージョンは意識しない。

Copyright © 2021 Cloud Security Alliance Japan Chapter

6

3. ユースケース(クラウド重大セキュリティ脅威 11 の悪質な脅威)
3.1. ケース 1: データ侵害
3.1.1. 概要
データ侵害とは、機微情報、保護情報、機密情報が外部に公開されることであり、勝手に閲覧、盗用など、権限のない人によってデータが使用されてしまうものである。
データ侵害は、標的型攻撃のほか、人的エラーやアプリケーション脆弱性などが起因して発生する。

3.1.2. ビジネスインパクト
データ侵害は、企業の信頼の低下をはじめ、以下のような影響をもたらす。
・ 評価、信頼の影響・ 競合他社に対する知的財産の漏洩
・ 金銭的損失につながる規制の影響
・ ブランド価値の低下
・ 法的および契約上の責任の発生・ 対応に関わる金銭的損失

3.1.3. 想定事例と実例「クラウド重大セキュリティ脅威 11 の悪質な脅威」に記載のある事例として以下が挙げられる。
Ø2018 年、Timehop 社はクラウド環境の侵害により、ユーザー2,100 万人分のデータ侵害にあった。

Ø

2016 年後半、Uber 社は AWS アカウントのハッキングにより、ユーザー5,700 万人の個人情報に関するデータ侵害が発生した。

Ø2019 年、Voipo 社は 700 万件の顧客通話記録、600 万件の SMS ログ、認証情報を含む内部ドキュメントを意図せず公開していた。

3.1.4. 当問題に対するポイントと対応策「データ侵害」における対応策の第１のポイントは、当該システムが取り扱うデータのプロファイルを明確にしておくことである。これには、データ管理表としてアプリケーションやネットワークに常時または一時的に存在するデータを明らかにし、データフローの文書化、データタイプ、価値、機微性、重要性に基づいて機密区分を付しておくことが含まれる。これにより、データ侵害に対する対策を適切に維持するとともに、万一の侵害発生の影響の限定を図ることが可能になる。
第２のポイントは、データセキュリティを確保するためのポリシーと手順を確立し、それを維持することである。特に、複数のシステムや取引を構成する機能をまたがる場合に、データの機密性、完全性、可用性を確保できるように留意しなければならない。また、システムにアクセスするすべての人に関する ID 情報を保管・管理し、個人のアクセスレベルを決定できるようにしなければならない。ポリシーは影響を受ける全ての関係者がいつでもレビューできるようにし、事業責任者により承認を受けることが必要である。
第３のポイントは、暗号プロトコルの適切な使用と鍵管理である。
機微なデータは、ストレージ内、データ使用時、及びデータの送受信時に適切な暗号プロトコルにより暗号化されなければならない。また、鍵の生成から廃棄、更新に至るライフサイクルを管理し、安全な鍵生成に適した
Copyright © 2021 Cloud Security Alliance Japan Chapter

7

アクセス制御、鍵の交換及び保管を実現しなければならない。クラウド事業者が提供するマネージド HSM（ハードウェア暗号モジュール）サービスを活用することが有効である。鍵の管理と鍵の使用は、異なる責務として分離されなければならない。
最後のポイントは、データフォーカスリスクアセスメントの実施である。
データガバナンスの要求事項に従い、リスクアセスメントを事前に定められた間隔、及びシステムを変更した
際に実施しなければならない。アセスメントには、機微なデータがどこで保管され送受信しているかの認識、定められた保存期間及び使用終了時の廃棄に関する要求事項への準拠、データの分類ならびに許可されていない使用、アクセス、紛失、破壊、改竄からの保護に関する事項が含まれる。

3.1.5. DevSecOps サイクル
アプリケーションとインターフェースセキュリティ、変更管理と構成管理、データセキュリティと情報ライフ
サイクル管理、暗号化と鍵管理、ガバナンスとリスク管理、アイデンティティとアクセス管理から主要なアクティビティを抽出し、DevOps サイクルに対応策をマッピングしている。

１・データセキュリティポリシー・手順の確立と維持・データ管理表の整備
・鍵管理ポリシーの確立

Sec

４・ インシデント対応計画策定

２・暗号プロトコルの適切な使用と実装
・ インタフェース標準への準拠
・完全性チェックルーチンの実装
・変更管理の実施
・データ処理のポリシーの確立と実装

５

Dev

Ops

３

・顧客アクセス要求に対する管理・許可に基づくデータの取り扱い
・ライフサイクルを通じた鍵管理
・ID管理

６

・ 脆弱性診断・ ペネトレーションテスト

・ データフォーカスリスクアセスメント

3.1.6. DevSecOps を踏まえた対処
3.1.5.の図内の対応の詳細を以下に記載する。
項番

項目

概要

対応例

1

データセキュリティポリ

複数のシステムや取引を構成する機・以下データセキュリティポリシ

シー・手順の確立と維持能をまたがる際、データの機密性、完ーを整備する。

全性、可用性を確保できるようにデー-基本方針

タセキュリティのポリシー及び手順-対策基準を確立する。

-管理体制

ポリシーは影響をうける全ての関係

・以下データセキュリティ手順を者がいつでもレビューできるように整備する。

し、事業責任者により承認を受けてお-データ資産管理手順

く。

-アクセス制御認証手順-機器利用手順

Copyright © 2021 Cloud Security Alliance Japan Chapter

8

-鍵管理手順
データ管理表の整備

データ管理表としてアプリケーショ

・データ管理表を整備する。

ンやネットワークに常時または一時・データフロー図を整備する。

的に存在するデータのデータフローを作成し、文書化する。
また、データ及びデータを含むオブジ
ェクトに対して、データタイプ、価値、
機微性、重要性に基づいて機密区分を付しておく。
鍵管理ポリシーの確立

組織として鍵管理に関するポリシー

・以下鍵管理ポリシーを整備する。

を確立する。鍵には識別可能な所有者-使用アルゴリズムを対応づけておく。また、鍵の管理と-ライフサイクル

鍵の使用は、異なる責務として分離す-アクセス方法る。

-保管・配布-バックアップ

2

暗号プロトコルの適切な機微なデータについて、ストレージ・TLS を使用する。

使用と実装

内、データ使用時、及びデータの送受・HSM(Hardware Security Module)

信時の暗号化を行う。暗号化には、オサービスを使用する。以下、パブリ

ープン、検証済の標準アルゴリズムをッククラウドのサービス例。

利用する。

-AWS CloudHSM

クラウド事業者が提供するマネージ-Azure Dedicated HSM

ド HSM サービスを活用することが有-Google Cloud HSM

効である。
インターフェース標準へプログラム間のインターフェースに

・以下のような標準化された APIの準拠

は、業界の認める標準に基づいた設を使用する。

計、開発及び導入を行う。当該インタ-(FAPI) Financial-grade APIーフェースは該当する法的及び規制-Open Banking API

を遵守する。
完全性チェックルーチン

データの入出力について、マッチングの実装

やエディットチェックなどデータ完

変更管理の実施・完全性確認ツールを使用する。
-Tripwire

全性をチェックするためのルーチン・エディットチェックツールを使を実装する。

用する。

システム間のインターフェース変更

・変更管理ポリシーを整備する。

に関わる設計、及び設定の変更を行う

・変更管理手順を整備する。

場合は、確立されたポリシーと手順に基づいて実施する。
データ処理のポリシーのデータ、及びデータを含むオブジェク

・情報の分類体系を整備する。

確立と実装

トのラベリングを確立されたポリシ・タグ付け機能を実装する。

ーに基づいて実施する。データをまと・メタデータ付与する。

Copyright © 2021 Cloud Security Alliance Japan Chapter

9めて格納するオブジェクトには、ラベルを継承して保持する仕組みを実装
する。
3

脆弱性診断

公開されるサービスに対してデータ

・対象サービスに応じて、プラット侵害に対する脆弱性有無を診断する。 フォーム診断とアプリケーション
診断の実施有無を判断し、適切に実施する。
ペネトレーションテスト

公開されるサービスに対してペネト

・適切なエンゲージメントの上、ペレーションテストを行い、攻撃防御・ ネトレーションテストやレッドチ検知の確認を行う。事前に定められたーム演習を実施する。

間隔及びシステム変更時に実施する。
4

インシデント対応計画策

データ侵害に関するインシデントが・インシデント対応計画を整備す

定発生した際の検知、復旧、事後対応まる。

での体制、連絡フロー、各種手順を対-インシデント対応体制

応計画として定める。法律や関連する-連絡フロー

規制、社内規定に準拠する。

-対応プロセス-業務復旧・継続手順

5

アクセス要求に対する管データへのアクセス要求があった場

理

合は、セキュリティ、契約、規制にお左記に同じける要求事項を把握した上で許可を行う。
許可に基づくデータの取データの利用は、影響を受けるデータ

り扱いのすべての顧客からの文書化された左記に同じ許可を必要とする。また、関連する法
律及び規制に従う。本番環境のデータのテスト環境へのコピーは禁止する。
ライフサイクルを通じた鍵の生成から廃棄、更新に至るライフ

鍵管理

サイクルを管理し、安全な鍵生成に適

左記に同じしたアクセス制御、鍵の交換及び保管を実現する。
ID 管理

システムにアクセスするすべての人

左記に同じに関する ID 情報を保管・管理し、個人のアクセスレベルを決定できるよ
うに管理する。
6

データフォーカスリスク

データガバナンスの要求事項に従い、 ・以下アセスメントを実施する。

アセスメントアセスメントを実施する。アセスメン-データ保管状況

トでは、機微なデータがどこで保管さ-データ廃棄状況

れ送受信しているか、データ廃棄が要-データ使用状況

求事項に準拠して行われているか、データの分類に従い、許可されていない
Copyright © 2021 Cloud Security Alliance Japan Chapter

10使用が行われていないか、紛失/破壊/改竄が発生していか確認を行い、データ侵害に焦点をあてたリスク要因の特定と評価を行う。リスクアセスメ
ントを事前に定められた間隔、及びシステムを変更した際に実施する。

Copyright © 2021 Cloud Security Alliance Japan Chapter

113.2. ケース 2 設定ミスと不適切な変更管理
3.2.1. 概要
設定ミスは多くの場合、悪意ある活動に対して脆弱な状況を生む。これには、セキュリティ保護されていない
データストレージ、過剰なアクセス権限、デフォルトから変更されないままの資格情報や設定、標準セキュリテ
ィ制御の無効化、パッチの未適用、ロギングや監視の無効化、ポートやサービスへの無制限のアクセスなどが含まれる。
適切な変更管理の欠如は、設定ミスの一般的な原因となる。
クラウド環境では、従来の変更プロセスより変更の制御が困難になる。インフラストラクチャの要素はソフト
ウェアに抽象化され、変更ライフサイクルはごく短時間になるなど複雑さが増しているため、このような環境下
では、変更管理と修復のためのアジャイルでプロアクティブなアプローチが必要になる。

3.2.2. ビジネスインパクト
設定ミスによるビジネスインパクトは、設定ミスの内容、それが検出・緩和される速度により深刻度は変わる
が、最も一般的な影響は、クラウドに保存されているデータの漏洩となる。

3.2.3. 想定事例と実例「クラウド重大セキュリティ脅威 11 の悪質な脅威」に記載のある事例として以下が挙げられる。
Ø

2017 年、Amazon S3 の設定ミスにより、データ分析会社 Alteryx 社所有のデータが公開状態になっていることが発覚した。このデータには Experian 社の調査情報や米国国税調査局のデータ 1 億 2300 万人分が含まれていた。

Ø2018 年、データベースサーバーの設定ミスにより、Exactis 社が所有する 2 億 3000 万人の個人データを含むデータが公開状態になっていることが発覚した。

Ø2018 年、rsync サーバの設定ミスにより、Level One Robotics 社は GM、フォード、テスラ、トヨタな
ど 100 社以上の機密情報を誰でもアクセスできる状態にしていた。

3.2.4. 当問題に対するポイントと対応策「設定ミスと不適切な変更管理」の対応策の第１のポイントは、変更管理ポリシーとベースラインの確立である。
全ての変更に対して、リリースされる前に登録された変更要求や顧客の承認を全て満たしていることを保証できるよう変更管理ポリシー、及び手順を策定することが望ましい。また、セキュリティのベースラインとなる要求事項を定め、標準的な設定から逸脱する場合は、変更管理ポリシーに従って承認を受けなければならないようにする。これらは、クラウド特有の抽象度・ライフサイクルの速度に対応できるよう考慮する。
第２のポイントは、品質検査の実施である。ベースライン、テスト及びリリース基準を備えた品質検査により、定義されたセキュリティ品質基準を満たせるようにする。各クラウド事業者から提供される設定の自動チェック
ツールも併せて利用することも有効である。また、すべての変更を記録し、仮想化されたインフラの変更実績を確認できるようにする。
第３のポイントは、関係者に対する訓練および資格証明と職務の分離である。セキュリティ意識向上の訓練プ
ログラムを策定し、ポリシー、手順、プロセスに対する意識向上を図る。また、適切な身元確認、権限付与を行
Copyright © 2021 Cloud Security Alliance Japan Chapter

12うとともに、職務分離方針に基づき、実施できる業務を制限する。
最後のポイントは、OS 堅牢性と基本管理の徹底である。各システム、コンポーネントは業務に必要十分なポー
ト、プロトコル、サービスのみを提供するようにする。また、クラウド事業者が提供する境界防御、モニタリン
グ、ログ収集等のサービスをベストプラクティスに基づき活用する。

3.2.5. DevSecOps サイクル
変更管理と構成管理、データセキュリティと情報ライフサイクル管理、暗号化と鍵管理、ガバナンスとリスク管理、人事、アイデンティティとアクセス管理、インフラと仮想化のセキュリティから主要なアクティビティを抽出し、DevOps サイクルに対応策をマッピングしている。

１・ 変更管理ポリシーとベースラインの確立
・ 訓練／認識向上
・ 資格証明と職務の分離

Sec４・ 変更管理環境整備
・ トレーニング２

・ 品質検査・ OS堅牢性と基本管理・ 設定の自動化

Dev

Ops

３

５

・ 変更検知・ ネットワーク監視

６

・ 脆弱性診断・ ペネトレーションテスト

・ リソースの継続的検査
・ リアルタイムの問題修正

3.2.6. DevSecOps を踏まえた対処
3.2.5.の図内の対応の詳細を以下に記載する。
項番

項目

概要

1

変更管理ポリシーとベー

リリースされるサービスに関して、影スラインの確立

響度や優先順位を定義する。

対応例
左記に同じ

全ての変更に対して、リリースされる
前に登録された変更要
求や顧客の承認を全て満たしていることを確認する。
セキュリティのベースラインとなる要求事項を定め、標準的な設定から逸脱する場合は、変更管理ポリシーに従って承認を受けるように定める。
訓練／認識向上

関係者に対するセキュリティ意識向・セキュリティ訓練（セキュリティ

上の訓練プログラムを策定し、必要に基礎など）の実施応じてその受講を義務付ける。ポリシ・レッドチーム演習／TLPT の実施

Copyright © 2021 Cloud Security Alliance Japan Chapter

13

ー、手順、プロセスに対する意識向上
及び定期的更新を実現する。
資格証明と職務の分離

適切な身元確認、権限付与、アクセス

・アクセス管理ポリシーの設定管理を行うためのポリシー及び手順

・身元確認方法の確立を確立し、これらを補強するためのプ
ロセスと技術的対策を実装する。
2

品質検査

ベースライン、テスト及びリリース基・以下（例）のサービスを利用した準を備えた品質検査により、定義され管理を実施た品質基準を満たせるようにする。ク-AWS Blueprints

ラウド事業者毎に用意された設定の-Azure Security Center, Azure

自動チェックツールも併せて利用す

Blueprints

ることが有効である。
OS 堅牢性と基本管理各システム、コンポーネントが業務に・以下（例）のサービスを利用した

必要十分なポート、プロトコル、サー管理を実施

ビスのみを提供するように設計・設定-AWS Trusted Advisor

する。また、クラウド事業者が提供す-Azure Advisor

る境界防御、モニタリング、ログ収集-Google Security Command

等のサービスをベストプラクティス

Centerに基づき活用する。
設定の自動化

設定をソフトウェアで定義し、その変

左記に同じ

更をパイプラインなど自動化した手続きで実施する。
3

脆弱性診断

公開されるサービスに対して脆弱性・対象サービスに応じて、プラット診断を実施し、脆弱性の有無を確認す

フォーム診断とアプリケーションる。

診断の実施有無を判断し、適切に実施する。

ペネトレーションテスト

公開されるサービスに対してペネト

・適切なエンゲージメントの上、ペレーションテストを行い、攻撃防御・ ネトレーションテストやレッドチ
4

変更管理環境整備

検知の確認を行う。

ーム演習を実施する。

設定自動化、検査、リアルタイムの問

左記に同じ

題修正などを実施するために、その時点で最適なテクノロジーを採用し、利用環境を整備する。
トレーニング
5

変更管理対象者に対し、設定および環境維持に

・IT サービスマネジメントに関す必要なトレーニングを実施する。

るトレーニングを実施する。

変更管理ポリシー及び手順に従って・変更記録（ログ）を収集・管理し、変更管理を実施する。すべての変更を

定期的なチェックを行う。

記録し、承認された変更以外の変更が実施されないようチェックする。
ネットワーク監視

信頼できるネットワークと信頼でき・以下（例）を導入し、ネットワー

Copyright © 2021 Cloud Security Alliance Japan Chapter

14

ないネットワーク間のトラフィック

6

リソースの継続的検査

ク制御・監視を実施する。

を制限し、監視を行う。不正なトラフ-ファイアウォールィックが検知された場合は、通信遮断-IDS/IPSなどの対処を行う。

-WAF

設定が適切に保たれているか、変更管

左記に同じ理が適切に維持されているか検査を行う。
リアルタイムの問題修正

問題が検知された場合、リアルタイム

・問題発生時に即座に検知する仕に修正を行う。

組みを導入し、適切な対応フローと体制の整備を行う。

Copyright © 2021 Cloud Security Alliance Japan Chapter

15

3.3. ケース 3 クラウドセキュリティアーキテクチャと戦略の欠如
3.3.1. 概要
この問題は、利用者のサービス機能の拡張とセキュリティ施策に対して警鐘を鳴らした内容である。クラウドへ移行する企業が増えている現在、サービス機能の拡張が優先され、不適切なセキュリアーキテクチャだった場
合、攻撃に対するリスクが発生する危険性がある。

3.3.2. ビジネスインパクト
適切なセキュリティアーキテクチャと戦略は、クラウドにおける安全な移動、配置、運用に必要な要素である。
不適切なクラウドアーキテクチャに対してサイバー攻撃が成功すると財務上の損失、信用ダメージ、法的な悪影
響、罰金などのビジネスに対する重大なインパクトを及ぼす可能性がある。

3.3.3. 想定事例と実例「クラウド重大セキュリティ脅威 11 の悪質な脅威」に記載のある事例として以下が挙げられる。
Ø

クラウドストレージにホストしたセキュアでないクラウドサーバにプライベートデータを保管し、サーバの Web アドレスさえ分かっていれば、パスワードなしでデータをダウンロードできる状態だった。
保管しているデータには機密性の高いパスワードや復号鍵が含まれていた。(アクセンチュア、2017 年)

Ø

自動車と連動するアプリに登録しているユーザーの個人情報 5 万人分以上がクラウドサービス上で公開されていた。データを保存するディレクトリの設定を誰でも閲覧できる「公開状態」にしていたのが原因。(本田インド法人、2018 年)

3.3.4. 当問題に対するポイントと対応策
本章では、「クラウドセキュリティアーキテクチャと戦略の欠如」の対応策として、重要なポイントについて記載している。
クラウド戦略の策定
どのような目的に対して、クラウド戦略を定義し、クラウド展開・利用するかを検討する。
セキュリティポリシーの定義利用するクラウドサービスのアーキテクチャにあわせ、情報セキュリティ関連の法律や規定、ガイドラインを参考に、クラウドサービスの実態にあったセキュリティポリシー（監視ポリシー、運用ポリシー等）
を策定する。
定期的な脅威モデリングの実施
開発対象のソフトウェアがどのような脅威にさらされており、攻略の可能性を持ちうるか洗い出す活動を定期的に実施する。
システムの運用状況の把握
セキュリティポリシーに則って稼働状況、運用状況等を定期的に把握できるような施策を講じる

3.3.5. DevSecOps サイクル
セキュリティポリシーの策定とその管理にフォーカスし、DevOps サイクルに対応策をマッピングしている。
Copyright © 2021 Cloud Security Alliance Japan Chapter

16

3.3.6. DevSecOps を踏まえた対処
3.3.5.の図内の対応の詳細を以下に記載する。
項番

項目

概要

1

セキュリティポリシーの利用するクラウドサービスのアーキ

定義

テクチャにあわせ、情報セキュリティ

対応例
左記に同じ

関連の法律や規定、ガイドラインを参考に、クラウドサービスの実態にあったセキュリティポリシー（監視ポリシー、運用ポリシー等）
を策定する。
リスク評価と脅威分析想定されるリスクと脅威の検討

公開されているフレームワーク等を参考に、脅威・リスク分析を実施する。
・STRIDE（for Microsoft）
・DREAD

クラウド戦略の策定目的に対して、どのようなクラウド戦

例としては以下のような計画が挙略を定義し、クラウド展開・利用するげられる。

かを検討する。

・導入（投資）効果の検討
・ワークロードの配置計画
・管理ツールの検討
・SaaS 統合・連携の検討

2

セキュアアーキテクティ

不正なアクセスを防止するための策

外部からの不正侵入に対応できる

ングを講じる（IDS/IPS、WAF など）

ソリューションの導入を検討する。

Copyright © 2021 Cloud Security Alliance Japan Chapter

17

・IDS/IPS
・WAF
・DDoS protection
暗号プロトコルの適切な機微なデータについて、ストレージ・TLS を使用。

使用と実装

内、データ使用時、及びデータの送受・HSM サービスを使用。以下、パブ信時の暗号化を行う。暗号化には、オリッククラウドのサービス例。

ープン、検証済の標準アルゴリズムを-AWS CloudHSM利用する。

-Azure Dedicated HSM

クラウド事業者が提供するマネージ-Google Cloud HSM

ド HSM サービスを活用することが有効である。
インターフェース標準へプログラム間のインターフェースに

・以下のような標準化された APIの準拠

は、業界の認める標準に基づいた設を使用。

計、開発及び導入を行う。当該インタ-Financial-grade APIーフェースは該当する法的及び規制-Open Banking API

上の遵守義務に従う。
完全性チェックルーチン

データの入出力について、マッチングの実装

やエディットチェックなどデータ完

変更管理の実施・完全性確認ツールを使用。
-Tripwire

全性をチェックするためのルーチン・エディットチェックツールを使を実装する。

用。

システム間インターフェースの変更

・変更管理ポリシーを整備。

に関わる設計及び設定の変更を行う

・変更管理手順を整備。

場合は、確立されたポリシーと手順に基づいて実施する。
データ処理のポリシーのデータ及びデータを含むオブジェク

・情報の分類体系を整備。

確立と実装

トのラベリングを確立されたポリシ・タグ付け機能を実装。

ーに基づいて実施する。データをまと・メタデータ付与。

めて格納するオブジェクトには、ラベルを継承して保持する仕組みを実装する。
3

コンプライアンス準拠

監督省庁における法的要件や、業界団

・以下サービスで、コンプライアン

体のコンプライアンスを基に、セキュス準拠状況を確認する。

リティポスチャを評価する。

-AWS Artifact-Azure Policy、Azure
Blueprints-Google Compliance Reports
Manager

ペネトレーションテスト

公開されるサービスに対してペネト

・適切なエンゲージメントの上、ペCopyright © 2021 Cloud Security Alliance Japan Chapter

18レーションテストを行い、攻撃防御・ ネトレーションテストやレッドチ検知の確認を行う。事前に定められたーム演習を実施する。
。

間隔及びシステム変更時に実施する。
脆弱性診断

公開されるサービスに対してデータ

・対象サービスに応じて、プラット侵害に対する脆弱性有無を診断する。 フォーム診断とアプリケーション
診断の実施有無を判断し、適切に
実施する。
4

5

インシデント対応計画策

データ侵害に関するインシデントが定発生した際の検知、復旧、事後対応ま-インシデント対応体制

での体制、連絡フロー、各種手順を対-連絡フロー

応計画として定める。法律や関連する-対応プロセス

規制、社内規定に準拠する。

-業務復旧・継続手順

鍵管理設計/運用

・インシデント対応計画を整備。

・認証、署名、データ暗号化などの用・HIPAA、FedRAMP などのコンプラ途に応じ、鍵のライフサイクル（生成、イアンス準拠が必要なケースで配布、更新、失効、再発行などのイベは、サービスとして用いる暗号ント）を踏まえた運用設計を行う。

鍵について、クラウド基盤が提供する鍵管理サービス(HSM)の採用を検討する。

ID ライフサイクル設計/

ID を適切に管理するための運用管理

・不要な ID や権限が残存していな運用

方法を検討する。

いか確認するため、定期的に棚卸を実行する。
・不要な ID や権限を残さないために、利用者による申請ベースの処理だけではなく、人事イベントやワークフロー等と連動したメンテ
ナンスも検討する。

6

アクセス履歴の監視

資産へのアクセス履歴を監視し、不正・以下、監視項目例。

なアクセスがないか確認する。また、-アクセス試行の傾向監視を行うことでの不正行為の抑止-許可されていないリソースへ

を行う。

のアクセス
-業務時間外のアクセス-許可外の端末・環境からのアクセス

設定不備の検査

設定不備などにより、意図せず公開さ・セキュリティ診断（設定不備の有れている資産などがないか確認する。 無確認）の実施
侵入検知（不正リクエス

内外部からの不正な侵入の有無をモ・セキュリティシステム（センサト）ニタリングする。

ー）からのアラートチェックを行う。

セキュリティ評価

実施している施策に対して、定期的な・組織の対策状況を評価するもの

評価（実施状況、妥当性、過不足など） として以下が挙げられる。
Copyright © 2021 Cloud Security Alliance Japan Chapter

19

を実施する。

-ISMS 適合性評価制度-情報セキュリティ監査-情報セキュリティ対策ベンチ
マーク-セキュリティ製品の評価（ IT
セキュリティ評価及び認証制度、
暗号モジュール試験及び認証制度など）

Copyright © 2021 Cloud Security Alliance Japan Chapter

203.4. ケース 4 ID・資格情報・アクセス・鍵の不十分な管理
3.4.1. 概要
資格情報を適切に保護できていないことにより、正規ユーザーへのなりすましによるデータ侵害や、管理機能の乗っ取り、移動中のデータの盗聴、正規のサイトと見せかけた悪意のあるソフトウェアのリリースなどのセキュリティインシデントが発生する。

3.4.2. ビジネスインパクト
データに対する許可されていないアクセスが可能になることで、組織やエンドユーザーに対して壊滅的なダメージを与える可能性がある。

3.4.3. 想定事例と実例「クラウド重大セキュリティ脅威 11 の悪質な脅威」に記載のある事例として以下が挙げられる。
Ø2018 年 12 月、ドイツの学生による脆弱なパスワードに対するハッキングにより、1000 人の議会メンバ
ー、ジャーナリスト、その他の著名人に紐付けられた電話番号、テキストメッセージ、写真、 クレジッ
トカード番号、その他のデータが盗難され、Twitter などを通じて拡散された。

Ø2017 年 9 月 25 日、デロイトは、脆弱な管理者 e メールアカウントが原因でグローバル e メールサーバが侵害されたと発表した。攻撃者には特権が与えられ、「全てのエリア」に対して無制限のアクセスが可能になったと推測されている。管理者アカウントに対して二段階認証プロセスは採用されていなかった。

Ø2017 年 5 月 31 日、ある攻撃者が、 ID・パスワードを管理するサービスを提供している OneLogin のAWS 鍵を利用し、同社の AWS プラットフォームにアクセスした。同社はその侵害を検知し、侵害を止めるために数分以内に対処を行った。

Ø

GitHub から収集されたクラウドサービスの資格情報によって、アカウントがハイジャックされた。プ
ロジェクトの立ち上げから 36 時間以内に発見され悪用されたケースも存在した。

Ø

情報セキュリティソリューションプロバイダの Praetorian は、AWS のコンピューティングパワーを活用したシンプルな方法によりパスワードハッシュをクラックするためのプラットフォームを立ち上げた。

3.4.4. 当問題に対するポイントと対応策
クラウド基盤が提供するセキュリティ機能を把握した上で、万が一の事態に被害を最小限に留めるために最小権限の原則に従うこと、ID や鍵のライフサイクルに合わせた運用ルールを設計段階から意識することが必要である。

3.4.5. DevSecOps サイクル

Copyright © 2021 Cloud Security Alliance Japan Chapter

21

3.4.6. DevSecOps を踏まえた対処
3.4.5.の図内の対応の詳細を以下に記載する。
項番
1

項目

概要

対応例

アクセス管理ポリシーの職務分掌を適切に行い、役割にあった・ロール（全体管理者、運用管理者、検討

権限を定義する。

オペレータ、バックアップ＆リカ
バリ、一般ユーザーなど）の定義
・運用オペレーションにおける、不必要な高権限 ID（root など）の排除・システム管理者やテナント管理者などの強い権限を持つアカウン
トには、利用者のデータを操作する権限を与えない。
・不要な ID や権限は残さない。

2

従業員に対するセキュリ

従業員に対してセキュリティに対す

ティ意識向上トレーニン

る意識向上を目的としたトレーニン

グの実施

グを実施する。

認証手段の検討

特権 ID の認証については、まず多要・認証手段を検討する上での考慮（多要素認証の採用）

素認証を提供しているサービス事業

事項（例）として、以下のようなも者を選定し、設定を有効にすることがのが挙げられる。

望ましい。

左記に同じ

-初回登録時と 2 回目以降の 2 つ

また一般利用者の認証については、サのユースケースについて検討が必ービスレベルや利用者のリテラシー

要。

を考慮して認証方式を検討する。

-管理機能のアクセス元 IP アド
レスを制限する。
-追加コストがかけられない場

Copyright © 2021 Cloud Security Alliance Japan Chapter

22合などは、SNS 認証やメールアドレ
ス認証など、比較的低コストで実現可能な認証手段を検討する。
-モバイルアプリの場合、2 回目以降の認証については端末認証の採用を検討する。
-認証強化を他のサービス（IDaaS など）に委託し、シングル
サインオン環境を構築する。
パスワードポリシーの検

原則、パスワードのみに依存しない認討証方式を採用すべきであるが、やむを左記に同じ得ない場合、十分に複雑で安全なパス
ワードポリシーを設定すべきである。
パスワード忘れに対応するための機能が、アカウントハイジャックなどの攻撃手段として利用されないよう、十分に注意が必要である。
3

鍵管理設計と運用

認証、署名、データ暗号化などの用途

・HIPAA、FedRAMP などのコンプラに応じ、鍵のライフサイクル（生成、 イアンス準拠が必要なケースで配布、更新、失効、再発行などのイベは、サービスとして用いる暗号鍵ント）を踏まえた運用設計を行う。

について、クラウド基盤が提供する鍵管理サービス(HSM)の採用を検討する。

ID ライフサイクル設計/

ID を適切に管理するための運用管理

・不要な ID や権限が残存していな運用

方法を検討する。

いか確認するため、定期的に棚卸を実行する。
・不要な ID や権限を残さないために、利用者による申請ベースの処理だけではなく、人事イベントやワークフロー等と連動したメンテ
ナンスも検討する。

運用ルールの定義システムで対策できない（あるいはコ・実施している内容や利用システ

ストの問題などで対策しきれなかっムに関係するため、システム的なた）リスクについて、運用対処が可能

対応が行えない箇所を整理して、なものは必要に応じて運用ルールや運用ルールを検討する。

利用ルールなどの整備を行う
4

ペネトレーションテスト

公開されるサービスに対してペネト

・適切なエンゲージメントの上、ペレーションテストを行い、攻撃防御・ ネトレーションテストやレッドチ検知の確認を行う。事前に定められたーム演習を実施する。

間隔及びシステム変更時に実施する。
Copyright © 2021 Cloud Security Alliance Japan Chapter

23

5

アクセス履歴の監視

内外部からの不審なアクセスや、ID・アクセスログ監視によって、ログの利用状況を監視し、不正アクセスなイン失敗の増加などの異常を検知

有無を確認できるようにする。

する仕組みを用意する。
・特権ユーザーによる設定変更については、誰がいつ何を変更したのかを監査ログとして保存する。
・root などの高い権限を持つ共有
ID については、実際に誰が利用したのかを特定できるように特権 ID
管理製品の導入も選択肢となる侵入検知（不正リクエス

外部からの不正な侵入の有無をモニ・セキュリティシステム（センサト）

タリングする。

ー）からのアラートチェックを行う。

Copyright © 2021 Cloud Security Alliance Japan Chapter

24

3.5. ケース 5 アカウントハイジャック
3.5.1. 概要
内部者の脅威とは「組織の資産へアクセスする権限を持っているか、またはかつて持っていた個人がその権利を使用し、悪意を持ってあるいは意図せずに、組織に悪影響を及ぼすおそれのある行動を取る可能性」と定義されており、現在のまたは元の従業者、請負業者、信頼しているビジネスパートナーなどの「内部者」が企業内の機密データに不正にアクセスし、情報を取得するような行為が該当する。

3.5.2. ビジネスインパクト
機密情報や知的財産の損失、信頼の低下をもたらす。
システムの停止が伴う場合には、「企業の生産性」に悪影響を及ぼす。
データの損失は、顧客への被害に繋がり、「会社のサービスに対する信頼」を低下させる。

3.5.3. 想定事例と実例「クラウド重大セキュリティ脅威 11 の悪質な脅威」に記載のある事例として以下が挙げられる。
Ø2018 年 6 月、テスラ社において、従業員（妨害者）は、不正なユーザー名を使用し、テスラの製造オペ
レーションシステムで使用されるコードの改ざんを行っていた。また、「大量のテスラの機密データを未知の第三者」に提供していた。

Ø2018 年に、インドのパンジャブ国立銀行の従業員が、SWIFT（銀行間取引システム）の機密パスワードに不正アクセスし、不正取引の仕組みで資金を拠出していた。

Ø

誤設定のクラウドサーバ、ネットワークバックアップインシデント、およびその他の不適切に設定されたシステムが数多く存在しており、おおよそ 20 億件超のレコードが危険な状態に晒されていることが確認された。その中で不正にアクセスされたレコードは、約 7 割に当たると言われている。

3.5.4. 当問題に対するポイントと対応策「内部者の脅威」の対応策の重要なポイントとして、大きく以下のようなものが挙げられる。
システム構築におけるセキュリティ基準の定義・見直し
データへのアクセス権限の定義と管理方法の確立
システム担当者へのシステム活用・運用におけるトレーニングの実施
従業員に対するセキュリティ意識向上トレーニングの実施
情報リソースへのアクセス履歴の定期的な検査
設定誤り等に対する定期的な検査や監査

Copyright © 2021 Cloud Security Alliance Japan Chapter

25

3.5.5. DevSecOps サイクルシステムを構築する際のアカウントセキュリティとアセスメントにフォーカスし、DevOps サイクルに対応策をマッピングしている。

1

アカウントセキュリティ設計• 最小権限の原則• IAMやMFAの設計• アカウント運用設計• トレーサブルな設計• IDaaS利用の検討

Sec

運用監視・保守

Dev

2

Ops 5
アカウントの棚卸し

アセットマネジメント設計
3

4

6

プレセキュリティアセスメント• コンプライアンス準拠• ぺネトレーションテスト
• 脆弱性診断

ポストセキュリティアセスメント• コンプライアンス準拠• ぺネトレーションテスト
• 脆弱性診断3.5.6. DevSecOps を踏まえた対応
5.6.5 の図内の対応の詳細を以下に記載する。
項番
1

項目

概要

対応例

アクセス管理ポリシーの検職務分掌を適切に行い、役割にあっ・ロール（全体管理者、運用管理者、討た権限を定義する。

オペレータ、バックアップ＆リカバ
リ、一般ユーザーなど）の定義
・運用オペレーションにおける、不必要な高権限 ID（root など）の排除・システム管理者やテナント管理者などの強い権限を持つアカウン
トには、利用者のデータを操作する権限を与えない。
・不要な ID や権限は残さない。

IAM や MFA の設計

・ストレージや仮想ネットワーク、・IAM に関するマネージドサービ

IAM など、管理プレーンから設定可能

スやサードパーティ製品を活用す

な IaaS 環境のセキュリティ関連設定

るについて、設定ミスやコンプライア

・公開リソースの配置環境に応じンスルールへの不適合、不適切な権て適切な認証方法・方式（MFA、リス

限昇格を継続的にチェックする仕組

クベース、CAPTCHA、FID など）の定みを導入する。

義を行う。

・リソース（資産）にアクセスするた
Copyright © 2021 Cloud Security Alliance Japan Chapter

26

めの認証方法を検討する。
アカウントの運用設計

アカウント不正利用防止機の方針を・アカウントロックを設定する。

検討する。

・不正な利用が発見された際にリモートロック・ワイプを行える準備を行う。

トレーサブルな設計

インシデント発生時のトレースにあたり「誰が」
、
「いつ」
、
「何を」
、
「どう
したか」を早急に対応可能な設計をする。

以下サービスを利用する。
-AWS Cloud Watch、AWS Cloud
Trail-Azure Activity Log、Azure
Security Center-Google Cloud Monitoring、
Google Security Command Center

IDaaS 利用の検討

管理対象 ID の総数、IdP(Identity

・以下 IDaaS を利用する。

Provider)の総数などの増加に伴う-Azure

管理負荷を軽減するために、一元管

Directory)

理する。

AD(Azure

Active-Cloud Identity-OneLogin2

アセットマネジメント設計

IT アセット情報、並びにアカウント

・以下でサービスを利用する。

情報を収集し、攻撃者による不正操-AWS IAM、AWS Config

作の検知やインシデントレスポンス-Azureに備える。

AD 、 Azure

Security

Center-Cloud IAM、Cloud Identity、Security Command Center3

コンプライアンス準拠

監督省庁における法的要件や、業界

・以下サービスで、コンプライアン

団体のコンプライアンスを基に、セス準拠状況を確認する。

キュリティポスチャを評価する。

-AWS Artifact-Azure Policy、Azure
Blueprints-Google Compliance Reports
Manager

ペネトレーションテスト

公開されるサービスに対してペネト

・適切なエンゲージメントの上、ペレーションテストを行い、攻撃防御・ ネトレーションテストやレッドチ検知の確認を行う。事前に定められーム演習を実施する。

た間隔及びシステム変更時に実施す
る。
脆弱性診断

公開されるサービスに対してデータ

・対象サービスに応じて、プラット侵害に対する脆弱性有無を診断す

フォーム診断とアプリケーションる。

診断の実施有無を判断し、適切に実施する。

4

インシデント対応計画

セキュリティインシデントレスポン

左記に同じ

Copyright © 2021 Cloud Security Alliance Japan Chapter

27スに対応できる体制、対応フロー、シ
ステムを定義、および設計する。
5

アカウントの棚卸し

アカウントの棚卸を行い、退職者や、 ・棚卸対象アカウントの整理を実契約が終了した外部パートナーのふ施ようになったアカウントを削除す-退職者アカウントる。

-外部パートナーアカウント-制限付き（特定の目的で作成したものなど）アカウント-管理者アカウント6

コンプライアンス準拠

監督省庁における法的要件や、業界

・以下サービスで、コンプライアン

団体のコンプライアンスを基に、セス準拠状況を確認する。

キュリティポスチャを評価する。

-AWS Artifact-Azure Policy、Azure
Blueprints-Google Compliance Reports
Manager

ペネトレーションテスト

公開されるサービスに対してペネト

・適切なエンゲージメントの上、ペレーションテストを行い、攻撃防御・ ネトレーションテストやレッドチ検知の確認を行う。事前に定められーム演習を実施する。

た間隔及びシステム変更時に実施す
る。
脆弱性診断

公開されるサービスに対してデータ

対象サービスに応じて、プラットフ

侵害に対する脆弱性有無を診断す

ォーム診断とアプリケーション診る。

断の実施有無を判断し、適切に実施する。

Copyright © 2021 Cloud Security Alliance Japan Chapter

28

3.6. ケース 6 内部者の脅威
3.6.1. 概要
内部者の脅威とは「組織の資産へアクセスする権利を持っているか、またはかつて持っていた個人がその権利を使用し、悪意を持ってあるいは意図せずに、組織に悪影響を及ぼすおそれのある行動を取る可能性」と定義されており、現在のまたは元の従業者、請負業者、信頼しているビジネスパートナーなどの「内部者」が企業内の機密データに不正にアクセスし、情報を取得するような行為が該当する。

3.6.2. ビジネスインパクト
機密情報や知的財産の損失、信頼の低下をもたらす。
システムの停止が伴う場合には、「企業の生産性」に悪影響を及ぼす。
データの損失は、顧客への被害に繋がり、「会社のサービスに対する信頼」を低下させる。

3.6.3. 想定事例と実例「クラウド重大セキュリティ脅威 11 の悪質な脅威」に記載のある事例として以下が挙げられる。
Ø2018 年 6 月、テスラ社において、従業員（妨害者）は、不正なユーザー名を使用し、テスラの製造オペ
レーションシステムで使用されるコードの改ざんを行っていた。また、「大量のテスラの機密データを未知の第三者」に提供していた。

Ø2018 年に、インドのパンジャブ国立銀行の従業員が、SWIFT（銀行間取引システム）の機密パスワードに不正アクセスし、不正取引の仕組みで資金を拠出していた。

Ø

誤設定のクラウドサーバ、ネットワークバックアップインシデント、およびその他の不適切に設定されたシステムが数多く存在しており、おおよそ 20 億件超のレコードが危険な状態に晒されていることが確認された。その中で不正にアクセスされたレコードは、約 7 割に当たると言われている。

Ø

3.6.4. 当問題に対するポイントと対応策「内部者の脅威」の対応策の重要なポイントとして、大きく以下のようなものが挙げられる。
システム構築におけるセキュリティ基準の定義・見直し
データへのアクセス権限の定義と管理方法の確立
システム担当者へのシステム活用・運用におけるトレーニングの実施
従業員に対するセキュリティ意識向上トレーニングの実施
情報リソースへのアクセス履歴の定期的な検査
設定誤り等に対する定期的な検査や監査

Copyright © 2021 Cloud Security Alliance Japan Chapter

29

3.6.5. DevSecOps サイクルシステムを構築する際のデータの管理、アクセス制限、アカウント管理にフォーカスし、DevOps サイクルに対応策をマッピングしている。

3.6.6. DevSecOps を踏まえた対応
3.6.5.の図内の対応の詳細を以下に記載する。
項番
1

項目

概要

管理体制の定義・見直し

組織横断的な管理体制や関連部門の

対応例
左記に同じ

役割を具体化、明文化し、その役割を徹底させる。従業員管理体制に問題がある場合には、適宜見直しを図る
また、業務委託においては、機密情報を提供する際に、提供元から提供先に対して、機密情報の指定またはその保持に必要とされる情報セキュリ
ティ対策の具体的な実施内容を示すことが重要である。
社内制度の見直し

公正な人事評価や適正な労働環境に・作業環境の見直し

より、従業員の不満やストレスを減・作業方法の見直し・効率化

らす（犯行の誘引）を減らすことを目・疲労回復支援施設の検討的とした対応を実施

・職場生活支援施設の検討

情報セキュリティマネジ

資産及びデータを紛失、誤用、許可さ・セキュリティのプログラムは、事

メントプログラムの開れていないアクセス、暴露、改ざん、 業の特性に関わる範囲で以下を定発・実施破壊から保護するために、管理的、技術的、物理的な保護措置を含む情報義する。
-リスク管理Copyright © 2021 Cloud Security Alliance Japan Chapter

30

セキュリティマネジメントのプログ-セキュリティポリシー

ラムを開発し、実施する。

-資産管理-人的セキュリティ
-物理的及び環境的セキュリティ-通信及び運用管理-アクセス制御-情報システムの調達、開発及び保守

2

データの価値と損失影響公開する資産にどのような情報（個の定義

人情報、機微情報）かあるか確認し、左記に同じその情報が外部に漏えいした場合のリスクを検討する。
最小権限の原則に則った職務分掌を適切に行い、役割にあっ・ロール（全体管理者、運用管理者、権限の検討た権限を定義する。

オペレータ、バックアップ＆リカバ
リ、一般ユーザーなど）の定義
・運用オペレーションにおける、不必要な高権限 ID（root など）の排除・システム管理者やテナント管理者などの強い権限を持つアカウン
トには、利用者のデータを操作する権限を与えない。
・不要な ID や権限は残さない。

利用者と公開範囲の定義

リソース（資産）にアクセスする利用・公開するリソースにアクセス可者とリソースを公開する範囲を検討

能な利用者の選定する。

・選定された利用者に公開するリ
ソースの決定認証方法の定義

リソース（資産）にアクセスするため

・公開リソースの配置環境に応じの認証方法を検討する。

て適切な認証方法・方式（MFA、リス
クベース、CAPTCHA、FID など）の定義を行う。

不正利用防止策の検討

アカウント不正利用防止機の方針を・アカウントロックを設定する。

検討する。

・不正な利用が発見された際にリモートロック・ワイプを行える準備を行う。

3

セキュリティチェック

公開するリソース（資産）に対する認・セキュリティ診断（設定不備の有（認証・アクセス権限）証および、アクセスにおいて、意図し無確認）の実施

たものになっているか確認する。
4

従業員に対するセキュリ

従業員に対してセキュリティに対す

ティ意識向上トレーニン

る意識向上を目的としたトレーニン

左記に同じ

Copyright © 2021 Cloud Security Alliance Japan Chapter

31

5

グの実施

グを実施する。

システム担当者へのシス利用するシステムに関する知識を向テム活用・運用における上させるためのトレーニングを実施

トレーニングの実施する。

アカウントの棚卸し

アカウントの棚卸を行い、退職者や、 ・棚卸対象アカウントの整理を実契約が終了した外部パートナーのふ

左記に同じ

施

ようになったアカウントを削除す-退職者アカウントる。

-外部パートナーアカウント-制限付き（特定の目的で作成したものなど）アカウント-管理者アカウント

6

アクセス履歴の監視

資産へのアクセス履歴を監視し、不・以下監視項目例

正なアクセスがないか確認する。ま-アクセス試行の傾向

た、監視を行うことでの不正行為の-許可されていないリソースへの抑止を行う。

アクセス-業務時間外のアクセス-許可外の端末・環境からのアクセス

設定不備の検査

設定不備などにより、意図せず公開・セキュリティ診断（設定不備の有されている資産などがないか確認す無確認）の実施る。

Copyright © 2021 Cloud Security Alliance Japan Chapter

32

3.7. ケース 7 安全でないインターフェースと API
3.7.1. 概要
サービスの利用者がクラウドサービスを管理し、情報の授受ができるよう、ソフトウェアユーザーインターフ
ェースや API を公開するが、認証やアクセス制御から暗号化や動作の監視まで、これらのインターフェースは、セキュリティポリシーの隙間をかいくぐる偶発的あるいは悪意ある攻撃を防ぐように設計がされていない場合、
誤った使われ方や、さらに深刻な場合にはデータ漏洩を引き起こす可能性がある。
API やユーザーインターフェースは、一般的にシステムの中で最も外部にさらされる部位であり、信頼できる組織の外側から利用可能なパブリック IP アドレスを付与された唯一の方法であるため、これらを攻撃から防御するためにセキュリティ・バイ・デザインと適切な制御が必要となる。

3.7.2. ビジネスインパクト
セキュリティが弱いインターフェースや API に依存すると、機密性、完全性、可用性、そして説明責任に関する様々なセキュリティリスクが発生する。

3.7.3. 想定事例と実例「クラウド重大セキュリティ脅威 11 の悪質な脅威」に記載のある事例として以下が挙げられる。
Ø

Facebook は、2018 年 9 月 28 日に 5,000 万を超えるユーザーに影響を及ぼすデータ漏洩があったことを発表した。報道によると、1 年以上前の 2017 年 7 月に Facebook のコードに資格情報の窃取の脆弱性が埋め込まれており、同社は、どのような情報が盗まれ、他にどの程度の数のユーザーカウントの情報が漏れたか、わからないことを認めた。

3.7.4. 当問題に対するポイントと対応策
API を安全な状態に保つことが必要である。
そのための取り組みとして、構成管理、テスト、監査、異常活動防止等のような入念な管理を行い、API キーを適切に保護し、再利用を避けることを確実に実施する。
また、標準的に公開された API フレームワーク※の利用を検討し、安全な API を準備することも重要である。
※Open Cloud Computing Interface (OCCI) , Cloud Infrastructure Management Interface (CIMI)

Copyright © 2021 Cloud Security Alliance Japan Chapter

33

3.7.5. DevSecOps サイクル
外部に公開されるインターフェースや API にフォーカスし、DevOps サイクルに対応策をマッピングしている。

3.7.6. DevSecOps を踏まえた対処
3.7.5.の図内の対応の詳細を以下に記載する。
項番

項目

概要

対応例

1

認証・認可方式の検討

アクセス認証、認可、署名、ライフサ

・OAuth（OpenID Connect）によるイクル管理をどのように行うか検討

認証方法の検討する。

・環境に応じた認可フロー（OAuth）

各ユーザーが必要な情報以外を読みの定義

書きできないようにするため、各ユー
ザーやアプリケーションが保持する権限レベルを管理、保守する必要がある。
アクセス管理設計

データ保護方式の検討

当該 API（リソース）を誰に対して提・利用者の検討

供するのか、それが適切かを検討す

・利用者に対する提供リソースのる。

精査

提供するデータや、API を利用して取・エンドツーエンドでの適切な暗得したデータの暗号化を検討する。ま

号化処理（TLS）、セッション管理のた、ネットワーク上の通信の暗号化も実施

併せて検討する。

・Mutual TLS に依存したセキュリ
ティ強化仕様への準拠

トークン管理の設計

API キー、トークンの保護、提供期限

・利用体系（参照系・更新系）に応Copyright © 2021 Cloud Security Alliance Japan Chapter

34

設定を適切に行うよう設計する。

じた有効期限やリフレッシュトー
クンの利用有無を検討する。
・トークンの失効管理を行う。

利用制限の定義

ユーザーの API 呼び出し回数を要件

左記に同じに応じて制限することを検討する。
監査記録の検討

API を利用する際にユーザーを一意左記に同じに識別し、その呼び出しと戻り値のス
テータスを監査記録としてログに記録する方法を検討する。
提供リソースの検討

API の形態において提供するリソー

・API の形態例

スの質をとらえた保護要件の検討を-パブリック API（不特定多数）行う。

-アクウェインタンス API（資格を有する法人、個人）-メンバーAPI（規範性のあるコ
ミュニティ）-パートナーAPI（個別契約締結先）-プライベート API（内部）2

SCA(Software

Composition

Analysis)

アプリケーションが利用するライブ

ソフトウェア静的解析ツール等を

ラリ、コンポーネントに対して脆弱性利用したテストを実施が報告されていないかをチェックする

3

セキュアアーキテクティ

不正なアクセスを防止するための策・外部からの不正侵入に対応できングを講じる（IPS、WAF など）

るソリューションの導入を検討す

また、API ゲートウェイを利用したエる。

ッジ処理等も検討する。

-IDS/IPS-WAF-DDoS protection

4

動作テスト（脆弱性診断） リアルタイムなコードのチェックや動的なアプリケーション解析を実施

・IAST・DAST ツールを利用し、機能テストを実行する。
5

ペネトレーションテスト

公開される API に対してペネトレー

・公開 API に対するペネトレーシ

ションテストを行い、攻撃防御・検知ョンテストの実施の確認を行う。
6

セキュリティパッチ管理

定期的にセキュリティパッチの公開

左記に同じ有無をチェックし、必要に応じて適用する。
7

ペネトレーションテスト

公開される API に対してペネトレー

・公開 API に対するペネトレーシ

ションテストを行い、攻撃防御・検知ョンテストを定期的に実施の確認を行う。
Copyright © 2021 Cloud Security Alliance Japan Chapter

35

8

アクセス状況（API コー

定常時と比較し、おかしな傾向がない

ル）の監視かなどを確認する。

・以下監視項目例-アクセス試行の傾向-許可されていないリソースへのアクセス

設定不備の検査

設定不備などにより、意図せず公開さ・セキュリティ診断（設定不備の有れている資産などがないか確認する。 無確認）の実施
侵入検知（不正リクエス

内外部からの不正な侵入の有無をモ・セキュリティシステム（センサト）ニタリングする。

ー）からのアラートチェックを行う。

Copyright © 2021 Cloud Security Alliance Japan Chapter

36

3.8. ケース 8 弱い管理プレーン
3.8.1. 概要
クラウドにおけるマネジメントプレーンではクラウド上のあらゆるサービス、データ、デバイスの管理を求められるため、管理者は、セキュリティ設定、データフロー、またアーキテクチャの弱点を適切に把握する必要がある。管理が不十分な場合、データの破損、使用不能、漏洩を引き起こす可能性がある。

3.8.2. ビジネスインパクトサービスや提供製品に対する不満や信頼の喪失により、最終的には、収益の減少につながる恐れがある。さらに、特に個人データを含むデータ損失の場合には、監督機関の処罰を受ける可能性がある（例：GDPR では、 2000 万ユーロまたは売上高の 4%の罰金が課される可能性がある）

3.8.3. 想定事例と実例「クラウド重大セキュリティ脅威 11 の悪質な脅威」に記載のある事例として以下が挙げられる。
Ø2 要素認証は、有効な対策のひとつであるが、多くの CSP が、2 要素認証に対して追加料金を設定している。このような慣行が、クラウド利用者のセキュリティ対策を弱めている

3.8.4. 当問題に対するポイントと対応策
他の脅威と同様、まずはリスクを評価し、重要さに応じた適切な対処を検討する必要がある。特に、仮想リソースの設定ひとつで重大なセキュリティ事故が発生しうるリスクについては、持続的（継続的）な状態監視が必要である。

3.8.5. DevSecOps サイクル
新たなクラウドサービスを利用する上での要点にフォーカスし、DevOps サイクルに対応策をマッピングしている。

Copyright © 2021 Cloud Security Alliance Japan Chapter

37

3.8.6. DevSecOps を踏まえた対処
3.8.5.の図内の対応の詳細を以下に記載する。
項番1

項目
データ関連法規の確認

データ損失影響の定義

概要

対応例

業界や地域などによって異なる、当該・データ関連法規：J-SOX 法、個人ビジネス領域で従うべき法令を確認

情報保護法、GDPR、PCI DSS、HIPAA

する。

など

データ損失により発生する可能性が・データ復旧費用、情報漏えいに対ある、金銭的被害などのリスクを定義する金銭的補償、ビジネス機会損する。

失影響、法令違反による制裁金、株価への影響など

2

利用予定のクラウドサー

・利用予定のクラウドサービスに対・利用予定のサービスを評価する

ビスの調査するデューデリジェンスを実施する。 ために認証取得有無や各種フレー・利用予定のクラウドサービスにつムワークに準拠しているか評価す

いて、多要素認証や権限レベル、取得

る可能な監査対応ログの内容など、管理-STAR 認証の有無

プレーンのセキュリティ機能に対す-ENISA/IPA：クラウドコンピュる調査を実施する。

ーティング 情報セキュリティ確保のためのフレームワークの確認

3

4

実施すべきデータセキュ

リスクへの対応方針や利用予定のク・2 要素認証の採用、利用者 ID 管

リティ対策の決定

ラウドサービスのセキュリティ機能

理の徹底、データ保全計画の策定、を踏まえて、運用管理におけるセキュ

CloudHSM の使用による強力な鍵管

リティ管理策を決定する。

理などが例として挙げられる

各種サービスへのログインやアクセ・AWS CloudTrail やサードパーテ

スに関するログを収集し、不正アクセ

ィー製品の活用したログ管理を実スを検知する仕組みを用意する。

施する。

侵入検知（不正リクエス

内外部からの不正な侵入の有無をモ・セキュリティシステム（センサト）ニタリングする。

ー）からのアラートチェックを行アクセス監視う。
CSPM（クラウドセキュリ

ストレージや仮想ネットワーク、IAM・AWS Trusted Adviser やサード

ティポスチャ管理）など、管理プレーンから設定可能な

パーティ製品の活用したインフラ

IaaS 環境のセキュリティ関連設定にストラクチャクラウドスタック全

ついて、設定ミスやコンプライアンス

体のセキュリティ評価とコンプラ

ルールへの不適合、不適切な権限昇格

イアンスの監視を実施する。

を継続的にチェックする仕組みを導入する。
5

データアクセス証跡の確対応すべきデータ関連法規に従った・特権 ID 管理、アクセスログの収保

監査証跡の確保集・保全を行う。

サービスのアップデート

サービスが提供するセキュリティ関・定期的なアップデート情報や脆情報のキャッチアップ

連の新機能や機能改善の適用による弱性情報を確認する運用業務を検Copyright © 2021 Cloud Security Alliance Japan Chapter

38

運用改善

討する

3.9. ケース 9 メタストラクチャとアプリストラクチャの障害
3.9.1. 概要
メタストラクチャは CSP と利用者の境界線（別名ウォーターライン）と見なされる。CSP はシステム運用に必要な機能を API によって提供するが、CSP による貧弱な API 実装は、サービスの機密性、完全性、可用性を損なわせ、クラウド利用者を混乱させる機会を攻撃者に与える。防衛策として、クラウド利用者は、安全性の高いク
ラウドサービスを選定するとともに、セキュリティを確保するために CSP が提供する機能を活用する必要がある。
また、クラウド利用者は、クラウドプラットフォームを十分に活用して、クラウドアプリケーションを適切に実装する方法を理解する必要がある。クラウドにビジネスオペレーションとアプリケーションを移行する場合、アプリケーションをそのままクラウドに移行する「リフト」アプローチを取るだけでは不十分である。

3.9.2. ビジネスインパクト
メタストラクチャやアプリストラクチャはクラウドサービスの重大なコンポーネントである。CSP レベルでこれらの機能に関わる障害は、すべてのサービス利用者に重大な影響を与える可能性がある。同時に、テナントによる設定ミスは、経済的、運用的に、ユーザーに非常に大きな影響を与える可能性がある。

3.9.3. 想定事例と実例「クラウド重大セキュリティ脅威 11 の悪質な脅威」に記載のある事例として以下が挙げられる。
Ø

利用者側でのメタ/アプリストラクチャの障害の最もよくある例は、ID やアクセス管理に関することである。多くの組織は今でもユーザー名とパスワードのみに依存しており、クラウド内で提供され簡単に実装されるシングルサインオン(SSO)、ID フェデレーション、多要素認証(MFA)のような進んだセキュ
リティ機能を無視している。例えば、デロイト社は、（MFA オプションを Microsoft が提供していたにも関わらず）管理者アカウント用に単一のパスワードに頼った運用をし続けために、Office 365 メール
サービスの内容を流出した。その結果、ハッカーがアカウントを侵害し、大量のクライアント情報が漏洩した。

ØAWS のヘビーユーザーの 1 つである Netflix 社は、メタストラクチャアクセスがどれほど重要であるかを理解しており、自社のセキュリティ運用プロセスで使用される資格情報の漏洩を検知する手順を提供している。攻撃者はメタストラクチャの資格情報に価値を見出す。2017 年の「Microsoft Security
Intelligence Report」によると、これらの攻撃の頻度は前年から 3 倍になった。2018 年の調査結果でも、「79%の SaaS ストレージ アプリケーションと 86%の SaaS コラボレーション アプリケーションが保存中および転送中のどちらもデータを暗号化していない」と記載している。

Ø

初期の SecureWorks 社の AWS Community Marketplace 調査では、Amazon Machine Image (AMI)にある半分以上のイメージに何らかの欠陥があることを発見した。この欠陥にはテンポラリディレクトリ
内のファイル、システムに残された埋め込みキー、スナップショットに残された追加のランレベル実行制御(rc)スクリプトが含まれる。イメージの出所が分からなければ、イメージを信頼することができない。
そのため、Infrastructure as a service (IaaS)プロバイダは、様々なマーケットプレイスで共有するための説明書や要求事項を公開している。加えて、アプリストラクチャの実装には、顧客分析用の画面の操作記録が原因で 2019 年に iOS アプリプロバイダーを制限した Apple と同様の問題がある。

Ø

Copyright © 2021 Cloud Security Alliance Japan Chapter

39

3.9.4. 当問題に対するポイントと対応策必要なセキュリティ機能（多要素認証など）を有するクラウドサービスを選定し、メタストラクチャを保護するとともに、クラウドネイティブなアプリケーション設計や侵入検知・防止の仕組みによりワークロードの保護行う。

3.9.5. DevSecOps サイクル
クラウドサービスにおけるメタストラクチャで発生する問題にフォーカスし、DevOps サイクルに対応策をマッピングしている。

3.9.6. DevSecOps を踏まえた対処
3.9.5.の図内の対応の詳細を以下に記載する。
項番
1

項目

概要

対応例

セキュアでオープンなク

・API の権限コントロールや MFA の機・利用予定のサービスを評価する

ラウドサービスの選定

能が成熟し、かつドキュメントが充実

ために認証取得有無や各種フレーしている CSP を利用する

ムワークに準拠しているか評価する-STAR 認証の有無-ENISA/IPA：クラウドコンピュ
ーティング 情報セキュリティ確保のためのフレームワークの確認

2

クラウドネイティブなア・クラウドにビジネスオペレーショ

・CI/CD の導入やコンテナの利用

プリケーション設計

ンとアプリケーションを移行する場

によるイミュータブルなインフラ

合、オンプレミスのアプリケーション

設計

をそのままクラウドに移行する「リフ-マイクロサービスの採用

ト・アンド・シフト」のアプローチだ-サーバレスアーキテクチャのけではなく、クラウドプラットフォー

採用

Copyright © 2021 Cloud Security Alliance Japan Chapter

40ムの機能を積極的に活用する。
アクセス管理ポリシーの職務分掌を適切に行い、役割にあった・ロール（全体管理者、運用管理者、検討

権限を定義する。

オペレータ、バックアップ＆リカ
バリ、一般ユーザーなど）の定義
・運用オペレーションにおける、不必要な高権限 ID（root など）の排除・システム管理者やテナント管理者などの強い権限を持つアカウン
トには、利用者のデータを操作する権限を与えない。
・不要な ID や権限は残さない。

認証手段の検討

特権 ID の認証については、まず多要・認証手段を検討する上での考慮（多要素認証の採用）

素認証を提供しているサービス事業

事項（例）として、以下のようなも者を選定し、設定を有効にすることがのが挙げられる。

望ましい。

-初回登録時と 2 回目以降の 2 つ

また一般利用者の認証については、サのユースケースについて検討が必ービスレベルや利用者のリテラシー

要。

を考慮して認証方式を検討する。

-管理機能のアクセス元 IP アド
レスを制限する。
-追加コストがかけられない場
合などは、SNS 認証やメールアドレ
ス認証など、比較的低コストで実現可能な認証手段を検討する。
-モバイルアプリの場合、2 回目以降の認証については端末認証の採用を検討する。
-認証強化を他のサービス（IDaaS など）に委託し、シングル
サインオン環境を構築する。

3

ペネトレーションテスト

公開されるサービスに対してペネト

・適切なエンゲージメントの上、ペレーションテストを行い、攻撃防御・ ネトレーションテストやレッドチ検知の確認を行う。事前に定められたーム演習を実施する。

間隔及びシステム変更時に実施する。
4

アクセス監視管理プレーンへのログインやアクセ・AWS CloudTrail やサードパーテ

スに関するログを収集し、不正アクセ

ィー製品の活用したログ管理を実スを検知する仕組みを用意する。

施する。

侵入検知（不正リクエス

・不正なアクセスを防止するための・IDS/IPS、WAF、DDoS protection

ト）

策を講じる（IPS、WAF など）など、外部からの不正侵入に対応

・API ゲートウェイを利用したエッジできるソリューションの導入を検Copyright © 2021 Cloud Security Alliance Japan Chapter

415

処理等も検討する。

討する。

設定不備の検査（クラウストレージや仮想ネットワーク、IAM・AWS Trusted Adviser やサード

ドセキュリティ態勢管など、管理プレーンから設定可能な

パーティ製品の活用したインフラ

理）

IaaS 環境のセキュリティ関連設定にストラクチャクラウドスタック全

ついて、設定ミスやコンプライアンス

体のセキュリティ評価とコンプラ

ルールへの不適合、不適切な権限昇格

イアンスの監視を実施する。

を継続的にチェックする仕組みを導入する。

Copyright © 2021 Cloud Security Alliance Japan Chapter

423.10. ケース 10 クラウド利用の可視性の限界
3.10.1. 概要
企業でクラウドを利用する場合、その状況を可視化し的確に把握することが重要になる。もし、可視性が保たれていない場合、シャドウ IT と呼ばれる私的利用の温床にもなりかねない。

3.10.2. ビジネスインパクト
利用しているクラウドサービスおよび、利用状況を把握できないことで以下のような影響がある。
・従業員に対しての適切なアクセス制限が出来ていない場合やガバナンスの不足により、プライベートの場
所に置くべき企業の機密データがパブリックな場所に配置される可能性がある。
• データとサービスが会社の知らないところで使用されている場合、財産を制御することができなくなる。
• 従業員がクラウドサービスを誤って設定した場合、既存のデータだけでなく、将来のデータに対しても攻撃可能になる可能性がある。

3.10.3. 想定事例と実例「クラウド重大セキュリティ脅威 11 の悪質な脅威」に記載のある事例として以下が挙げられる。
Ø

22,000を超えるコンテナオーケストレーションとAPI管理システムが保護されていないか、インターネット上で公開されている(Lacework社調査,2018年)

Ø

今日使用されている1,000以上のクラウドサービスのうち、その多くがシャドウITのカテゴリーに分類される可能性がある(Skyhigh Networks Cloud Adoption & Risk Report 2015 Q2,2015年)

3.10.4. 当問題に対するポイントと対応策
クラウド可視化にかかわる対応策のポイントとして、大きく以下のようなものが挙げられる。
・クラウドサービス選定基準の策定
・適切なアクセス制限・管理・クラウド利用ポリシーの策定と継続的なトレーニング・シャドウ IT 対策ソリューションの導入
・データ保護方法の策定・利用しているクラウドサービスの把握と利用状況の可視化

Copyright © 2021 Cloud Security Alliance Japan Chapter

433.10.5. DevSecOps サイクル
企業内でのクラウドサービス利用および状況管理にフォーカスし、DevOps サイクルに対応策をマッピングしている。

3.10.6. DevSecOps を踏まえた対処
3.10.5.の図内の対応の詳細を以下に記載する。
項番

項目

概要

対応例

1

リスク管理のためのベー適用される法律、法令と規制上の義務・公開されているガイドラインやスライン要件の検討を順守した開発または調達を行うた

各種基準を元にベースラインアプ

め、組織が所有または管理する物理的ローチを実施する。

または仮想的な、アプリケーション及-FISC 安全対策基準

び基盤システムとネットワークコン-ISO270001

ポーネントのベースラインセキュリ-Critical Security Control

ティ要件を定める。

-PCI DSS

標準的なベースライン設定から逸脱する場合は、導入、提供、使用の前に、
変更管理ポリシー及び手順に基づいて承認する。
利用サービスの選定基準

従業員のアクティビティを全て管理の策定することが難しいことを想定し、運用左記に同じにあたっては厳格なポリシーを定めると共にクラウドサービスの利用制
限や、利用できるサービスを限定するなどの対応を行う。
Copyright © 2021 Cloud Security Alliance Japan Chapter

44アクセス管理ポリシーの職務分掌を適切に行い、役割にあった・ロール（全体管理者、運用管理者、検討

権限を定義する。

オペレータ、バックアップ＆リカ
バリ、一般ユーザーなど）の定義
・運用オペレーションにおける、不必要な高権限 ID（root など）の排除・システム管理者やテナント管理者などの強い権限を持つアカウン
トには、利用者のデータを操作する権限を与えない。
・不要な ID や権限は残さない。

暗号プロトコルの適切な機微なデータについて、ストレージ・TLS を使用。

使用と実装

内、データ使用時、及びデータの送受・HSM サービスを使用。以下、パブ信時の暗号化を行う。暗号化には、オリッククラウドのサービス例。

ープン、検証済の標準アルゴリズムを-AWS CloudHSM利用する。

-Azure Dedicated HSM

クラウド事業者が提供するマネージ-Google Cloud HSM

ド HSM サービスを活用することが有効である。
2

監視サービスの導入

CASB などシャドーIT 対策ソリューシ

左記に同じ

ョンの活用を検討する。
環境に適応したセキュリ

働き方の多様化に伴い、セキュリティ

・例として、ゼロトラストセキュリ

ティ基盤の構築の考え方も変化しているため、環境にティに即した環境の構築などが挙適用したセキュリティモデルを構築

げられる。

する。
認証手段の検討

特権 ID の認証については、まず多要・認証手段を検討する上での考慮（多要素認証の採用）

素認証を提供しているサービス事業

事項（例）として、以下のようなも者を選定し、設定を有効にすることがのが挙げられる。

望ましい。

-初回登録時と 2 回目以降の 2 つ

また一般利用者の認証については、サのユースケースについて検討が必ービスレベルや利用者のリテラシー

要。

を考慮して認証方式を検討する。

-管理機能のアクセス元 IP アド
レスを制限する。
-追加コストがかけられない場
合などは、SNS 認証やメールアドレ
ス認証など、比較的低コストで実現可能な認証手段を検討する。
-モバイルアプリの場合、2 回目以降の認証については端末認証の採用を検討する。

Copyright © 2021 Cloud Security Alliance Japan Chapter

45

-認証強化を他のサービス（IDaaS など）に委託し、シングル
サインオン環境を構築する。
3

アクセス監視従業員のクラウドサービス利用状況

・監視の観点としては以下が挙げを常時監視し、不審な行動をチェックられるできるようにする。

-普段と異なる行動-ポリシーに反した行動-管理外のリソースアクセス

4

従業員に対するセキュリ

従業員に対してセキュリティに対す

ティ意識向上トレーニン

る意識向上を目的としたトレーニン

グの実施

グを実施する。

クラウド利用状況の監視

内外部からのアクセス状況や操作履

左記に同じ

・監視項目例

歴など、想定と異なる利用がないか確-アクセス試行の傾向認する。

-許可されていないリソースへのアクセス

設定不備の検査

設定不備などにより、意図せず公開さ・セキュリティ診断（設定不備の有れている資産などがないか確認する。 無確認）の実施
セキュリティベースライ

セキュリティベースライン要件の遵

ンのアセスメント

守状況を定期的（少なくとも年 1 回）

左記に同じは再評価する。

Copyright © 2021 Cloud Security Alliance Japan Chapter

46

3.11. ケース 11 クラウドサービスの悪用・乱用・不正利用
3.11.1. 概要
クラウドサービスの悪用・乱用・不正利用とは、悪意ある攻撃者がクラウド上のシステムを悪用し、以下に挙げるような行為が該当する。
DDoS攻撃スパムメールとフィッシング詐欺
デジタル通貨のマイニング
大規模な自動化されたクリック詐欺
盗まれた認証情報データベースによるブルートフォース攻撃
悪意のあるコンテンツや海賊版コンテンツのホスティング

3.11.2. ビジネスインパクト
顧客の利用システムが侵入を許し、マイニング活動等に当該システムが利用された場合、システム利用料が膨大になる可能性がある。
マルウェアの感染による BOT 化や攻撃のための踏み台などに利用された場合、その企業のシステムが攻撃者に加担する形で利用されてしまう。

3.11.3. 想定事例と実例「クラウド重大セキュリティ脅威 11 の悪質な脅威」に記載のある事例として以下が挙げられる。
Ø

ランサムウェア Locky の亜種である Zepto は Microsoft OneDrive、GoogleDrive、Box などのクラウ
ドサービスを通じて、悪意のあるファイルが被害者の手によってシェアされることで拡散されていた。

Ø

CloudSquirrel （キャンペーン名）はフィッシングメールを利用して被害者をマルウェアに感染させるものであった。
フィッシングメールを開封（リンクを叩くと）すると、CloudSquirrel は、JAR ファイルによって別の暗号化されたマルウェアのペイロードをダウンロードして ユーザーを感染させる。感染後にマルウェアが Dropbox 上の C&C サーバと接続し、ユーザーの情報やパスワードが取得されてしまった。

Copyright © 2021 Cloud Security Alliance Japan Chapter

47

3.11.4. 当問題に対するポイントと対応策
本章では、「クラウドサービスの悪用・乱用・不正利用」の対応策として、重要なポイントについて記載している。
クラウドサービスの不正利用において、利用者によるクラウドサービス利用を監視することが重要な対応策となる。監視要件として、いつ、どこから、誰が、どのリソースにアクセスしたかを把握し、正当な理由によるア
クセスか否かを確認することで、不正利用を防止する。
また、DLP などを利用し、ファイルのダウンロードを制限（禁止）するなどの対策も有効となる。

3.11.5. DevSecOps サイクル
保有しているクラウド環境への攻撃（侵入）にフォーカスし、DevOps サイクルに対応策をマッピングしている。

Copyright © 2021 Cloud Security Alliance Japan Chapter

48

3.11.6. DevSecOps を踏まえた対処
3.11.5.の図内の対応の詳細を以下に記載する。
項番
1

項目

概要

対応例

リスク管理のためのベ適用される法律、法令と規制上の義務・公開されているガイドラインや各

ースライン要件の検討を順守した開発または調達を行うた

種基準を元にベースラインアプロ

め、組織が所有または管理する物理的ーチを実施する。

または仮想的な、アプリケーション及-FISC 安全対策基準

び基盤システムとネットワークコンポ-ISO270001

ーネントのベースラインセキュリティ-Critical Security Control

要件を定める。

-PCI DSS

標準的なベースライン設定から逸脱す
る場合は、導入、提供、使用の前に、変更管理ポリシー及び手順に基づいて承認する。
リスク評価と脅威分析想定されるリスクと脅威の検討・公開されているフレームワーク等を参考に、脅威・リスク分析を実施する。
-STRIDE（for Microsoft）-DREAD

アクセス要求に応じたシステムに対して、アクセス範囲をで・公開するリソースの分類（情報レ

公開範囲の定義

きる限り限定するような検討を行う。

ベルなど）・分類されたレベルに対するアクセ
ス権の定義

認証方法の定義

リソース（資産）にアクセスするための・公開リソースの配置環境に応じて認証方法を検討する。

適切な認証方法・方式（MFA、リスク
ベース、CAPTCHA、FID など）の定義を行う。

2

セキュアアーキテクテ

不正な侵入を防止するための策を講じ・外部からの不正侵入に対応できるィングる（IPS、WAF、DDOS 対策など）

ソリューションの導入を検討する。
-IDS/IPS-WAF-DDoS protection

3

動作テスト（脆弱性診リアルタイムなコードのチェックや動・IAST・DAST ツールを利用し、機能

断）的なアプリケーション解析を実施す

テストを実行る。
ペネトレーションテス

公開されるサービスに対してペネトレ

・適切なエンゲージメントの上、ペトーションテストを行い、攻撃防御・検知

ネトレーションテストやレッドチの確認を行う。事前に定められた間隔

ーム演習を実施する。

及びシステム変更時に実施する。
Copyright © 2021 Cloud Security Alliance Japan Chapter

49

4

脆弱性診断

定期的な脆弱性診断を行う。

対象サービスに応じて、プラットフ
ォーム診断とアプリケーション診断の実施有無を判断し、適切に実施する。

5

セキュリティパッチ管

定期的にセキュリティパッチの公開有理

無をチェックし、必要に応じて適用す

左記に同じ

る。
6

クラウド利用状況の監内外部からのアクセス状況や操作履歴

・以下監視項目例

視など、想定と異なる利用がないか確認-アクセス試行の傾向する。

-許可されていないリソースへのアクセス

リソースの監視

リソースの過剰な負荷などを確認す

左記に同じ

る。
設定不備の検査

設定不備などにより、意図せず公開さ・セキュリティ診断（設定不備の有れている資産などがないか確認する。

無確認）の実施

侵入検知（不正リクエ

内外部からの不正な侵入の有無をモニ・セキュリティシステム（センサー）

スト）

タリングする。

からのアラートチェックを行う。

セキュリティベースラ

セキュリティベースライン要件の遵守

左記に同じ

インのアセスメント

状況を定期的（少なくとも年 1 回）は再評価する。

Copyright © 2021 Cloud Security Alliance Japan Chapter

50

4. 参考・引用文献
政府情報システムにおけるクラウドサービスの利用に係る基本方針Ø

https://cio.go.jp/sites/default/files/uploads/documents/cloud_%20policy.pdf

クラウドの重大セキュリティ脅威 11 の悪質な脅威
Ø

https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2019/10/top-threats-tocloud-computing-egregious-eleven_J_20191031.pdf

CCM Controls Frameworks
Øhttps://cloudsecurityalliance.org/research/cloud-controls-matrix/

Copyright © 2021 Cloud Security Alliance Japan Chapter

51