作成者別アーカイブ: 諸角昌宏

2024: クラウドセキュリティ・ティーンエイジャーにとって重要な年

2024: クラウドセキュリティ・ティーンエイジャーにとって重要な年(2024: A Critical Year for the Cloud Security Teenager)

本ブログは、2024年のスタートに当たって、CSA本部のCEO Jim Reavis のメッセージとして以下のブログに掲載された内容の日本語訳になります。本ブログは、Jim Reavis の許可のもとに公開していますが、本ブログの内容とCSA本部のブログとに相違があった場合には、CSA本部のブログの内容が優先されます。

https://cloudsecurityalliance.org/blog/2023/12/29/2024-a-critical-year-for-the-cloud-security-teenager/

Blog Article Published: 12/29/2023
Written by Jim Reavis, Co-founder and Chief Executive Officer, CSA.

2024年、クラウドセキュリティアライアンスは15周年を迎えます。この間、私たちは世の中の様々な変化、技術シーンの移り変わり、そしていくつかのクラウドセキュリティベンチャーの誕生と消滅を見てきました。これほどダイナミックな世界では、企業もかつてのような長寿ではありません。テクノロジーの移り変わりを通してベストプラクティスのリーダーシップに焦点を当てた非営利組織として、私たちはまさに10代の若者のように感じています。私は、「次はどうなるのですか」と尋ねるスタッフやその他の人々に、CSAは100年間ミッションを継続する構造になっていると話すのが好きです。

クラウドの歴史(A Quick History of the Cloud)

2024年は非常に興味深い年になるでしょう。私はこのブログを使って、今年私たちが取り組んでいくこと、私たちが対応し対処しようとしている主なトレンドを書いていきたいと思います。私にとって、これを説明する良い方法は、クラウドの歴史を世代別に簡単に説明することです。

クラウド0、あるいはプリクラウドとは、コンピューティングの歴史の中で、クラウドにつながるいくつかの発展を意識したものです。メインフレームコンピュータとその仮想マシンおよびタイムシェア機能が良い例です。1980年代のIntel 80836プロセッサは、PCに仮想マシン機能をもたらしました。より最近の歴史では、アプリケーションサービスプロバイダ(ASP)が、他人のコンピューターで仕事ができる素晴らしい例であり、SaaSの先駆けでした。

クラウド1.0は、私たちが今日使っているクラウドコンピューティングの最初のバージョンと認識しているもので、本質的には、前述の仮想マシンやストレージといった従来のITサービスを、革新的な新しいビジネスモデルで提供するものでした。私たちは、この初期にCSAに着手し、2007年に計画を立て、最終的に2009年のRSAで発表しました。

クラウド2.0は、クラウドネイティブと呼ばれる、クラウド特有の技術やフレームワークの出現を表しています。コンテナ、サーバーレス機能、DevOpsなどのほか、Cloud Security Posture Management(CSPM)などのクラウドネイティブセキュリティソリューションが挙げられます。

クラウド2.0の始まりの時期についてはいろいろな意見があります。長い間開発が進められていたクラウドネイティブが主流になったのは2016年頃で、これが始まりと私は考えています。2020年には、パンデミックによって在宅勤務が急増し、バーチャルで仕事をし、バーチャルで考えるということに対して、従来のセキュリティアーキテクチャや戦略がいかに破綻しているかが露呈しました。クラウドへの移行が加速し、cloud sprawl(クラウドの無秩序)を保護する戦略としてゼロトラストが再発見され台頭してきました。

クラウド3.0は2022年に始まりました。サイバーセキュリティの景気後退がこの歳の中頃に見られ、IPOが中止され、資金が枯渇し始めました。生成AIと大規模言語モデル(LLM)は、2022年後半にLLMプロンプトをクラウドサービスとしてリリースし注目を集め始めました。

私は、クラウドとAIに赤ちゃんが生まれ、それをChatGPTと名付けたと冗談を言うのが好きです。私にとっては、クラウド3.0は生成AIとクラウドネイティブの融合であり、今後何年にもわたって私たちが使うことになるクラウドのバージョンになることを約束するものです。私たちの業界により具体的に言えば、すべてのベンダーと企業のセキュリティチームは、クラウドセキュリティを新たに作り出すための自動化、拡張、ブレークスルーの創出に生成AIを活用しようとする「コパイロット化」の段階を迎えています。

2024年に何が起こるか(What’s Coming in 2024)

クラウドセキュリティアライアンスは、明日の問題を今日解決するために最善を尽くすよう努めています。そのため、これらのトレンドを理解し、業界に適切なサポートを提供できるようにしたいと考えています。以下に、2024年に向けての私たちの着目点を概説したいと思います。

AI Safety Initiativeについてはすでにご存知でしょう。我々のグローバルなフットプリントを活用して、クラウドのために行ってきたAIに関する研究、教育、認証機能のすべてを提供することを期待しています。重要なことは、私たちはAIを次の光り輝くものとして移行しようとしているのではなく、AIがクラウドに到来し、クラウドを変革しつつあるということです。フロンティアであるLLMやハイパースケーラー、そして事実上すべてのSaaSソリューションがAIを提供することで、究極のセキュリティ責任共有シナリオが生まれつつあります。

私がサイバーセキュリティの同僚に印象づけられることが1つあるとすれば、悪意のある行為者によるAIの採用(AIのコードスキャンを考えてみましょう)は、大きな課題を生み出すということです。AIの採用については慎重を期すことができるかもしれませんが、悪意のある行為者とそれに必要な対策とが交差するところではそうはいきません。

CSAは2023年末に、幅広いゼロトラストの知識を証明する業界初の資格、Certificate of Competence in Zero Trust(CCZT)を導入しました。これは、2024年に私たちにとって大きな重点分野となります。戦略として、ゼロトラストはあらゆるタイプのコンピュートシステムのセキュリティを強化するために使用され、全体として最も一般的な戦略になると考えています。私は以前、ゼロトラストを次のバージョンのインターネットのセキュリティ設計図と見ていると述べました。私たちは、これまで明らかにしてきたベストプラクティスを基に、AI向けの具体的なゼロトラストのユースケースなど、新たな分野でイノベーションを起こすつもりです。

CSAのSecurity, Trust, Assurance and Risk (STAR)プログラムは、クラウドプロバイダの保証表明の世界最大のリポジトリを提供しています。STAR は、最も人気のある調査成果物であるクラウド・コントロール・マトリックス(CCM)で構成されています。

STARは2011年に発行されたにもかかわらず、2023年に最も成長した成果物です。多くの企業のベンダー管理の中心的存在であり、多くの国や業界で標準となっています。私たちは、IT GRCの近代化の最前線にいることを確認するために、いくつかのプロジェクトを進行中です。AIの保証および保証のためのAIの活用の両方が取り上げられています。管理策の継続的なモニタリングは重要です。業界、国、テクノロジーセグメントによって使用されている多くのコンプライアンスフレームワークを調和させることが重要です。

歴史のあるCertificate of Cloud Security Knowledge (CCSK)プログラムが2024年半ばにバージョン5に更新されることをお知らせできることを大変嬉しく思います。クラウドセキュリティプロフェッショナルのための業界標準であるこのプログラムは、テクノロジーとプラクティスの適切なバランスを備え、クラウド3.0がサイバーセキュリティにとって何を意味するかを示す生きた見本となります。私たちは、CCSK v5の立ち上げにおいて、既存の資格保有者に最も簡単なパスを提供することをお約束します。皆様のご愛顧に感謝いたします。

これらは2024年における主な優先事項ですが、CSAらしく、私たちは野心的で、コミュニティに対応し、皆さんにとって重要な問題を幅広くカバーすることに重点を置いていきます。私たちと交わる機会はたくさんあります。CSAのバーチャルイベントや直接参加できるイベントにぜひお越しください。支部に参加しましょう。リサーチワーキンググループに参加しましょう。オンラインコミュニティ「circle」に登録しましょう。年寄りの私は、私たちの業界が文字通り一つの部屋に収まることができた頃を覚えています。幸いなことに、それはもはや不可能であり、我々は世界のビジネスの多くで重要な役割を果たしています。2024年、この責任をしっかり果たしていきましょう。

以上

CCAKの合格者経験記

《CCAKの合格者経験記》

2023年9月20日
三優監査法人
システム監査技術者、CCAK
堺 由美子

🔳CCAK取得の目的と経緯

クラウドセキュリティの監査について体系的に学ぶこと、「英語で勉強・英語で資格取得」に慣れることを主な目的として、新設されたCCAKに挑戦することを2021年春に決意。途中、別の資格試験を優先したり業務多忙で勉強を中断したりの後、2023年7月初旬にようやく受験、合格しました。

🔳どこからスタートだったか

  • CCAKは「CCSKをベースにして、それを補完する内容」とされていますが、CCSKは未取得(未勉強)でした。
  • システム監査やITガバナンス、情報セキュリティの知識、データセンター・クラウドの各種認証取得実務の経験がありました。
  • 技術者ではありません。
  • 英語は、読むのがそれほど苦ではない(何度も同じ単語を辞書で引いても折れずに読み続けられる)レベルでしたが、英語での勉強・受験は未経験でした。

🔳使用した教材

  • CCAK Study Guide
  • 諸角さんの講演資料(「クラウド監査人向けクラウドセキュリティ認定資格 CCAK(Certificate of Cloud Auditing Knowledge) 解説」, 2022年1月24日)。本資料はこちらからダウンロードできます
  • CCAK Questions and Answers Collection(200問の問題集)
  • CSAおよびCSAジャパンの各種ドキュメント(セキュリティガイダンス v4.0他)
  • UdemyやLinkedIn Learningの「XX入門」講座(DevOps等、そもそも不足していた知識の補強)
  • また、会社(当時)でMicrosoft Azureの資格試験を受ける機会があったので、ボキャブラリ獲得と英語受験の練習としてMicrosoft Azure Fundamentals (AZ-900)を英語で勉強・受験しました。

🔳学習方法

当初はStudy Guideの目次と各章冒頭にあるOverviewで全体の構成を把握し、気になる箇所・知識不足の箇所を中心に読んでいこうとしましたが、”Governance”や”Compliance”がいろいろなところに出てきたりして構成があまり頭に入って来ず、捗りませんでした。

そこでQuestions and Answers Collectionに取組み、正答できなかったところをStudy Guideで確認、惨敗なところは一旦中断してCSAジャパンの翻訳資料を参照したり、Udemy等の入門講座をあたりました。Questions and Answers Collectionは3回くらい繰り返したと思います。

🔳CCAK取得に挑戦中/取得を検討中の方へのTIPS

  • Study Guide
    • PDF版がおすすめです。ダウンロードで即入手できますし、わからない単語を調べたり翻訳したりが簡単です。(読み上げツールも試しましたが、起きていられませんでした。)
      とはいえ断然紙の方が勉強しやすいので、PDFファイルを好きなところで分割し、ネットのプリントサービスで製本して利用しました。
  • Questions and Answers Collection
    • ブラウザで利用するので、ページの翻訳が使えます。英語で読んで英語で回答しないと試験対策になりませんが、解いた後の回答確認・解説は適宜翻訳して日本語で読み、脳の負担を減らしました。
    • 回答の解説は、残念ながら日本の情報処理技術者試験の問題集のようには全く充実していないです。
    • 購入すると12ヶ月間アクセス可能ですが、6ヶ月単位で延長できます(39ドルでした)。
  • 受験申込み
    • 購入すると有効期限が12ヶ月あります。準備万端となっていなくても購入し、自分を追い込むのも一手です。(有効期限が近づくと「これをもう一回受けるのはイヤだ!(受験料も高いし円安だし)」が強烈なモチベーショとなり、壮絶なまでの締切効果を得て乗り切れました。)
  • 受験当日(オンライン)
    • CCSKとは異なり、試験中は何も参照できません。
    • 試験官やカスタマーサポートも外国人で英語、本人確認に国内の免許証等は使えません。
    • (ISACAに旧姓で登録しているのにGovernment Issued ID Family Nameが空欄のままだったので、パスポートでも本人確認してもらえないことにチェックイン時になって気づき、試験直前に英語サバイバル訓練を余儀なくされてかなり消耗してしまいました。)
    • 早めにISACA Certificate Programs Exam Guideをよく読み準備しておくことをおすすめします。

🔳受験を終えて

以前から効率的な知識習得のために資格試験を利用していましたが、今回も「無知の知→勉強」を繰り返し、英語訓練もできたので、大変でしたが挑戦して良かったです。

CSAジャパンの豊富な翻訳資料・講演資料に大いに助けられました。どうもありがとうございました。

以上

SaaSのセキュリティ運用負荷を軽減させる方法とは

SaaSのセキュリティ運用負荷を軽減させる方法とは

クラウドセキュリティ自動化WG
株式会社マクニカ
根塚 昭憲

クラウドセキュリティ自動化WGでは、クラウドセキュリティにおける運用担当者の方の負担を少しでも下げるために、様々な監視自動化の仕組みを紹介したいと考えています。まずはSaaSのセキュリティ自動化について取り上げたいと思います。

DXの中で進められていた業務システムのクラウド化は、コロナウイルス感染拡大に伴う企業のワークスタイルの変化によりさらに加速。企業ではテレワーク、Web会議システム、オンラインストレージなどのクラウドサービスなどのSaaSの導入が飛躍的に進みました。SaaSは拡張性もあり、導入もしやすい一方で、企業の機密データを扱うケースも多く、高度なセキュリティが求められています。

一方で、SaaSからの情報漏洩インシデントも多く発生しており、いくつか例を挙げたいと思います。

  • 【複数企業で発生した事例】(2019年)
    プロジェクト管理システム(Jira)における、グローバル設定での設定不備により主にUSの企業データと個人情報の漏洩のリスクが露呈
  • 【Microsoft PowerAppsの事例】(2021年)
    Microsoft Power Appsの設定ミスにより、個人情報、社会保障番号、氏名、メールアドレスなどの機密データが計3800万件流出
  • 【某教育委員会の事例】(2022年)
    公立小・中・義務教育学校の令和3年度末退職予定者を対象にGoogleフォームを使って行ったアンケートにおいて、回答者に対し、結果の概要を共有する設定にしてしまったことにより、回答者の名前が他の回答者に閲覧できる状態であったことが判明した

Google Formsの結果の概要を表示する設定(デフォルトは無効)

  • 【複数企業で発生した事例】(2022年)
    複数の企業が、タスク管理ツール(Trello)の設定を誤って利用し、社内情報や個人情報が外部に公開され、検索可能となっていたことが判明。内閣サイバーセキュリティセンター(NISC)からも注意喚起が行われるほど、話題となりました。
  • 【某自動車会社様の事例】(2023年)
    ソフトウェア開発用のプラットフォーム(GitHub)において、データベースへのアクセスキーを含むソースコードが公開状態となっていた。このアクセスキーを利用することで、データサーバーに保管されているメールアドレスおよびお客様管理番号にアクセスできたことが判明。多くの場合、これらの問題はSaaSの設定不備から生じています。
    この点を示すデータとして、2022年に実施されたCSAの調査1では、SaaSセキュリティインシデントの63%が設定不備に起因する可能性が示唆されています。さらに、IPAが公表したデータ2によれば、2022年の不正アクセスの原因別比率では、設定不備が全体の16.1%で2位にランクされています。このことからも、SaaSの設定不備の対策検討が非常に重要であることがわかると思います。

なぜセキュリティ的に問題が発生しうる設定不備が発生するのでしょうか。
その答えは単純な作業ミス、設定ミスという人為的な問題ではなく、以下のような様々な要因が複雑に絡んで発生していると考えられます。

  • 【少ない設定監査機会と手動での設定チェック】
    国内の企業でよくあるSaaSの導入プロセスとして採用判定時に、セキュリティチェックシートなどを活用してSaaS全体のデータ管理方法や、物理セキュリティ、コンプライアンスなどを確認してから利用可否を決定します。その後でSaaSの設定が行われていくのですが、設定が適切かどうか、セキュリティ的に問題が無いかどうかの確認はその導入時のみで、その後、セキュリティ設定の定期的な確認や監視を怠っている企業は少なくありません。さらに、定期的に設定確認を実施している企業でも、手動で設定を確認している場合もあります。この手動での設定確認は時間とリソースを消費し、SaaS利用数が増えれば、その対応量も増えていきます。そのため、運用に対応できない状況や工数ばかりかかる事態を招きかねません。
  • 【SaaS毎に異なる設定と適切な設定判断】
    SaaSプロバイダーは異なる用途に対応するために多様な機能を提供し、その動作仕様や設定内容はSaaSごとに異なります。そのため、セキュリティの高い設定や、利用者の利便性も損なわない最適な設定を、各ベンチマーク(CISやCCMなど)を元に適切に判断してくことは、比較的難しいと思われます。このことも設定ミスを招く要因の一つと言えるでしょう。
  • 【セキュリティ部門以外での運用管理】
    事業部でSaaSの運用管理を一任されているケースもあります、セキュリティ担当ではないチームで運用を行う場合、上記のような設定監視運用やセキュリティチェックの複雑さに対応しきれないケースも考えられ、このような運用体制の課題も要因の一つとして考えられます。実際に、CSAの調査1でも、SaaSの設定に最も責任を持つ部門はセキュリティ部門が59%、IT部門が50%、そしてビジネスアプリケーションの所有者が40%という結果が出ており、これはセキュリティ部門の外に存在する複数の部門がSaaSの設定に関与していることを示しています。

また、上記の要因をさらに加速させている背景として以下も考えられます。

  • 【SaaS運用管理の複雑さの増加】
    • SaaS設定の可視性の欠如
    • 企業が管理するSaaS数の増大(11SaaS以上導入する企業が3割以上、40SaaS以上の企業も増加)3
    • SaaSの更新頻度の高さ
    • SaaSとSaaS間におけるデータ連携、API連携の増加における複雑性の増大
    • デフォルト設定では十分なセキュリティが考慮されていないケースがある

このような状況の中で、セキュリティ課題、運用課題を自動的に解決できる仕組みが、SaaS Security Posture Management(SSPM)と呼ばれるソリューションがあります。これはSaaSアプリケーションの設定不備によるインシデント(不正アクセス、機密情報流出、etc)を予防するためのソリューションとなります。
CSPM(Cloud Security Posture Management)と名称が似ていますが、CSPMは主にIaaSに対する設定監査の機能を提供するのに対し、SSPMはSaaSに対する設定監査を提供するという違いがあります。

SSPMは主に以下の機能を提供します。

  • 構成、設定の分析/追跡の自動化
  • コンプライアンス準拠状況の評価
  • データアクセス権の評価
  • リスクの検出
  • 分析結果の可視化
  • ダッシュボード
  • アラート
  • リスクを軽減するための改善方法の教示
  • 設定項目
  • 設定パラメータ

動作としては主にAPIで各SaaSに対してアクセスを行い、設定情報を網羅的に監視・解析します。製品にも依存しますが、各設定をセキュリティベンチマークと比較し、どの程度準拠しているかを即座に確認することが可能です。ほぼ全てが自動化されているため、今まで数日かかっていた目視・手動での設定確認作業は不要となります。一部のSSPMでは、設定に課題がある場合、影響を受けるユーザをリストアップしてくれる機能もありますし、設定の修正案を提示、SaaS間連携の可視化など、SaaSの設定をセキュアに維持できる機能を備えています。そのため、先ほど挙げた設定ミスの複数の要因を網羅的にカバーできるソリューションとなっています。

SSPMは比較的新しいソリューションで、徐々に市場に浸透しつつあり、お客様の実績も出てきてます。
ただ、海外ベンダーが提供しているSSPMの対応SaaSの9割以上が海外製SaaSとなっており国産SaaSへの対応はまだ十分ではありません。SSPMの利用を検討されている日本のお客様からも国産SaaSの対応数を増やしてほしいという声が多くあがっています。これは今後のSSPMが普及しいく中での課題といえるでしょう。

代替のツールとして各SaaSベンダー自身が提供する各テナントの設定状況チェックするツールもありますが、提供元のSaaSしか監視できない可能性が高く、SaaS毎の管理が必要となり煩雑さが残ります。そもそも大手SaaSベンダー以外からはそのようなツールがリリースされていない現状もありますので、その点でも複数のSaaSを管理しているのであれば、一気通貫で確認できるSSPMの方にメリットがあると考えています。

また、類似のソリューションとして、CASBがあげられます。
CASBの機能の一つに、APIを使って各SaaSに対するコントロールを実現する機能がありますが、どちらかというとユーザのアクティビティ監視やファイルチェックを行うことがメインの機能となっており、SSPMがカバーする設定の監査機能とは別物になります。
ただし、ベンダーにもよりますが、CASB機能の一部としてSSPM機能が提供されるケースも出てきていますので、SaaSのセキュリティ全体を検討される際にはしっかり理解してご検討いただきたいと思います。

まとめ

SaaSからの情報漏洩の原因の多くは設定不備となっており、今後も利用の増加が見込まれるSaaSに対し、何かしらの対策がクラウドセキュリティの観点からは必要です。このような課題を解決するためにSaaS Security Posture Management(SSPM)が注目されています。SSPMは自動化された監視と改善のツールで、SaaSのセキュリティを強化し、設定不備から引き起こされる問題を軽減、同時にそれにともなう運用負荷も削減できます。今後のクラウドセキュリティ強化の一案としてSSPMも検討してもらえればと思います。

参考文献

※1 https://cloudsecurityalliance.org/artifacts/saas-security-and-misconfigurations-report/

※2 引用元:コンピュータウイルス・不正アクセスの届出状況 [2022年(1月~12月)]

※3 引用元:株式会社メタップス「2022年度 SaaS利用実態調査レポート」

以上

ゼロトラストの2つの成熟度モデルを理解する

Understanding the Two Maturity Models of Zero Trust
ゼロトラストの2つの成熟度モデルを理解する

本ブログは、CSA本部のブログに公開されている「Understanding the Two Maturity Models of Zero Trust」の日本語訳となります。原文は、こちらを参照してください。本ブログは、著者の許可のもとに翻訳し公開するものです。原文と日本語版の内容に相違があった場合には、原文が優先されます。


Blog Article Published: 05/17/2023
Written by John Kindervag, Senior Vice President, Cybersecurity Strategy, ON2IT Cybersecurity.

ゼロトラストの世界における一番の間違いは、一枚岩的な思考です。一口で象全体を食べることが可能であると信じてしまっていることです。組織の最大の間違いは、すべてのゼロトラスト環境を同時に展開しようとすることです。規模が大きすぎるのです。その結果、すぐに失敗します。このような組織は、ゼロトラストについて考え、議論することにすべての時間を費やしていますが、実際に実行に移すことはできません。

2つ目の関連する間違いは、戦術的に考えすぎてしまうことです。製品や技術にのみ焦点が当たってしまっています。戦略を投げ捨てています。このような技術への過度の集中は、サイバーセキュリティの目的である「何を守る」ということを見失わせます。

このことは、進捗を測定することを難しくしています。私は、サイバーセキュリティの進歩を測る最適な方法は、成熟度であると確信しています。

Forrester Researchに在籍中、私は包括的な企業サイバーセキュリティ成熟度評価プロジェクトに携わりました。その後、私はそれをゼロトラストの最初の成熟度モデルに適応させ、報告書にまとめました: “Asses Your Network Security Architecture with Forrester’s Zero Trust Maturity Model “というレポートです。(注)私がレポートを執筆したのは2016年末ですが、出版されたのは私がForresterを退社した後の2017年です。筆者名のところに私が3番目に記載されているのはこのためです)。

“Asses Your Network Security Architecture with Forrester’s Zero Trust Maturity Model” レポートの最初のページが以下です。

図1

何年もかけて、実際の顧客との関わりの中で、このモデルを改良する機会を得ました。このモデルは、NSTACの報告書の中で体系化されています。Appendix Aをご覧になれば、より深く理解することができます。

簡略化した図が下の図です。これは、最近CSAで行ったプレゼンテーションも含め、モデルを説明する際に使用している図です。

図2

この成熟度モデルは、「ゼロトラスト」の5ステッププロセスに基づいており、プロテクトサーフェス単位でスコア付けされます。カーネギーメロン大学が開発した標準的な5段階の成熟度パラダイムを使用しています。

各プロテクトサーフェスは個別にスコア付けされます。このモデルでは、プロテクトサーフェスとDAASの両方の要素を特定することが必要です。このようにして、成熟度のスコアを管理しやすい一口サイズの塊に分割しています。プロテクトサーフェスとしてディレクトリサービスを使用した例は、NSTACの報告書のAppendix Aに記載されています。

つまり、プロテクトサーフェスが完全に最適化されていれば、最大25点というスコアで採点されることになります。ON2ITでは、このようなことはほとんどありません。

図3

次に、すべてのプロテクトサーフェスを集計して、組織の総合スコアとプロテクトサーフェスごとの平均スコアを定義することができます。この例では、平均成熟度スコアは3.8であることがわかります。また、すべてのプロテクトサーフェスにおける成熟度の分布も見ることができます。この情報をもとに、組織は成熟度の低い特定のプロテクトサーフェスを重点的に強化することができます。

図4

では、新しいCISAゼロトラスト成熟度モデルはどのようにフィットするのでしょうか。この成熟度モデルは、実は5ステップ成熟度モデルにうまく統合されています。両者は補完関係にあると考えたほうがよいでしょう。

図5

私は最近、CISAの本社に行き、CSA Zero Trustの運営委員会のメンバーであるSean ConnellyとJohn Simmsを含む、この文書を作成した数人の人物とこの話題について話し合う機会を得ました。私たちは、5ステッププロセスの各ステップで使用される適切なテクノロジーをどのように定義できるかについて議論しました。

プロテクトサーフェスごとの成熟度モデルとCISA成熟度モデルの間のほとんどのマッピングは、ステップ3:ゼロトラスト環境の構築で行われます。以下は、ON2IT AUXOマネージドサービスポータルでどのように表示されるかの例です。

図6

どのコントロールが実施され、どのコントロールがまだ必要なのかを確認することができます。ポータルサイトでは、プロテクトサーフェスをForrester ZTXフレームワークまたはCISA成熟度モデルにマッピングしたレポートを作成することができます。

ForresterのZTXフレームワークといえば、まさにPillar(柱)成熟度モデルの前身といえるでしょう。Chase Cunningham博士がフォレスター・リサーチに在籍していたときに作成したもので、「プロテクトサーフェスごとの成熟度モデル」を補完するために作られました。この歴史は失われてしまいましたが、フレームワークの意図と、それがどのように “柱” につながったかを理解することは重要です。ChaseとForresterの彼のチームは、称賛に値します。

図7

では、どちらの成熟度モデルを使うのが良いでしょうか?その答えは、両方です。なお、CISAの文書には、「CISAのZTMMは、ゼロトラストへの移行をサポートするための多くのパスの1つです」と記載されています。

多くの組織が「柱のモデル」を文字通りに受け取りすぎており、それが重大な実装の問題につながっています。例えば、ある組織は、左から右へ進めていく必要があると考え、アイデンティティの柱から始めます。組織内のすべてのアイデンティティの問題を解決してから、デバイスの柱に移らなければならないと考えています。しかし、これは不可能なことです。この組織は、ID のアップグレードが必要な数千のシステムがあることを認識します。また、多くの組織と同様に、組織全体で複数の異なるIDソリューションを使用する必要があります。そのため、たとえ 1つのシステムの ID ソリューションを最適化できたとしても(CISA モデルのレベル 4)、すべてのシス テムの成熟度レベルは 1 のままになります。これはおそらく永久に続くことでしょう。

よりシンプルで効果的なソリューションは、1つのプロテクトサーフェスを取り上げ、柱にまたがる既存のコントロールをマッピングし、成熟度のギャップを判断することです。その情報をもとに、組織はプロテクトサーフェスの成熟度を向上させるためのプロジェクトを立ち上げることができます。そして、プロテクトサーフェスの成熟度をCISAモデルにマッピングしたレポートを作成すれば、短期間で進捗を確認することができます。

以上

グローバルプロバイダが日本語CAIQ評価レポートを登録する方法

2023年4月3日
CSAジャパン 諸角昌宏

本ブログは、すでに英語のCAIQ自己評価レポートをCSAのSTAR Registryに登録しているプロバイダ(グローバルにクラウドサービスを展開するプロバイダ)が、日本語でのCAIQ自己評価レポートをSTAR Registryに登録する方法について記載します。

  1. 日本語CAIQとSTAR Registryの状況
    まず、STAR Registryへの日本語CAIQ評価レポートの登録についての状況について説明します。

    • STAR Registryへの登録に必要なCAIQ評価レポートの内容(EXCELシートに書き込む言語)は、英語でも日本語でも可能です。
    • STAR Registryのサイトは英語でできているため、登録方法、運用はすべて英語になります。登録時の手順(ウエブの登録用画面等)はすべて英語になります。また、STAR Registryの検索等の運用もすべて英語になります。

この状況を踏まえて、CSAジャパンでは、「日本語での評価レポートの公開方法およびLevel1セルフアセスメントの重要性について」というブログで、日本語で評価したCAIQをSTAR Registryに登録する方法を紹介しています。しかしながら、こちらはあくまで日本のプロバイダがSTAR Registryに登録する場合を想定していますので、すでにCAIQを英語で登録されているプロバイダが日本語CAIQを追加する方法が分かりません。そこで、その方法について説明したものが本ブログになります。

  1. すでに英語版のCAIQ評価レポートを登録されている場合の日本語CAIQ評価レポートの登録方法CSAグローバルに確認したところ、複数言語に対して、以下の対応を行っています。
    STAR Registryの登録ページの以下のDocument Upload ページで、Supporting Documentにアップロードすることでできます。

    以下のようにすることで、英語版と日本語版の両方をアップすることができるとのことです。
    Primary Document: 英語版CAIQ
    Supporting Document #1: 日本語版CAIQ

    STAR Registryそのものはマルチリンガル対応していないのですが、複数のCAIQ評価レポートを公開する仕組みはできているので、これを使うことが可能になるということです。
    なお、登録自体は本社(英語版を登録した部署)の方でSTAR Registryを担当されている方と共同して行っていただく必要があります。

  2. 日本語版CAIQ評価レポート登録後のCSAジャパンの支援
    STAR Registryでは、日本語でCAIQ評価レポートを登録しているのを検索することができません。つまり、プロバイダが日本語で公開しているかどうかは、STAR Registryで該当するプロバイダの登録内容を確認してみないと分からないということになります。そこで、CSAジャパンでは、日本語でCAIQ評価レポートを公開しているプロバイダが一目でわかるように、また、日本語でCAIQ評価レポートを公開していることを周知できるように、以下のように支援しています。

    • CSAジャパンの以下のウエブページから、日本語版CAIQ評価レポートを公開しているプロバイダを紹介します。https://www.cloudsecurityalliance.jp/site/?page_id=19811
      現在、「準備中」ということで、プロバイダの情報が整い次第公開を開始します。
    • CSAジャパンのホームページの新着情報として紹介します。
    • CSAジャパン会員及び連携団体向けメールニュース配信を行います。
    • CSAジャパンのフェースブックグループから紹介します。
  1. 今後について
    CSAジャパンは、上記の方法による登録について、CSA本部の担当者およびSTAR/CCM/CAIQの責任者と連絡を取って対応します。従いまして、何か問題が発生した場合には、CSA本部と連携を取りながら対応していきます。
    それから、STAR Registryそのものをマルチリンガル対応にしていくことが必要と考えています。これに関しても、CSA本部と協議を進めていきたいと考えています。

以上

 

 

 

クラウドネイティブにおける新しい責任共有モデルとセキュリティの考え方

クラウドネイティブにおける新しい責任共有モデルとセキュリティの考え方

2023年3月29日
CSAジャパン クラウドセキュリティ自動化WG 諸角昌宏

クラウドの責任共有モデルは、サービスモデル(IaaS, PaaS, SaaS)に基づいて説明されてきた。しかしながら、新たに登場してきたコンテナ、サーバーレス等を用いたクラウドネイティブの環境における責任共有モデルを考えた場合、既存のサービスモデルに基づいた考え方ではカバーしきれないのではないかという懸念がある。CSA Silicon Valley Chapterでは、クラウドネイティブにおける新しい責任共有モデルの考え方を説明したThe Evolution of Cloud Computing and the Updated Shared Responsibilityというブログを2021年2月に公開した。これはCSAジャパンにより日本語化されクラウドコンピューティングの進化と新たな責任共有モデルとして公開されている。
ここでは、上記資料で説明されている新しい責任共有モデルに対して、CSAが公開した以下の資料におけるセキュリティの考え方を対応させることで、クラウドネイティブの責任共有モデルの考え方とそのセキュリティの考え方について統合して理解できるようにしたい。

なお、このクラウドネイティブの責任共有モデルは、標準として定められているものではなく、あくまで現段階における1つの考え方として提供されているものであるということは注意していただきたい。今後、NISTやISOにおいて、標準としてのクラウドネイティブの責任共有モデルが定義された際は、その標準に基づいて改めて考えていく必要がある。

  1. クラウドネイティブにおける新しい責任共有モデルの概要
    ここでは、まずクラウドネイティブにおける新しい責任共有モデルについて、「クラウドコンピューティングの進化と新たな責任共有モデル」の下図を用いて説明する。なお、ここで記述されているモデルをここからは便宜上「CNCFモデル」と呼ぶことにする。また、ここでは要点だけ説明するので詳細は上記資料を参照していただきたい。なお、下図は上記資料では英語で表記されているが、分かりやすくするため日本語に翻訳して表記している。
    図1 CNCFモデル(「クラウドコンピューティングの進化と新たな責任共有モデル」より引用、作成)

図の左で「CNCFレイヤー」と記載されているのはCloud Native Computing Frameworkとして、既存のサービスモデルのレイヤーに新たに追加されたクラウドネイティブのレイヤーである。これらのレイヤーは以下の内容になる。

  • プロビジョニングサービスプレーン
    このレイヤーは、コントロールプレーンにあたる。ここでは、Kubernetesで説明されているが、Dockerコントロールプレーンでも同様に扱うことができる。プロビジョニングサービスプレーンでは、コンテナの稼働や停止等の運用や、コンテナの配置、デプロイ時のコンテナ入れ替えや仮想ネットワークの提供等を行う。
    セキュリティの観点からは、コンテナのセキュリティを実装されるために必要となる機能およびアーキテクチャを提供するレイヤーとなる。
    このレイヤーは、IaaSを除くすべてのモデル(K8s-aaS, CaaS, FaaS, NoCode, SaaS)においてプロバイダの責任となる。IaaSにおいては、このレイヤーにあたるKubernetesやDockerを利用者がインストール・設定・運用・管理を行うため、利用者側の責任となる。
  • マネージドサービスランタイム
    このレイヤーは、データプレーンにあたる。コンテナが稼働する実行環境、もしくはサーバーインスタンスそのもので、コンテナランタイムを管理する。コントロールプレーンが提供する機能を実際にコンテナランタイムに対して実施するレイヤーとなる。
    サーバーレスの観点では、コントロールプレーンとデータプレーンの両方をプロバイダが管理することで、利用者はコンテナクラスタや仮想マシンなどのインフラストラクチャを管理しなくてもクラウドネイティブサービスに簡単に移行できるようになる。したがって、このマネージドサービスランタイムのレイヤーまでをプロバイダが管理するモデル(CaaS, FaaS, NoCode)がサーバーレスのモデルということになり、K8s-aaSはサーバーレスではないことになる(注:SaaSはアプリケーションを含むクラウド全体をプロバイダが管理するので、サーバーレスのカテゴリーからは除くこととする)。
  • アプリケーションビルドとパッケージ化
    このレイヤーは、コンテナイメージの作成、コンテナ環境への移動・実施といういわゆるビルドチェーンを管理する。クラウドネイティブの観点では、このレイヤーを利用者が管理する(CaaS)のか、あるいはプロバイダが管理する(FaaS, NoCode)のかということになり、サーバーレスの責任共有を考える上では重要なレイヤーとなる。後ほどサーバーレスの章で説明する「コンテナイメージベースのサーバーレス」(CaaS)と「機能ベース(ファンクションベース)のサーバーレス」(FaaS, NoCode)として、それぞれの責任を明確にすることが必要となる。
  • アプリケーション定義と開発
    このレイヤーは、アプリケーションのコードロジックを定義・開発する。アプリケーションの仕様と構成からコードを生成する際に、利用者が自身でコードロジックを作成する(FaaS)のか、あるいは、プロバイダが利用者の作成した仕様と構成からコードを生成する(No-Code)に分類される。クラウドネイティブの観点からは、この2つのモデルの差はあまりなく、FaaSの場合には利用者がビジネスロジックを直接コード化する(Python等を用いる)のに対して、No-Codeの場合にはプロバイダが提供するGUI等を用いてドラグ&ドロップなどによってコードロジックを作成する。No-Codeに対してLow-Codeという方法もありこれはGUIだけでなく一部のコードロジックについては直接作成する。
    セキュリティの観点では、このレイヤーは基本的に利用者が管理を行うが、No-Codeの場合にはGUIを提供する部分がプロバイダの責任となる。責任共有の観点からはあまり区別する必要は無いと思われる。
  1. コンテナセキュリティ
    ここでは、CSAが公開している「安全なアプリケーションコンテナアーキテクチャ実装のためのベストプラクティス」に基づいてコンテナセキュリティについて説明する。この資料では、コンテナのセキュリティについてアプリケーションの開発者および運用者の観点で書かれているので、上記のモデルのK8s-aaSを対象として考えるのが分かりやすい。つまり、この資料の登場人物である「開発者」を利用者、「運用者」をプロバイダと読み替えることで、K8s-aaSの責任共有モデルとして表現できる。

    • CNCFレイヤーとコンテナセキュリティ
      まず、本資料で記述しているコンテナセキュリティの構成要素をCNCFレイヤーに対応付けると以下になる。

      • プロビジョニングサービスプレーン
        プロビジョニングサービスプレーンを構成しているのは、プラットフォーム管理、コンテナ管理で、運用者がこれらの機能を提供している。
      • マネージドサービスランタイム
        プロビジョニングサービスプレーンで提供されている機能を用いて、開発者がコンテナランタイムの管理を実施する。
      • アプリケーションビルドとパッケージ化、アプリケーション定義と開発
        この2つのレイヤーは、アプリケーションの設計、開発、ビルド、実行を行うもので、開発者が管理する。
    • コンテナセキュリティの内容
      ここでは、コンテナセキュリティについて、主なポイントとなる点を説明する。詳細については上記資料を参照していただきたい。

      • 開発者のアプリケーションセキュリティ
        • 開発環境全体(開発、品質保証、テスト、本番)のコードプロモーションのセキュリティ対策として、コンテナイメージに署名し信頼の起点(root of trust)を確立する。
        • 開発プロセスの一部として脆弱性スキャンを行う。
        • イメージの中には必要なコンポーネントのみを入れる。
        • アプリケーションにログ機能、フォレンジック機能を含める。
        • アプリケーションにシークレット管理機能を取り込む。
        • コンテナイメージの暗号化、保存データの暗号化を行う。
      • 運用者のアプリケーションセキュリティ
        • ビルドチェーンの完全性を確保するため、デジタル署名を使用し検証するための機能を提供する。
        • 署名され承認されたイメージだけを使用許可するための機能を組み込む。
      • 運用者のホストセキュリティ(ホストセキュリティは開発者は無し)
        • 通信の暗号化を行う。
        • コンテナを特権モードで実行しない。
        • 基本的に、コンテナランタイムにホストファイルシステムへのアクセスを許可しない。
        • 限定的なcapability設定でコンテナを起動する。ユーザが必要な機能以外を使用できないようにする。
      • 開発者のプラットフォームセキュリティ
        • コンテナで実行されるアプリケーションのバージョン管理を行う。
      • 運用者のプラットフォームセキュリティ
        • ログの送信、集中管理の基盤を提供する。
        • コンテナのライフサイクル(起動から破棄まで)のイベントを開発者に通知できるようにする。これにより、開発者は適切な対応が取れるようになる。
        • リソースの消費を監視し、最適化する。
      • 開発者のコンテナセキュリティ
        • ホストとコンテナ間の通信の機密性(暗号化)および双方向TLS等の相互認証メカニズムを使用する。
        • ネットワーク監視機能を使用する。
        • コンテナのフォレンジック機能、ログ機能を、アプリケーションにログ機能を含める。
        • データのバックアップとして、データの保存場所の特定、バックアップの定期的な実施、また、コンテナが消滅する前にバックアップされることを確認する。
      • 運用者のコンテナセキュリティ
        • ホストとコンテナ間の通信の機密性(暗号化)および双方向TLS等の相互認証メカニズムを提供する。
        • コンテナのフォレンジック機能、ログ機能を提供する。
        • コンテナのトラストチェーンの維持。OS およびコンテナイメージの完全性検証、脆弱性検査を実施する。
        • コンテナのリソース管理、ボリューム監視を行う。
        • 通信トラフィックの分離を行う。
        • シークレット管理機能を提供する。
        • データのバックアップとして、データの保存場所の特定、バックアップの定期的な実施、また、コンテナが消滅する前にバックアップされることを確認する。

以上のようなポイントを考慮してコンテナのセキュリティを考えていくことが必要である。

  1. サーバーレスセキュリティ
    サーバーレスは、CNCFモデルではCaaS, FaaS, No-Codeの各モデルが対象となる。サーバーレスのセキュリティとしてCSAが公開している資料は、「安全なサーバーレスアーキテクチャを設計するには」であり、ここではこの資料とCaaS, FaaS, No-Codeの各モデルをマップして説明する。サーバーレスセキュリティの基本的な考え方は、クラウド利用者(注:「安全なサーバーレスアーキテクチャを設計するには」では「アプリケーションオーナー」と表記)がデータの保護およびアプリケーションの保護のみの責任を持つ。一方、クラウドプロバイダ(注:「安全なサーバーレスアーキテクチャを設計するには」では「サーバーレスプラットフォームプロバイダ」と表記)がサーバーの立ち上げ、OSのパッチ適用、アップデート、シャットダウンなどのサーバーやそのセキュリティの管理の責任を持つ。これにより、アプリケーションオーナーはインフラの管理を気にせずにアプリケーションに集中することができる。「安全なサーバーレスアーキテクチャを設計するには」では、サーバーレスを2つの名称に分けて表現しており、1つは「コンテナイメージベースのサーバーレス」で、もう1つが「機能ベース(ファンクションベース)サーバーレス」である。この2つの名称をCNCFモデルに当てはめると以下のようになる。

    • コンテナイメージベースのサーバーレス: CaaS
    • 機能ベースのサーバーレス: FaaS, No-Code

機能ベースのサーバーレスにFaaS, No-Codeの2つのモデルを当てはめているが、FaaS, No-Codeの違いは「アプリケーション定義と開発」レイヤーにおける責任の一部の違いであり、サーバーレスのセキュリティを考える上では同じものとして扱うことで問題ないと考える。

これをCNCFレイヤーとサーバーレスのセキュリティを対応付けると以下になる。

  • アプリケーションビルドとパッケージ化
    コンテナイメージベースのサーバーレス(CaaS)ではアプリケーションオーナー(利用者)の責任となるが、機能ベースのサーバーレス(FaaS, No-Code)ではサーバーレスプラットフォームプロバイダ(プロバイダ)の責任となる。
  • アプリケーション定義と開発
    コンテナイメージベースのサーバーレス(CaaS)、機能ベースのサーバーレス(FaaS, No-Code)のどちらにおいても利用者の責任となる。

この責任の考え方については、「安全なサーバーレスアーキテクチャを設計するには」で表現されている以下の2つの図が分かりやすい。「コンテナイメージベースのサーバーレス(注:この図では「イメージベースのサーバーレスの責任共有モデル」と表現)」(左図)では、コンテナイメージの責任がアプリケーションオーナー、つまりクラウド利用者となっているのに対して、「機能ベースのサーバーレス(注:この図では機能ベースのサーバーレス(FaaS)の責任共有モデル」と表現)」(右図)では、このコンテナイメージの責任がサービスプロバイダとなっている。この違いは、CNCFモデルにおける「アプリケーションビルドとパッケージ化」レイヤーの責任の違いとなる。

図2 「安全なサーバーレスアーキテクチャを設計するには」より引用

なお、これらをAWS、Azure、Googleのサービスに照らし合わせると以下になる。

  • コンテナイメージベースのサーバーレス(CaaS)
    AWS Fargate、Azure Container Instances(ACI)、GoogleCloudRunなど
  • 機能ベースのサーバーレス(FaaS, No-Code)
    FaaS: AWS Lambda、Azure Functions、Google CloudFunctions
    No-Code: Azure Power Apps、Google AppSheet、AWSHoneycode

これをCNCFレイヤーとサーバーレスのセキュリティを対応付けると以下になる。

  • アプリケーションビルドとパッケージ化
    コンテナイメージベースのサーバーレス(CaaS)ではアプリケーションオーナーの責任となるが、機能ベースのサーバーレス(FaaS, No-Code)ではプロバイダの責任となる。
  • アプリケーション定義と開発
    コンテナイメージベースのサーバーレス(CaaS)、機能ベースのサーバーレス(FaaS, No-Code)のどちらにおいてもアプリケーションオーナーの責任となる。

「アプリケーションビルドとパッケージ化」におけるセキュリティは、「2. コンテナセキュリティ」で説明した内容となるのでそちらを参照していただきたい。あくまで、これがアプリケーションオーナーの責任になるかプロバイダの責任になるかの違いである。
「アプリケーション定義と開発」におけるセキュリティについて、「安全なサーバーレスアーキテクチャを設計するには」では、アプリケーションオーナー(つまり、利用者)のセキュリティとして、ワークロードへの脅威の観点で以下の3点を挙げている。

  • セットアップフェーズの脅威
    アプリケーションオーナーがワークロードを準備し、コード、イメージ、CI/CD作業、デプロイに関する脅威のことを言う。最小特権原則を維持していない呼び出し、およびセキュアでない構成管理の問題となる。
    サーバーレスにおいてはワークロードが小さな呼び出し可能なユニットに分割され、それぞれにセキュリティを管理する一連のパラメータ(ユーザの認証情報/アクセス件、呼び出し可能なユニットの認証情報/アクセス権、モニタリングなど)が設定される。これらに対して、最小権限の原則を維持することが必要である。また、この分割が増えることで、サプライチェーンの脆弱性の問題が起こる。ベースイメージの脆弱性、リポジトリに対する不正アクセス、ビルド/デプロイツールに対する攻撃などへの対応が必要である。
  • デプロイフェーズの脅威
    アプリケーションオーナーによるワークロードのデプロイフェーズでの脅威のことを言う。
    サーバーレスでは、様々なリソースからの膨大なイベントを利用する。イベントの一部として呼び出し可能なユニットに渡される情報はデータインジェクションの脅威となる。また、呼び出し可能なユニットが必要とするトークン、シークレットなどはグローバルコンテキストを必要とし、このグローバルコンテキストのリークが発生する脅威がある。
    また、サーバーレスで使用するコンピュートリソースは従量課金であるため、適切な感じと処理を行わないとリソースの枯渇等の問題が発生する。
    サーバーレスのワークロードは、データと制御パスの一部をサービスプロバイダにオフロードするため、開発とテストをクラウド上で行う必要がある。デバッグなどが制限される可能性もある。したがって、エラーメッセージが重要になる。
  • サービス事業者による脅威
    サービスプロバイダが使用するコンポーネントスタック全体および関連サービスの脅威が含まれる。
    まず重要なのがマルチテナントを維持するための隔離の問題である。サーバーレスでは、プロバイダが分離を確立する必要がある。また、インスタンスの起動/終了のオーバーヘッドを削減するために呼び出し可能なユニットの再利用を行う場合があるため、呼び出し可能なユニットの呼び出し間の漏洩および残留データの漏洩というサーバーレス固有の脅威もある。
    また、責任共有の問題として、サーバーレスではコードの設計、ランタイムのセキュリティの責任をアプリケーションオーナーが持つが、その中で機能ベースのサーバーレスの場合、プロバイダが提供する呼び出し可能なユニットの脆弱性が発生する可能性がある。コードの設計やイベントシステムのセキュリティだけでなく両者の相互作用についても考える必要がある。

以上が、アプリケーションオーナーのワークロードへの脅威の観点でのサーバーレスのセキュリティとなるが、「安全なサーバーレスアーキテクチャを設計するには」ではKubernetesのセキュリティからアプリケーションのセキュリティまでを詳細に記述している。Kubernetesのセキュリティは、「2. コンテナセキュリティ」でも記述されている部分になるが、より詳しくKubernetesの機能に基づいて記述しているので、参照していただきたい。

  1. まとめ
    以上、CNCFモデルをベースに、CSAが公開しているコンテナおよびサーバーレスのセキュリティに関する資料を参照しながら説明してきた。コンテナのセキュリティについては整理されてきているが、サーバーレスについてはまだ適切なセキュリティが明確になっていない。今後、様々な形で情報が提供されてくるので、それを見ていきながらサーバーレスとしてまとまった形でのセキュリティについて説明できるようにしていきたい。

以上

 

コンフィデンシャルコンピューティングとクラウドデータセキュリティ

CSAジャパン理事 諸角昌宏
2023/2/5

本ブログは、最近注目を集めているコンフィデンシャルコンピューティングについて、クラウドのデータセキュリティの観点から説明する。特に、クラウド環境での暗号化の基本である利用者鍵管理との関係について触れる。

  1. コンフィデンシャルコンピューティングとクラウドデータセキュリティ
    コンフィデンシャルコンピューティングの詳細については、様々な資料や情報が出ているのでそちらを参照していただくとして、ここではクラウドのデータセキュリティの観点からコンフィデンシャルコンピューティングを説明する。

    コンフィデンシャルコンピューティングを推進しているConfidential Computing Consortium(CCC)では、「ハードウェアベースの信頼できる実行環境Trusted Execution Environment(TEE)で計算を実行することで使用中のデータを保護する」と定義している。そうすると、コンフィデンシャルコンピューティングによって、利用者はデータがどのように保護されているかを気にしなくてもすむようになる。

    これを、クラウドにおけるデータセキュリティの観点で説明すると以下のようになる。
    クラウド(だけではないが)でのデータセキュリティを考える場合、以下の3つのデータの状態を考慮する必要がある。

    • 保存中のデータ(Data At Rest)
    • 移動中のデータ(Data In MotionあるいはData In Transit)
    • 使用中のデータ(Data In Use)

データを保護するためには暗号化が重要な技術となる。暗号化することで、マルチテナント環境における隔離を超えたアクセスや不正アクセスに対してデータを保護することができる(情報を保護するといった方が正しいが、ここではデータと情報を特に区別しない)。これらの3つの状態において、保存中と移動中のデータに対しては暗号化を行うことができるが、使用中のデータには暗号化を行うことができない。それは、アプリケーションが暗号化されたデータを処理することができないためで、アプリケーションが処理を行うためには暗号化されたデータは必ず復号する必要がある。クラウドにおいてはこれが特に問題となる。クラウド上のアプリケーションは仮想マシンなどの仮想環境で動作しているのがほとんどであるため、ハイパーバイザや仮想マシンを狙った攻撃により、暗号化されていない使用中のデータが狙われる可能性がある。コンフィデンシャルコンピューティングでは、この使用中のデータを保護するため、プロセッサ上の隔離された環境でプログラムを実行し、データに不正アクセスしたり書き換えたりすることができないようにしている。これにより、使用中のデータを保護することが可能になる。

このように、コンフィデンシャルコンピューティングにより、データの3つの状態のすべてにおいてデータを保護することが可能になる。すでにAWS, Azure, Google等で採用されているように、コンフィデンシャルコンピューティングを提供することはクラウドサービスプロバイダにとって重要なこととなると思われる。

  1. コンフィデンシャルコンピューティングと利用者鍵管理

    クラウドにおけるデータ保護としてもう1つ考慮する必要があるのが鍵の管理である。これは、データの暗号化に使用される鍵の管理方法の問題で、クラウドにおいては利用者が鍵を管理することが必要である。それは、プロバイダが鍵を保持した場合、クラウド側のインサイダー(管理者)による情報侵害などの問題を引き起こすからである。一方、利用者が鍵を保持した場合、アプリケーションがそのデータを処理できないという問題が発生する。特にSaaS環境においてはこの問題に直面する。そこで用いられているのが、「利用者鍵管理」という方法で、プロバイダが暗号化エンジンを管理するのに対して、利用者が自身の鍵を管理できるようにする仕組みである。BYOKやHYOKという言葉を耳にすることも多いだろう。この詳細については、以下のブログを参照していただきたい。
    https://cloudsecurityalliance.jp/newblog/2022/02/09/%e3%83%87%e3%83%bc%e3%82%bf%e3%81%ae%e6%9a%97%e5%8f%b7%e5%8c%96%e3%81%ab%e3%81%8a%e3%81%91%e3%82%8b%e5%88%a9%e7%94%a8%e8%80%85%e9%8d%b5%e7%ae%a1%e7%90%86%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6/

    利用者鍵管理では、一時的にせよプロバイダが鍵を保持することになる(一時的というのは、実装の仕方は様々なのでこの言い方を取る)。また、その鍵を使用して復号し、アプリケーションが処理を行うことになる。したがって、使用中のデータに対する保護はできない。
    一方、コンフィデンシャルコンピューティングでは、使用中のデータの保護はできるが、アプリケーションが処理した後のデータの保存時の暗号化を行うことはできない、というか、暗号化はプロバイダが管理する鍵を用いて行うしかない。そうすると、コンフィデンシャルコンピューティングを利用したとしても、引き続き利用者鍵管理は必要となると考えられる。

  2. まとめ

    使用中のデータの保護と保存時のデータの暗号化を両立させる方法としては、完全準同型暗号が解となる。完全準同型暗号については、先のブログに記載しているのでそちらを参照していただきたい。しかしながら、完全準同型暗号が一般的に利用されるようになるまでにはまだ時間がかかりそうである。
    コンフィデンシャルコンピューティングは、使用中のデータの保護として非常に重要な技術であり、引き続き理解を深めていく必要がある。また、利用者鍵管理も引き続き必要となるし、特に、ISMAP等の要求事項となっているので、こちらの理解も深めていく必要がある。

以上

 

データの暗号化における利用者鍵管理について

データの暗号化における利用者鍵管理について

2022年2月9日
データセキュリティ WGメンバー: 諸角昌宏

本ブログでは、クラウド利用において必要となる利用者鍵管理について解説する。

  1. 利用者鍵管理の必要性について

    クラウドでは共有責任モデルとしてユーザーがデータセキュリティの責任を持ちます。そのデータを保護する技術として「暗号化」が有効な技術であることが各法規制やガイドライン等で言及されており、多くの情報システムにおいて暗号技術は活用されています。
    また暗号化技術を利用する場合には「暗号鍵」もユーザーの責任で保護する必要があり、ユーザー自身の責任で鍵管理技術を理解して実装方法を選択して運用する必要があります。」(引用: Cloud Data Protection, https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2021/08/Cloud_Data_Protection2_V10.pdf

    また、クラウドコンピューティングのためのセキュリティガイダンス V4.0(https://cloudsecurityalliance.jp/j-docs/CSA_Guidance_V4.0_J_V1.2_clear_20200806.pdf)では、利用者が管理できる鍵(Customer-Managed Keys)」という手法の説明として、「利用者が管理できる鍵は、クラウド事業者が暗号化エンジンを管理するのに対して、クラウド利用者が自身の暗号鍵を管理できるようにする。例えば、SaaSプラットフォームの中でSaaSデータを暗号化するのに利用者自身の鍵を使う。クラウド事業者の多くは、デフォルトでデータを暗号化するが、事業者自らの完全な管理下にある鍵を使う。一部の事業者では、利用者が自分の鍵に差し替えて事業者の暗号化システムに組み入れることを許している。利用する事業者のやり方が利用者自身の要求条件と合致するか確認する必要がある。」と記載している。

    クラウドにデータを暗号化して保存する場合において、プロバイダーが鍵を管理すると以下のような問題が発生する可能性がある:

    • クラウド側のインサイダー(管理者)による情報侵害が発生する可能性がある
    • クラウド上に暗号化データと暗号化鍵の両方が存在するため、クラウド環境が侵害された場合(例えば、利用者間の論理境界が破られるなど)に情報漏洩につながる可能性がある
    • 召喚状等によりプロバイダーが利用者データの開示を求められた場合、クラウド上に暗号化して保存していたデータであっても、プロバイダーが復号して提供することが可能になる

半面、利用者がデータを暗号化し暗号鍵を保持する場合、アプリケーション(クラウドサービス)がそのデータを処理できないという問題が発生する。IaaSにおいては、利用者がアプリケーションとデータの両方を管理できるため、利用者が暗号化鍵を管理することが可能だが、SaaS環境においてはこの問題に直面する。

そこで考えられたのが「利用者による鍵管理(以下、利用者鍵管理と呼ぶ)」という方法で、プロバイダーが暗号化エンジンを管理するのに対して、利用者が自身の暗号鍵を管理できるようにする仕組みである。本ブログでは、この利用者鍵管理についての規制等の要求事項、利用者鍵管理の手法、動作の例などについて説明していく。

  1. 利用者鍵管理に関係する規制・要求事項

    以下に、代表的な規格における利用者鍵管理の要求事項を記載する。

    • ISO/IEC 27017
      • 10.1.2:  クラウドサービスカスタマは,自らの鍵管理を採用する場合又はクラウドサービスプロバイダの鍵管理サービスとは別のサービスを利用する場合,暗号の運用のための暗号鍵をクラウドサービスプロバイダが保存し,管理することを許可しないことが望ましい。
    • CSA CCM V4
      • CEK-08: CSPはCSCがデータ暗号鍵を管理できる機能を適用しなければならない。
    • ISMAP
      • 10.1.1.9.PB: クラウドサービス事業者は、クラウドサービス利用者に、当該利用者の管理する情報の暗号化に用いる暗号鍵を当該利用者が管理し消去する機能を提供し、または、当該利用者が暗号鍵を管理し消去する機能を実装するために必要となる情報を提供する。
  1. 利用者鍵管理(BYOK、HYOK)とは?

    利用者鍵管理の構成として、前述の「Cloud Data Protection」では以下のように2つのタイプ(BYOK、HYOK)が記述されている。

    • BYOK(Bring Your Own Key)

      • ユーザー自身が暗号鍵を作成してクラウドサービスに持ち込むシステム構成
      • 持ち込んだ後の暗号鍵はクラウドサービス事業者内で管理
      • APIが公開されることが多く、オンプレミスのHSM等で作成した鍵をアプリケーションを開発することで持ち込むことが可能
    • HYOK(Hold Your Own Key)

      • クラウド事業者のサービスがユーザーの鍵管理システムを利用
      • ユーザーの暗号鍵はクラウドサービス事業者外部で管理

ここで、BYOKとHYOKの違いを明確にすると以下のようになる:

  • BYOKは、ユーザー自身が暗号鍵の作成・管理を行うが、プロバイダー側(つまり、クラウドのアプリケーション)が復号を行うにあたって、利用者から鍵を受け取る。受け取った鍵は、プロバイダー側で管理することになる。したがって、一度プロバイダーに渡された鍵を利用者が管理することはできない。
  • HYOKでは、利用者はプロバイダーの鍵管理システムを利用するが、暗号鍵の管理は利用者自らが行い、利用者の管理のもとプロバイダーは暗号鍵を扱うことができるようになる。したがって、利用者が常に鍵を管理することが可能になる。なお、このHYOKを提供する方法は、Microsoft Azureの2重キー暗号化 (Double Key Encryption) 、 Google Cloud External Key Manager、Salesforceキャッシュのみの鍵サービス(Cache-Only Key)などがあり、主なプロバイダーが提供している。

このBYOKとHYOKを明確にすることが重要であり、ここが利用者鍵管理として混同されている点である。特に、BYOKがバズワードとなっていて、利用者鍵管理=BYOK と扱われてしまっていることが問題となる。先に述べた様々な規格の要求事項は、HYOKが必要となることでありBYOKでは不十分であるということを理解する必要がある。

  1. 利用者鍵管理(HYOK)の動作例

    ここでは、HYOKの動作の1つの例を以下の図を使って説明する。

    まず、この図に表示されているそれぞれの鍵について説明する:

    • DEK(Data Encryption Key): データ暗号化鍵。データを暗号化および復号に使用
    • 暗号化DEK(Encrypted DEK) :DEKを暗号化したもの
    • KEK(Key Encryption Key):DEKの暗号化に使用される鍵
    • マスターキー:KEKの暗号化に使用される鍵

利用者から送られたデータを暗号化してストレージに保存する手順は以下になる:
(1) アプリケーションに利用者からデータが送られる
(2) アプリケーションは、KMSに対して、データ暗号化用の鍵(DEK)を要求する
(3) KMSは、DEKを作成し、KEKを使って暗号化DEKを作成し、DEKと暗号化DEKの両方をアプリケーションに送る
(4) アプリケーションは、DEKを用いてデータを暗号化し、暗号化されたデータと暗号化DEKをストレージに送る
(5) アプリケーションはDEKを削除する

次に、データを復号する手順は以下になる:
(1) アプリケーションは、ストレージから暗号化されたデータと暗号化DEKを入手する
(2) アプリケーションは、暗号化DEKをKMSに送る
(3) KMSは、KEMを用いてDEKを作成し、アプリケーションに送る
(4) アプリケーションは、DEKを使ってデータを復号する
(5) アプリケーションはDEKを削除する

以上の流れにおいて、プロバイダーがDEKを保有するのは、暗号化および復号の作業を行うときのみになる。また、一連の流れとして、利用者が鍵の管理を行うことができる。

  1. 利用者鍵管理に向けての考慮事項

    • BYOK  利用者鍵管理 について

      以上、説明してきたように、クラウド環境で必要とする利用者鍵管理はHYOKであり、BYOKでは不十分である。しかしながら、BYOKを利用者鍵管理として説明している資料も多数あるのも事実である。ここは悩ましいところであり、現状でこれを明確にしていくことはかなり難しいかもしれない。もちろん、BYOK、HYOKを正確に伝えることは重要であるが、ある程度BYOKとHYOKを区別せずに、HYOKとして必要な要求事項をベースにしてBYOKを説明することもやむを得ないと思われる。
      また、BYOKとHYOKを厳密に区別することが、逆に、利用者鍵管理は不要であるという印象を与えてしまっているケースもある。CSAが公開している「クラウドサービスの鍵管理(原書:Key Management in Cloud Services)」では、まとめとして、「いわゆるBYOK(Bring Your Own Key)や同様のモデルをクラウドサービスで使用したBYOKの意味は、通常期待される結果が得られないことを示しています。これらのいわゆるBYOKモデルを使用しようとしているほとんどの組織は、クラウドサービスプロバイダが利用者のデータを裁判所や法執行機関などの第三者に引き渡すことを強制できないことを期待しています。ただし、いわゆるBYOKモデルのほとんどのベンダーにおける実装では、クラウドサービスがデータ暗号化鍵を使用しているため、必要に応じてエクスポート用に暗号化されていないデータを生成できるので、実際にはその結果を防げません。」と記述している。これは、BYOKとHYOKを明確に区別した上でBYOKでは不十分であることを指摘しているのであるが、HYOKを含めた利用者鍵管理すべてが不十分であると理解されてしまっているところがある。この辺りは、CSAとしても明確に記述する必要があったと思われる。
      また、ISMAPのFAQ(https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010098&sys_kb_id=cfb60af91baebc1013a78665cc4bcb12&spa=1)において、「暗号鍵の管理に関するクラウドサービス事業者内部からの不正アクセス対策を別の手段で実現すること。①1.2(権限分離)、②7.2.1(従業員・契約相手へのセキュリティ)及び③9.2.3(特権的アクセス権の制限)を適切に実施…」という代替策を記述している。しかしながら、この代替案では、先に挙げたプロバイダーが鍵を管理する場合の問題点に対する対策にはならない可能性が高く、あくまでリスク管理上可能であれば取れる代替案であることを理解しておく必要がある。

    • SaaSにおける利用者鍵管理の実装について

      SaaSプロバイダーが利用者鍵管理を提供する場合、以下の2つのケースが考えられる:

      • SaaSプロバイダーが、第三者ベンダーが提供している利用者鍵管理機能を実装する。
      • SaaSプロバイダーが、インフラとして利用しているIaaS/PaaSプロバイダーが提供している利用者鍵管理を用いて実装する。

なお、SaaSプロバイダーが利用者鍵管理を評価・実装するには、ユースケースを含めた詳しい情報が必要であると思われる。利用者鍵管理を提供しているベンダーおよびIaaS/SaaSプロバイダーは、利用者鍵管理に関する情報を積極的に発信していただきたい。本ブログにおいても、今後、できるだけ情報発信できるようにしていきたい。

6. 暗号化の代替手段

これまで、利用者鍵管理について記述してきたが、利用者鍵管理が必要となるそもそもの暗号化について、その代替手段として以下の2つが考えられる。

  • トークン化

    トークン化はクレジットカードの保護等で実績がある仕組みであり、従来からの暗号化技術と同様検討に値する技術である。
    暗号化の問題は、アプリケーションが暗号化されたデータを処理できないという点である。利用者鍵管理の問題以前に、クラウド上のアプリケーションは、何らかの形で復号しないと処理できないという根本的な問題を抱えており、クラウドのマルチテナントを維持しなければならない環境において問題となる。トークン化されたデータは、元のデータと同じサイズ/形式で保管されるため、トークン化されたデータを保管するためにデータベースのスキーマやプロセスを変更する必要はない。データのトークン化により、クラウドやビッグデータ、外部委託環境に移行する際も、制御機能やコンプライアンスを維持することが可能である。ここでは、トークン化について詳しく述べないが、1つの代替手段と考えられる。

  • 完全準同型暗号

    アプリケーションが、暗号化データを復号せずに処理できる方法として、(完全)準同型暗号が考えられる。まだ、あまり一般に商用化されていないが、今後、幅広く利用されてくる可能性もある。今後の展開に注目したい。

以上、クラウド上のデータの暗号化として必要となる利用者鍵管理について記述した。これから先、新たな情報が得られれば、また、情報発信していきたい。

以上

Log4Shellとゼロトラスト

本ブログは、CSA本部のブログを著者の許可を得て翻訳したものです。本ブログの内容とCSA本部のブログとに相違があった場合には、CSA本部のブログの内容が優先されます。

Log4Shellとゼロトラスト

このブログは、Appgateのこちらの記事を元にしています。
著者:Jason Garbis、Appgate

Log4Shellの脆弱性が発覚してからわずか数週間しか経っていませんが(関連する問題はまだいくつか残っています)、世界中のセキュリティチームは、診断、検証、更新、コミュニケーションのために奔走しています。一歩下がって振り返るにはまだ少し早いかもしれませんが、私はいくつかの考えをコミュニティと共有したいと思います。

Log4Shellは、悪用が容易であるだけでなく、一般的に攻撃対象がすべてのユーザーに利用可能であり、非常に陰湿な脆弱性です。多くの場合、そのユーザーは認証前の状態です。場合によっては、悪意ある者がウェブサイトのログインページから直接攻撃を仕掛けて成功させることも可能です。さらに、このエクスプロイトは、通常、信頼されたゾーンの企業ネットワーク上で動作するロギングサーバー自身によって実行されます。ロギングサーバーは、インターネット上の悪意のあるサイトにアウトバウンドのリクエストを行い、悪意のあるコードを取得し、ローカルで実行します。

この種の脆弱性に対しては、ゼロトラストセキュリティとその中心的な考え方である最小権限の原則を実施することの重要性を示しています。それは、不必要にインターネットにさらされているアプリケーションがあまりにも多いからです。ZTNA(Zero Trust Network Access)技術を使用すると、ユーザーがアクセスを許可され認証されない限り、すべてのリソースを見えなくし、攻撃対象を減らすことができます。

Log4Shellは、認証のみのセキュリティではあまりにも弱すぎることを示す好例で、悪意のあるアクターにログイン画面を見せるだけでも悪用されてしまいます。ゼロトラストの最小権限の原則は、プライベートなアプリケーションがネットワーク上に隠れていることを保証し、悪用される可能性を最小限にします。

もちろん、会社のWebサイトのように、公開しなければならないアプリケーションやWebサイトもあります。しかし、企業はセキュリティの考え方を変えることで、顧客専用のWebアプリケーションに対しては、実際の顧客にしかアクセスできないようにすることを検討すべきです。

例えば、ビジネス向けの出荷・物流サービスを提供している企業であれば、顧客のログインページをあらゆる攻撃者に公開する理由はありません。ゼロトラスト方式を採用すれば、正当なお客様だけがログインを試みることができ、攻撃者がログインサイトを悪用することを防ぐことができます。このような安全性の高いアクセス方法をお客様に要求することは、合理的であるだけでなく、お客様に対するビジネスのセールスポイントにもなり得ます。

一般に公開する必要のあるサーバーやサイトについては、組織はゼロトラストの原則である最小権限モデルを適用しなければなりません。これらのサーバーは、広い範囲の社内ネットワークにアクセスできないようにする必要があります。すべてのアクセスはデフォルトでは拒否され、定義されたポリシーに基づいて明示的に許可されたアクセスのみが許可されなければなりません。このモデルは、インターネットへのアウトバウンドアクセスにも適用する必要があります。

企業は、ネットワーク上で稼働しているリソースだけでなく、それらのリソースが何にアクセスすることを許可されているのかを明確に把握し、明確に定義されたゼロトラストポリシーによってアクセスを許可する必要があります。これは、内部のサーバー間のアクセスについても、正当かつ合理的な要件です。セキュリティチームは、必要なアクセスを許可するためのポリシーを文書化し設定する責任をITチームやアプリケーションチームに負わせなければなりません。また、セキュリティチームは、それ以外のすべてのアクセスを制限する責任も負わなければなりません。

管理者からサーバーへのアクセス(アップデートや設定変更など)には、ITサービスマネジメント(ITSM)のビジネスプロセスに基づいてアクセスを制御するゼロトラストシステムを用いて、定義されたメンテナンスウィンドウを使用すべきです。さらに進んだ組織では、サーバーをペットではなく家畜のように扱うDevOpsのアプローチを検討する必要があります。つまり、サーバーのアップグレードやメンテナンスは行わず、マスターイメージを更新して新しいサーバーをデプロイすることになります。

サーバーからインターネットへのアクセスの場合、ほとんどのサーバーは任意のインターネットサイトにアクセスする正当な必要性はなく、むしろアクセスを許可することはセキュリティ上の弱点となります。組織は、このようなアクセスをブロックするか、許可された厳格なサイトに制限する必要があります。DNSやNTPなどのコアネットワークやインフラサービスは、企業が管理する内部システムに限定する必要があります。

Log4Shellはまた、ソフトウェアサプライチェーンのセキュリティと完全性に関するもっともな疑問を提起していますが、これについては別のブログ記事で取り上げます。ソフトウェアをどの程度信頼しているかにかかわらず、「侵害を想定する」というゼロトラストの原則に基づいて運用する必要があります。オープンソース、ベンダーから提供されたソフトウェア、または独自に作成したソフトウェアが危険にさらされていると想定する場合、最低限、ソフトウェアのインバウンドとアウトバウンドを制限し、すべてのアクセスがポリシーによって明示的に制御されていることを確認し、実際の動作を記録して監視する必要があります。

今日のリモートワークの世界における複雑な脅威の状況、脆弱性が発生する頻度、ハイブリッド環境の複雑さ、デバイスの急増を考慮すると、多くの企業や政府機関は、ゼロトラストへの移行に急速に乗り出しています。ZTNAソリューションは、以下の方法で移行をスムーズに行うことができます:

  • 例えば、SPA(Single Packet Authorization)を使用して、ポートを積極的に隠蔽し、インターネットに接続されたサーバーを権限のないユーザーから見えないようにします。
  • デバイスとユーザーのリスクへの対応:きめ細かなZTNAポリシーは、限られたリスクに基づいてユーザーデバイスに適切な権限を調整し付与することができます。
  • サーバーやユーザーデバイスとの間のトラフィックを制御します。多くのZTNAソリューションは、「アップルール」(例えば、ユーザーのモバイルデバイスがデータベースにアクセスする必要がある場合など)として知られる、リソースのやり取りに対するユーザー/デバイスのポリシーを必要とするユースケースでうまく機能します。しかし、「ダウンルール」、つまりサーバー、サービス、リソースから「下方向」のユーザーデバイスとのやりとりを扱うこともサポートされるべきです(例:リモートデスクトップのサポートやエンドポイントプロテクションの集中管理プラットフォーム)。この両方をサポートするZTNAプラットフォームを見てください。
  •  幅広いITおよびセキュリティエコシステムの統合をサポートします。ZTNAは、脅威インテリジェンスツール、SIEM(Security Incident and Event Management)ソリューション、EDR(Endpoint Detection and Response)プラットフォーム、ITSMソリューションなどと統合する必要があります。
  • エンタープライズスケールとスピードでの運用。多くの組織は単一のユースケースからスタートしますが、最終的には、ZTNAソリューションは、組織全体のアクセスコントロールの全負荷に対応できなければならず、また、ネットワークやクラウドエコシステム全体のすべてのアプリケーションを含む、拡大するフットプリント内の負荷レベルの増加にも対応できなければなりません。

この数週間は、情報セキュリティに携わる多くの人々にとって困難な時期でした。あなたが実務者であれば、その献身的な努力に感謝します。もしあなたが組織のビジネスサイドにいるのであれば、企業を守るために夜も週末も働いているセキュリティチームやネットワークチームに、どうか辛抱強く対応していただきたいと思います。

Log4Shellは、これまでに見たことのない最悪の脆弱性であり、セキュリティに対するゼロトラストアプローチの必要性とその価値を明確に示しています。この事件をきっかけにして、ゼロトラストへの移行を始めたり、加速させたりしてください。無駄にする時間はありません。ゼロトラストの原則とアプローチは、明らかに優れたセキュリティを提供することが証明されており、あなたには組織をより良い場所へと導く責任があります。今こそ、始める時です。

日本語での評価レポートの公開方法およびLevel1セルフアセスメントの重要性について

本ブログでは、STAR Level1セルフアセスメントの重要性および日本語での評価レポートの公開方法について記述します。

2021年10月20日
CCM/STAR WGメンバー 諸角昌宏

クラウドサービスプロバイダが、提供するクラウドサービスのセキュリティ情報を公開することは非常に重要です。クラウドセキュリティにおける責任共有モデルにおいては、クラウドサービス利用者は、自身が管理するセキュリティとプロバイダが管理するセキュリティの両方を把握し説明責任を果たすことが必要で、そのためには、利用するクラウドサービスのセキュリティレベルを把握する必要があります。これは、利用者がプロバイダに直接確認することで行えますが、たくさんの利用者を抱えているプロバイダが、利用者ごとの問い合わせに対応することは非効率です。そこで、プロバイダが、提供しているクラウドサービスのセキュリティ情報をあらかじめ公開することで、利用者は公開された情報に基づいてクラウドサービスのセキュリティレベルを把握することができます。また、プロバイダは、利用者からの個別の問い合わせに対応する作業を削減することができますし、セキュリティ情報を積極的に公開することにより、セキュリティをビジネス上の差別化要因とすることができます。

STAR Level1セルフアセスメントは、CSAが提供しているCAIQ(Consensus Assessment Initiative Questionnaire)に、プロバイダが自己評価した結果を記述し、それを公開するウエブサイト(CSA STAR Registry: https://cloudsecurityalliance.org/star/registry/)を提供しています。このCSA STAR Registryには、STAR認証が提供する3つのレベルの情報が公開されていますが、CAIQの評価レポートは、STAR Level1 セルフアセスメントとして公開されています。STAR Level1 セルフアセスメントのようなセキュリティの透明性に対する取り組みは、特に欧米のプロバイダは積極的に行っています。CSA STAR Registryには、1000以上のクラウドサービスが登録されていますが、その大部分がSTAR Level1セルフアセスメントとしてCAIQ評価レポートを公開しています。

CSAジャパンでは、日本のプロバイダが積極的にセキュリティ情報を公開できるように支援していきます。以下の2つのアプローチになります。

  1. 日本語CAIQ評価レポートの登録手順を日本語で提供
    STAR Level1 セルフアセスメントの登録手続きは、英語で行う必要があります。会社名やクラウドサービス名、およびそれらの概要等は、英語で記述する必要があります。CSAジャパンでは、日本語CAIQ評価レポートの作成から、STAR Level1 セルフアセスメントの登録までの一連の手順を日本語で記述しました。以下のウエブサイトを参照してください。
    https://www.cloudsecurityalliance.jp/site/?page_id=1005
  2. 日本語 CAIQ評価レポートを公開されているプロバイダとクラウドサービスの情報を公開
    CSA STAR Registryには、すべてのクラウドサービスの情報がアルファベット順にリストされています。この中から、日本語CAIQ評価レポートを公開しているプロバイダ及びクラウドサービスを探すことは難しいです。そこで、CSAジャパンでは、CSAジャパンのウエブサイトから、日本語 CAIQ評価レポートを公開されているプロバイダとクラウドサービスの情報を公開することとしました。以下のウエブサイトになります。
    https://www.cloudsecurityalliance.jp/site/?page_id=19811
    なお、日本語 CAIQ評価レポートを公開されているプロバイダ及びクラウドサービスをすべて把握することが難しく、このサイトの情報はCSAジャパンが把握できているもののみになります。日本語 CAIQ評価レポートを公開されていて、このサイトにリストされていないものがありましたら、以下のメールアドレスまでご連絡ください(注意: @の前後のクオーテーションを削除してください)。 info’@’cloudsecurityalliance.jp

以上