security in a box クラウド・セキュリティ・アーキテクチャのあ … ·...
TRANSCRIPT
2018年1月発行
www.pwc.com/jp
Security in a Box
クラウド・セキュリティ・アーキテクチャのあるべき姿
1Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿
目次
概要
はじめに
対象者
セキュリティに関する共通課題
9
セキュリティアーキテクチャの再定義
Security in a Boxについて
セキュリティサービス
第三者／第四者によるデューデリジェンス
アクセス権の再認証
セキュリティの監視と対応
サービスとしての暗号化
統合スレットインテリジェンス
インフォメーションセントリックプロテクション
リアルタイムアシュアランス
13寄稿者
2
3
3
4
7
7
概要
レガシーシステムとアプリケーションを長年使用する中で、膨れ上がったテクノロジー負債（technology debt）という制約がなかったら、セキュリティはどのような形になるだろうか？必要な時に、できるだけ迅速にセキュリティの機能をサービスとして調達可能になったら？本書では、クラウドセキュリティに関する共通課題をどのように解消できるか説明する。これから紹介するサービスは、実際に利用可能なソリューションと提案内容を基にしており、クラウド内の情報保護を託されたクラウドセキュリティの専門家が検討すべき内容である。
2PwC Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿 12
今日のテクノロジー主導型社会において、以下のような多くのマクロトレ
ンド（※）が浮上しており、組織はテクノロジーの活用方法の再定義を迫
られている。
例：
•顧客エンゲージメントおよびサービスを高めるデジタルサービスの採用
• IT管理のトータルコスト改善に向けた「クラウドファースト」戦略の実行
• EU決済サービス指令（PSD2）やオープンバンキング規制などの原則を
通じた「シェアリングエコノミー」の推進※マクロトレンド：業界を横断したグローバルレベルで起こっている一種の傾向
Salesforce
3Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿
はじめに
セキュリティサービスに関する新しい考え方
対象読者： NetflixやUberなど、クラウド環境の活用を前提としてスタートしたクラウドネイティブのハイテク企業や、レガシー環境のクラウド化を進め、社内のクラウド化を推進している組織の全クラウドセキュリティ担当者
Acme社（※）
公衆無線LAN
モバイル／IoT
ホームオフィス
交通機関
GoogleCloud
社員 スーパーユーザー
顧客
AzureMicrosoft
AmazonWeb Services
Security in a Box
そこで、一つの解決策として、我々が提唱するのが「Security in a
Box」という考え方である。「 Security in a Box」とは具体的に以下
のような特徴を持ったセキュリティ機能をテクノロジーを活用したビ
ジネスの1ソリューションである「Box」に組み込むことである。
• セキュリティAPIの使用
• 拡張性や柔軟性に優れ、かつ自動化されたクラウドベースの
サービス
• 組織固有のニーズに応じて簡単に開始・停止でき、自由にカス
タマイズ可能
本書では、実際にクラウドセキュリティの専門家がこれらのマクロト
レンドに対応するため、どのようにセキュリティ機能を組み込んだ
「Box」を開発し、活用していくかを説明する。その上で、結果的に
企業がいかにデジタル社会において信頼を維持できるようにする
かを見ていく。
こうしたトレンドにより、テクノロジーのアーキテクチャについても、「独立した閉鎖的なもの」という考え方か
ら、「オープンでコラボレーティブなもの」へと変わりつつある。
• 情報やさまざまなデジタル取引の組織間共有を促進するAPIの使用
• 第三者が管理するクラウド環境への基幹業務システムの移行
• アジャイル開発手法の採用（DevOpsなど）によるイノベーションのスピードとサービスの市場投入まで
の時間短縮
従来のウォーターフォール型開発によるデータセンター中心型の統制では、ペースの速い協業が必須
なビジネスを実施することは難しくなっている。そのため、上記のような変化に適応するために、セキュリ
ティ担当のリーダーは、サイバーセキュリティの機能設計や構築方法を見直す必要が出てきている。
※架空の会社
1. パッチ管理
2.セキュリティサービス標準化の遅れ
3.コンプライアンス関連取り組みの重複
4.サイバー攻撃に対する誤った評価
5.第三者／第四者によるセキュリティに対する誤った認識
6.データ統制の維持
7. ログ最適化
8.アクセス権の再認証
9.ツールベースのセキュリティ戦略
セキュリティに関する 共通課題組織的な課題に直面している多くのクライアントと議論する中で、ゼロデイの脆弱性、人員の地理的な分散化、リモートワークに対する組織的な理解等の課題と並んで、未解決なままとなっているセキュリティ課題も数多く挙げられた。その中で、最も頻出する課題として以下のようなものがある。
4PwC Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿 12
Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿
1. パッチ管理
パッチ管理は企業がITシステムの脆弱性にできるだけ晒されない
ようにするために不可欠である。
一方で、パッチ適用には、検討すべきパッチの量、適用時に検討
すべきテクノロジーの数、いくつかのパッチ適用にて必要となる手
作業、パッチ適用前の膨大なテスト要件等を多くの考慮すべき事
項がある。その結果、組織はパッチの適用での膨大な作業量に圧
倒され、パッチ管理が難しい状況に陥っている
さらに、パッチ適用はビジネスに支障がでないタイミングで、ITの
サービス中断時間を設けなければならないことがあり、対応が後手
に回ることがある。その結果、組織のシステムに最新のセキュリティ
アップデートを適用できず、サイバー攻撃の危険に晒され、脆弱な
状態に陥ってしまう。
2. セキュリティサービス標準化の遅れ（マルチベンダーによって提供されるセキュリティサービスの課題）
さまざまな大手テクノロジー企業がひしめくサイバーセキュリティ市
場は、最新テクノロジーの活用が進み、刻々と進化を遂げている。
各組織でこれら多様なソリューションが採用され始め、さまざまなベ
ンダーが開発した独自のアプリケーションおよびツールが使用され
ている。しかし、多くの製品は互換性がないため、各製品を使用時
には多数のさまざまなソースから収集した情報を整理・調査・関連付
けるための大量の分析が必要となっている。その結果、これらツー
ルを使用するセキュリティ担当者の作業負荷が膨れ上がってしまっ
ている。
また、セキュリティツールと各システムが統合されておらず、個々の
製品が複数ベンダーによって保守運用され、ベンダー毎にデータ
レベル、システムレベルで個別最適化されているようなシステム環
境を持つ組織ではデータ保護の対応がより困難になっている。
このような状況下で、組織が各システムから有意味なデータを得ら
れない場合、ビジネスで最も重要かつ利益をもたらすような意思決
定を下すことが困難となってしまう。
3. コンプライアンス関連取り組みの重複
イギリスの一般的な中規模組織では、財務健全性コンプライアンス、
規制認証、クライアントのアシュアランス要求などの一環として、1年
に3~5回のセキュリティ監査を実施される。各監査では、エビデンス
となる書類一式を作成する必要があり、さらに監査人と認識を合わ
せつつ、レビューしなければならない。
最も苦労するのは金融サービス業界など規制が厳しい業界だが、
小売業界においてもPCI DSS（Payment Card Industry Data
Security Standard） およびISO27001の監査に何百万ドルもの費
用が必要となる場合もある。
問題は、どのセキュリティ監査においても質問の大部分は同じであ
り、質問の範囲およびその質問をどこまで掘り下げるかが若干異な
る程度であるという点である。さまざまな組織で見受けられることだ
が、関係者間のコミュニケーション不足が原因で、現場の統制業務
の担当者は、何度も同じ資料を提出させられ、 同じ内容の文書の
作成に膨大な時間が奪われる。これによって、通常業務に加えて、
こうした負担が重なり、担当者が疲弊する結果になってしまう。
4. セキュリティ指標に関する誤解
メディアでは、標的型攻撃メールを発端とする企業へのセキュリティ
侵害や、さまざまな攻撃者による絶え間ないフィッシングキャンペー
ンが多く報じられている。そうした中で、ほぼ全てのCISOが、自社の
社員がフィッシングに引っかかることを最も懸念している。
そのため、ユーザーを騙してメールに記載されているリンクをクリック
させようとする標的型攻撃メールテストが定期的に実施されている。
しかし、こうしたテスト結果（例：先月騙されたユーザー数は88％、
今月は79％に低下）は誤解されているケースも多い。
1ヶ月で9ポイント減少したのは良い結果と言えるだろうか？ この結
果に満足してしまい、人的な対策は予防的対策に過ぎず、効果的
にマルウェアへの感染リスクを軽減するには、セキュリティ・オペレー
ション・センターによる適切な検出と迅速な対応が必要である、とい
う点が忘れられる恐れがある。
5. 第三者／第四者によるセキュリティに関する誤った認識
サービス利用者（例：銀行）と業者（例：アプリケーション外注組織）
間で最低限のセキュリティベースラインを維持する契約が存在する
場合もあるが、それでも利用者がシステム開発におけるサプライ
チェーンの脆弱性からもたらされるリスクに晒されていることに変わり
ない。
FinTech、Insure Tech、その他、これに類似する細分化
（comparmentalisation）が進む中、サプライチェーンはより複雑化
している。もはや、サービス利用者が第三者となるアプリケーション
開発業者に対するリスクを管理するだけでは不十分となっている。
そのため、クラウドセキュリティの専門家はその先を見据え、第四者、
第五者のリスクも検討しなければならない。
しかし、必要な定期的セキュリティデューデリジェンスを行うための
リソースが不足しており、組織は、ISO27001準拠証明、さらに悪
い場合は自己評価アンケートに頼らざるを得ない状況である。こう
した評価アンケートを受けたことがある人はだれでも回答が可能で
あるため、本自己評価手法では各人の解釈の幅が広がりすぎて、
質問側の組織がセキュリティに対する誤った認識を持つことに
つながりかねない。
例えば、クライアントに安価なITサービスを提供することを唯一のビ
ジネスモデルとしているような第三者に、IT業務要素の一部を外注
することはよくあることである。しかし、こうした第三者は、コストカット
を一層進めて競争力のある価格を提示するために、受注した業務
の一部を専門業者に孫請けに出すこともあり、そしてその専門業者
がさらに下請けに出す可能性もある。
5
6. データ統制の維持
他の組織との情報共有は、テクノロジーの領域の中心的な要件となっ
ている。英国で導入が進んでいるオープンバンキングやPSD2（※）など、
規制の下において本情報共有が推奨されている。その一方、情報共
有を行う場合は、個々の組織にて共有した情報が改ざんされずに、
意図した相手のみに届くことを確保しなくてはならない。
情報が公開されると、組織のコントールが効く境界線上に情報が存在
することになり、情報保護施策があまり効かなくなってしまうという一
定のリスクを常に伴う。例えば、情報を暗号化して送信する場合は、
受領側でそれを復号できる必要があり、有資格者のみが情報を
復号化し内容を閲覧できる確かな方法を用意しておかなければなら
ない。
情報にアクセスするタイミング次第で状況はより複雑になる。情報を共有したいが、現在と事業環境及び組織との関係性が変わったら、その情報へのアクセス権を取り消したい、というケースもありえる。しかし、「送信」ボタンを押してから、すぐにそうしたことを行うのは非常に困難である。
※ PSD2(Payment service Directive2)：2015年に公表されたEU域内における資金決済サービス業者に関する規定（PSD）の改定版
7. ログ最適化
従来のセキュリティ監視は、組織全体のすべてのログを確認し、
セキュリティチームにとって最善のネットワークの可視性をもたらして
きた。この手法は概ねうまくいっているものの、制約と課題があること
も確かである。
現在は、組織全体にわたる相互接続機器が増え続け、悪意ある
攻撃者対策のツールや技術も高度化している。こうした中で、全て
のイベントを検出し、記録するために必要なログは、いくらセキュリティ・
オペーレーション・センター（SOC）の人員が豊富であっても、手に
負えないデータ量になってしまう（「データの泥沼化」）リスクがある。
「データの泥沼化」の管理には、ユーザのアクティビティ調査、ログ
のチェック、脅威情報の参照から、電子メールの送信やレポートの
作成などの管理タスクまで、多くのサブタスクも必要である。そのうえで、
侵入検知および侵入防止システム（IDPS）署名の作成、プロキシブ
ラックリストの更新、アカウント無効化といった是正策も実行しなけれ
ばならない。
最適なログ取得は難しい課題である。組織は、活用可能な全てのログ
を利用しようとすると、 その膨大なデータによって、SOCチームを
疲弊させ、大量のイベントデータにまぎれて悪意あるトラフィックを
見逃してしまうということにつながってしまう恐れがある。あるいは、
すべてのログの活用を検討した場合、コストが膨れ上がり、その結果、
活用しているマネージドセキュリティサービスプロバイダ（MSSP）の
コスト面で圧力をかけ、ネットワークの可視性を制限することになって
しまう。
8. アクセス権の再認証
組織のIDを統合管理し、セキュリティを確保するID＆アクセス管理
（IAM）は、定期的なアクセス認証チェックを行う組織にとって、常に
頭を悩ませる問題である。
企業のユーザーディレクトリ上、明確な所有者が存在しないタグ
無しアカウント、権限の再認証が行われないまま新入社員に提供
される「コピーID」、ユーザーが一部のワークフローのみで認証できて
しまうといった有害アクセス、認証プロセスに対する効果的監査能力
の無さなど、IAMにおける問題が山積しているケースが多い。
特に、アカウントの再認証は、ビジネス関係者にとって複雑な課題
である。本認証では「最小特権」という考え方を理解しなければなら
ないだけでなく、権限の統合に起因した役割の総合的なリスクプロ
ファイルや、自社内のさまざまな相互接続システムを深く理解して
おく必要もある。そうした役割の責任者は、再検証の量と複雑さに
圧倒され、結局単に「受け入れる」をクリックするだけになっているのが
実情である。
実際、最近年次のアカウント再検証を行った世界クラスの銀行に
おいて、システム責任者とラインマネージャーが再検証でクリック
した回数は実に1400万回に及んでいた。このような地味でありながら、
大規模な活動は、「チェックボックス文化」を生み出す可能性が高く、
リスク軽減の価値とコストについて大きな議論を招いてしまう。
9. ツールベースのセキュリティ戦略
組織への侵害方法として最も多いケースは従来と変わらず電子メールの添付ファイルであり、エンドポイントのセキュリティに引き続き焦点が当てられている。この市場は活況を呈している一方で、シグネ
チャー、ヒューリスティック、ブラック／ホワイトリストベース等のクラウド脅威分析に基づくエンドポイント保護ツールのあまりの多さに、クラウドセキュリティ担当者も圧倒されている状況である。最近、ある大規模
組織におけるツールのポートフォリオレビューを実行したところ、 25を超えるエンドポイント・セキュリティー・ソリューションが存在し、その中には機能が重複しているものもあった。また、全世界で採用されている
ソリューションもあれば、一部の地域のみで購入されているものもあり、試験的に導入した結果、他の地域ではうまく機能しないことが判明したものもケースも存在していた。さらに、採用しただけで、まだ誰も設定を
済ませていないケースも見受けられた。こうした問題は、ツールで飽和状態にある市場やセキュリティ・ソリューション・プロトコル間の標準化不足、またその結果生じるツールの適切な統合が不可能であること
に起因している。他のITおよびIT以外の業界と比較した場合、ITセキュリティ業界は比較的未成熟であることも相まって、問題が一層複雑化しているのが実情である。クラウドセキュリティの専門家は、業界最
高クラスの最新ソリューションを購入することで頭が一杯になり、追加ツールの維持費を深く考えないことがよくある。しかし、このツールの維持を考慮に入れないと、脅威の軽減という点での限界便益は損なわ
れてしまう。その結果、多くのセキュリティ戦略が、健全な設計手法に基づくものではなく、単にツールの人気度に基づくものになってしまっている。
Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿 6PwC
企業 セキュリティサービス（Security in a Box）
以下に概要を示したのは、第三者から提供されるまたは大企業にてコンセプトとして採用し構築され、後にグループに「Box」サービスに組み込まれたセキュリティ機能一覧である。
7Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿
セキュリティアーキテクチャの再定義Security in a Boxについて
英国では、競争・市場庁（CMA）によって確立されたオープン・バンキング・イニシアチブを踏まえて、多くの非金融サービス組織が、すでに顧客へのサービス向上を図る独自の銀行商品を構築し始めている。
オープンバンキングは大きな一歩であるものの、まだ始まりに過ぎない。疎結合で、ビジネス志向のウェブサービスアーキテクチャを採用するITサービスが多くなる中、企業におけるIT専門家は、近い将来、第三
者が提供するサービスカタログから利用するサービスを選択するようになると想定している。そして、業界の枠を超え、特定のビジネスを達成するようにカスタマイズされたエコシステムを簡単に構築できるようになると
考えている。
企業およびIT専門家は、こうしたテクノロジーを活用し、製品ポートフォリオ、支払受領、ローン管理などサービスの「Box」を作り、顧客に提供するようになる。PwCは、セキュリティもこのような「Box」を構成
する一要素になりうると考えている。クラウドセキュリティの専門家は、このセキュリティ設計手法および最先端テクノロジーを用いることで、セキュリティの要素を加味した組織のテンプレートとして「Security in a
Box」を構築することが可能であり、これによって従来の課題を解決できるだけでなく、より高いアジリティでセキュリティ対策を導入できるようになる。
下流サプライヤー・パートナー
構築 テスト パイロット 実行
顧客向け
アプリケーション
エンタープライズアプリケー
ション（カスタム）
内部ユーザーアクセス
スタッフ
顧客API
顧客
顧客向けサービス ＜ ＞ エンタープライズ
マネジメントAPI
スーパーユーザー
外部エンタープライズアプリケーション
セキュリティ統合
統合セキュリティ コンプライアンスリアルタイムアシュアランス
サービスとしての暗号化
アクセス権の再検証
インフォメーションセントリックプロテクション
統合スレットインテリジェンス
セキュリティの監視と脅威への対応
第三者／四者による
デューデリジェンス1
2
3
4
5
67
1. 第三者／四者によるデューデリジェンス － セキュリティ態勢のリア
ルタイム指標に基づき、サプライヤー／パートナー優先順位リスト化。その後、本指標用いて、組織が問題を抱えている特定の組織に対して現地監査やウォーゲームを実施
2. アクセス権の再認証 － 異常検出とデータマイニングを活用し、スタッフのアクセス認証レビューに必要な労力の大幅な削減
3. セキュリティの監視と対応 － データマイニングと異常の検出による、セキュリティ警告の監視および分析にかかる労力の大幅な削減
4. サービスとしての暗号化 － 暗号化手法を標準化し、脆弱な暗号プロトコルの利用や実装を回避
5. 統合スレットインテリジェンス － 人による介入ゼロ（または最小限）で新たな脅威を迅速に検出
6. インフォメーションセントリックプロテクション － 機密データが組織外に出た後も保護する集中セキュリティポリシーの作成
7. リアルタイムアシュアランス － セキュリティリスクとパフォーマンス
の指標に基づき、組織のセキュリティ体制のダイナミックかつリアルタイムに組織の概況を提供
Security in a Box vs MSSP
「Security in a Box」とMSSPの違いは何か？従来の MSSP は、セ
キュリティ上のインシデントおよびイベント管理ソフトウェアを対顧客
業務の中心に据えてきた。具体的には予め定義されたログの収集、
ユースケースによる監視プロセスおよびプロセスレベルで統合に注
力してきた。しかし、既述のように、こうした手法では効果のあるログ
管理が行えず、セキュリティについて誤った認識を組織側に与え
かねない。つまり、外注した組織が、「第三者にセキュリティを外注
したのだからもはやリスクを抱えていない」 という認識を持ってしま
う恐れもある。
この誤った認識は、脅威を巡る環境変化に適応せず、組織内部の
変革も行わないという現状維持を促すことにつながる。さらに、
MSSPにかかるコスト面での影響により、そうした現状維持を打破し
ようとするインセンティブがほとんどなくなってしまう。MSSP プログ
ラムは通常、肝となるインフラストラクチャ監視のユースケースを設
けるところまでを実施することが多い。そのため、能動的な脅威
ベースのセキュリティ業務まで踏み込むことはなく、受動的にセ
キュリティ要件を満たす業務にとどまってしまう。その結果として、
業界や業務環境の違いを考慮することなく、イノベーションを必要
としない型にはまった手法が適用されることになる。
こうした状況に陥らないためには、能動的な対応が必要である。能
動的な対応とはアプリケーションをリリース後ではなく、リリース前に
セキュリティの側面から分析し、ルールを策定し、予算を確保する。
さらに、リスクを許容し、リスク自体をアプリケーションの一部として
サービス運営を行うことである。
「Security in a Box」の手法では、セキュリティとの連携を中心とし
てソフトウェア開発及びテクノロジーとの統合を行うように設計する。
セキュリティに対する従来の手法は、もはや現代のソフトウェア開発
手法に合っていない。セキュリティは、イネーブラーというよりもむし
ろブロッカーとみなされることも多く、製品発売の遅延をもたらし、リ
スクを招くものとして敵視されている。「Security in a Box」の手法
で提示するのは、ソフトウェア開発機能との深いレベルでの統合を
通じて、セキュリティ要件を体系化し、開発サイクルやテストサイク
ルに含め、製品を採用した段階ですでにセキュリティ要件も満たし
た状態することである。
前提条件「Security in a Box」のモデルを導入可能な状態にするには、いく
つかの初期前提条件をクリアしなければならない。組織毎に必要
なセキュリティ機能が異なるため、一律のリストを提示することはで
いないが、いくつかのパターンのテンプレートを求められた場合は、
テクノロジーの専門家は少なくとも以下の点について検討を行う
べきである。
a. セキュリティ自動化「Security in a Box」のモデルを効果的に利用するために、組織は
セキュリティコントロールの自動化手法を採用する必要がある。
簡単に言うと、クラウドセキュリティの専門家は、自分の仕事がなく
なるところまで自動化を進める、という目標を設定する必要がある。
もちろん、これは決して達成されることのない目標であるが、こうした
考え方を持つことで、クラウドセキュリティの専門家は、セキュリティ
機能を再使用可能なサービスセットに分割し、組織のITアーキ
テクチャに統合してリアルタイムで報告を上げることが可能になる。
この5～7年の間で、多くのセキュリティベンダーがセキュリティの
基本ユースケースの自動化に向けたセキュリティミドルウェアを
生産している。
例えば、組織の内部不正監視デバイスから精度の高い信号を受領
した際に、侵入検出／防止システムを監視モードからブロックモード
に自動的に変更するミドルウェアなどが挙げられる。しかし、そうし
た製品は独自のプロトコルや複雑なアーキテクチャに依存しており、
柔軟性が不足しているため、おおむね失敗に終わっている。しかし、
DevOps やマイクロサービスアーキテクチャの進化により、クラウド
セキュリティの専門家は、自分たちのセキュリティ統合プラットフォー
ムを適用／開発することが可能になっている。そのため、本統合プ
ラットフォームを活用し、組織のニーズに応じて、アジャイル・ソフト
ウェア開発チームと協力しながら、継続的にカスタマイズできるよう
になっている。
さらに、本カスタマイズにより必要なレポート機能を開発して、セ
キュリティ信号を組織が直面しているリスクに照らして検討すること
もできるようになる。
b. サービスとしてのプラットフォームの提供複雑な課題を解消していくには、自分たちが最も得意とすることに
集中する必要がある。大手クラウド・サービス・プロバイダーでは、
適切にコンプライアンス要件を満たすように多くの人材を雇用し、
堅牢なパッチ適用スケジュールに巨額を投じている。これにより、
サービス利用者側がこれらの要件に対応する手間を省いている。
クラウドセキュリティの専門家は、開発者と協働して、組織が「サー
ビスとしてのプラットフォーム」のモデルに移行可能かを把握する必
要がある。リスクを受容できるのならば、このモデルを採用すること
でスタッフの労働時間を数千時間レベルで削減し、より迅速な
セキュリティ脆弱性に対するパッチ対応が可能になる。
8PwC Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿 12
セキュリティサービス以下説明するのは、「Box」に組み込む主要なセキュリティ機能で
ある。ここで挙げた機能は全てを網羅したものではなく、市場の成
熟度や、IT業界がさらにAPIを活用する中で、更新され、拡大し、
また向上していく可能性がある。以下のサービスは、実際に利用
可能なソリューションと提案に基づくものであり、クラウド内の情報
保護を託されたクラウドセキュリティの専門家が検討すべきもので
ある。
1. 第三者／第四者によるデューデリジェンスクラウドセキュリティの専門家は、第三者が提供する情報を利用し
たサプライヤーの分類、優先順位付けに目を向ける必要がある。
最近では、テクノロジーを活用することで、既知の不正ドメインと
の関連性やC&Cサーバとのマルウェア通信、不十分な境界線防
御、および、セキュリティ衛生の悪化やセキュリティ体制の弱体化
を示す指標などの情報を基に、第三者／第四者サプライヤーの
セキュリティ態勢に関する知見を得られるようになっている。
これにより、セキュリティガバナンス／事業継続チームが実施する、
何百ものサプライヤー評価に関する要件に欠かせない背景情報
が得られる。
成果： セキュリティ体制のリアルタイム指標に基づく、サプライ
ヤー／パートナーの優先順位リストを作成。これに基づき、
組織は、現地監査やシミュレーションなどの取り組みを真に
最大のリスクを示している対象に絞って実施することが可能
2. アクセス権の再認証ビッグデータのマイニング機能および異常検出アルゴリズムにより、
アクセス再認証における企業の意思決定のサポートが可能となる。
人手で10～30件ものITアクセスポリシーを把握するのではなく、
ソフトウェアを活用することで、類似の従業員基盤全体のアクセス
プロファイルをレビューしてパターンを特定し、イレギュラーとみら
れる者のみにフラグを立てることが可能である。これによって、アプリ
ケーション担当者の役割は、異常を示す対象者の確認のみに作業
負荷が軽減される。
さらに、「サーバーX、資格グループY、統制Z」というフォーマットで
はなく、より分かりやすいフォーマット（例：事業アプリケーションへ
のアクセスA、メニューB、コマンドC＆D）のアウトプットを出せるよう
セキュリティサービスを構築できるようになれば、セキュリティに関す
る正しい意思決定を効率よく行うことができるようになる。
成果：異常の検出とデータマイニングによりアクセス実行に必要
な労力の大幅な削減
3. セキュリティの監視と対応前述の非効率的なログ管理に関する問題を解消するために、クラ
ウドセキュリティの専門家は、異常検出アルゴリズムなどのコン
ピュータ支援分析手法を見直す必要がある。
セキュリティサービスのAPIがログを受領し、人の介入なしにデータ
を自動的にレビューできるようになれば、サービスのコストを理由に
受領可能なデータ量に制限がかかることもなくなる。多くの分析
タスク同様、提供データが多いほどアウトプットの質は向上する。
レイテンシー、データ主権、セキュリティという、クラウドが抱える
三つの共通課題が解決されれば、セキュリティ監視・対応APIは現行
のMSSP手法およびビジネスモデルを一新し、最終的に、顧客に
これまでより大幅に優れた価値を提供できるようになる。
成果： データマイニングと異常の検出によって達成される、
セキュリティ警告の監視と分析に必要な労力の大幅な削減
9PwC Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿 12
10Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿
4. 暗号化ソフトウェアエンジニアが開発するアプリケーションは、標準化された
暗号化手法をベースにする必要がある。これにより、クラウドセキュリ
テの専門家は社内で開発され未検証の暗号化手法を使用するリス
クを低減させることができる。
また、暗号化APIは、多くのチーフ・リスク・オフィサーが積極的な
クラウド採用をためらう原因を解消するのに役立つ場合もある。リ
スク専門家は、オペレーションを実行するのと同じクラウドインフラ
内にマスターキーを保管することに不安を感じている。そのため、ク
ラウドセキュリティの専門家は、キーがコンポーネントに分割された上で
ベンダー間で保管され、ベンダーが単独でマスターキーを作成でき
ないように、CaaS/KMSaaSソリューションの評価を行う必要がある。
正しく実装されていれば、暗号化APIはパブリッククラウドの採用
促進につながる。
成果： 暗号化実行時の標準方法で、脆弱な暗号プロトコルや
方法の実行を回避
5. 統合スレットインテリジェンス境界保護に焦点を当てていた時代は過ぎ、現在、クラウドセキュリ
ティの専門家は、効果的なセキュリティ戦略には能動的に脅威を管
理する機能を活用する必要性があることを認識している。とはいえ、
スレットインテリジェンスプラットフォームを入手するだけでは不十分
である。新たな脅威がないかを確認可能なエンドポイント検出機能
を統合し、テクニカルな分析指標を抽出できるようにしなくてはなら
ない。
テクニカルな分析指標を用いて対象領域をスキャンし、脆弱性を検
索できる統合スレットインテリジェンスのAPI用いることで、本要求に
対応することが可能である。
6. インフォメーションセントリックプロテクションクラウドコンピューティングにより、開発者は一番得意とすること（イン
フラ管理ではなくアプリケーション開発 ）に集中できるようになる。
セキュリティに関しても、同様であり、クラウドセキィリティの専門家は、
インフラではなくデータに注力し、エンドツーエンドでデータを保護
するデータ指向のセキュリティソリューションを活用すべきである。
それにより、データが保持されるインフラを問わず、データのアクセス
権を承認された者に限定することが可能となる。
標準化されたデータ／情報指向保護サービスを利用することにより、
組織のセキュリティ機能ポートフォリオの統合化をさらに進めることが
できる。この サービスを使用することにより、クラウドセキュリティの
専門家は、過去に定めたデータ損失防止／アクセス統制ポリシーを
用いて、情報保護に関する意思決定の推進ができるようになる。
成果：組織外でも機密データを保護する集中セキュリティポリシー
7. リアルタイムアシュアランス（GRC）毎月作成するセキュリティレポートスライドや毎週のセキュリティ
ダッシュボードの利用は無くなりつつある。セキュリティ自動化の
大きなメリットのひとつは、セキュリティAPIにてデータをマイニングし、
セキュリティ体制のリアルタイムビューを抽出する可能なことである。
継続的な脆弱性スキャン、構成コンプライアンス監視、アンチウイルス
製品その他の統制から提供されるデータを、既知の脅威と関連付
けることが可能になり、SOCが処理を行い組織幹部にサイバーリスク
のリアルタイムビューを提供する。
成果：セキュリティリスクとパフォーマンス指標に基づく、組織の
セキュリティ体制のダイナミックかつリアルタイムの概要を提供
成果：人による介入ゼロ（または最小限）で新たな脅威を迅速に
検出
ネクスト ステップ本書はクライアントとの協働中にPwCが確認した共通課題を説明し、課題に対する一つのソリューションを記載している。サイバー攻撃に対する包括的な対策ではないが、本書で挙げた手法は、従来のセキュリティアーキテクチャにはない、次世代セキュリティアーキテクチャを特徴付けるものであると私たちは考えている。その他のセキュリティ上の課題や、解決策を支援したい場合は、こちらにて実施されているディスカッションにぜひ参加していただきたい。： https://pwc.blogs.com/cyber_security_updates/
11PwC Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿 12
Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿 12
寄稿者
Anton Tkachov
著者
PwC フィナンシャル・サービス・サイバー・セキュ
リティ・チームのチーフセキュリティ設計者。極め
て複雑なセキュリティ課題を解決するために、
銀行・保険・資本市場のクライアントをサポート。
情報・サイバーセキュリティ分野で14年以上の経
験を誇る。PwC入社以前は、大手多国籍テクノロ
ジー・コンサルティング組織やさまざまな大手金
融サービス組織に所属。
セキュリティ組織は、クラウドコンピューティングの原理を適用することで、現代企業の期待に応える、より優れた、迅速かつアジャイルなサービス提供が可能になる、と考えている。
George Florentine
著者
PwC フィナンシャル・サービス・サイバー・セキュ
リティ・チームのセキュリティコンサルタント。銀行・
保険・資本市場に属する幅広いクライアントと協働。
情報セキュリティに関して広範な専門知識を有す
る。PwC入社以前は、金融サービス業界クライア
ント向けにセキュリティサービスを提供する、世界
有数のシステムインテグレーターに所属。
大規模クラウド採用は必然的流れであり、一部は
遅れを取っているものの、セキュリティ業界全体と
しては、企業のクラウドテクノロジーおよび関連手
法の導入実現に向けて、大きな進歩を遂げてい
ると考えている。
Paul Gamble
編者
英国およびアイルランドのアライアンス事業チーフ・
テクノロジー・オフィサー（CTO）。Symantec の全体
的テクノロジー戦略および当社のアドバイザリーお
よびテクノロジーアライアンスを指揮。
セキュリティアーキテクチャ、情報管理、サービス管
理などのITビジネス分野で25年以上の経験を有す
る。この 18 年間は、通信、金融、小売、エネルギー、
公共 （英国）部門など幅広い領域に携わる。直近
の4年間の大半を、Symantec社のトップクラスのアド
バイザリーパートナーとの共同サイバー・インテリ
ジェンス・サービスの開発に注力。
13PwC Security in a Box―クラウド・セキュリティ・アーキテクチャのあるべき姿 12
本報告書は、PwCメンバーファームが2018年1月に発行した『Security in a Box - Security in a box – a blueprint for cloud security architecture』を翻訳したものです。翻訳には正確を期しておりますが、英語版と解釈の相違がある場合は、英語版に依拠してください。
This publication has been prepared for general guidance on matters of interest only, and does not constitute professional advice. You should not act upon the information contained in this publication without obtaining specific professional advice. No representation or warranty (express or implied) is given as to the accuracy or completeness of the information contained in this publication, and, to the extent permitted by law, PwC does not accept or assume any liability, responsibility or duty of care for any consequences of you or anyone else acting, or refraining to act, in reliance on the information contained in this publication or for any decision based on it.
© 2019 PwC. All rights reserved.PwC refers to the PwC network member firms and/or their specified subsidiaries in Japan, and may sometimes refer to the PwC network. Each of such firms and subsidiaries is a separate legal entity. Please see www.pwc.com/structure for further details.
Design Services 30868 (08/17).
www.pwc.com/jp
日本のお問い合わせ先
PwCコンサルティング合同会社
〒100-6921 東京都千代田区丸の内2-6-1
丸の内パークビルディング
03-6250-1200（代表）
林和洋
パートナー
PwCコンサルティング合同会社
〒100-6921 東京都千代田区丸の内2-6-1
丸の内パークビルディング
03-6250-1200（代表）
小林 公樹
シニアマネージャー