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

継続的な保証とコンプライアンス自動化はなぜ必要なのか

2025年2月11日
情報セキュリティ大学院大学
CSAジャパン クラウドセキュリティ自動化WGメンバー
対馬 亜矢子

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

継続的な保証とコンプライアンス自動化はなぜ必要なのか

2024年10月15日
Daniele Catteddu, Chief Technology Officer, CSA

私たちの業界では「信頼」について多くのことが語られますが、信頼は実際には目的を達成するための手段にすぎません。組織にとっての「目的」は、組織のミッションを達成することです。組織のミッションを達成するためには、組織内外の関係者との健全な交流が必要です。したがって、この文脈における信頼とは、あらゆる取引や関係が安全を持つのに値するものであるという信頼性を確立し、信用を築くことを意味します
信頼性と信用は、誰か/何かをどれだけ信頼できるかを測る尺度である保証につながります。これにより私たちは、ある主張が述べられたとおりに展開するだろうという一定の保証を感じるのです。

信頼、保証、ガバナンス、リスク

保証が信頼の代用品であるとすると、次に保証をどのように定義し、測定するかが問題となります。ある事象がその通りに進む確率を、私たちはどのように定義し、定量化/定性化するのでしょうか。
そこで、ガバナンスとリスクマネジメントの出番となります。ガバナンスとリスクマネジメントは、原則、ポリシー、手順、管理策を定め、下記に対する組織体制を確実にします。

  • ミッション目標の達成
  • リスクの許容範囲内への抑制
  • 不確実で変化する環境における、法律、規制、標準、ポリシー遵守の継続

組織におけるガバナンスとリスクマネジメントの枠組みは、ポリシーと管理策を設計し、実装し、施行し、モニターするために使用される仕組みであるはずです。また、データを収集し、分類し、分析し、評価し、それに基づいて行動することで、変化する環境の中で長期にわたり正しい方向性が設定され維持されることを確実にするものでもあります。
そこで質問に戻りましょう:私たちは保証をどのように定義しますか?そして、それをどのように測定しますか?保証は信頼を構成する要素であり、その伝達手段です。誰かあるいは何かが提供できる保証が多ければ多いほど、その相手はより信頼できるということになります。サイバー空間における保証は、データ主導で、エビデンスに基づき、ゼロトラスト原則に従うべきです。サイバー空間における保証とは、組織が運営上のリスクを管理しながら、ガバナンスをいかに適切に識別し、設計し、構築し、実装し、監視し、変更し、改善しているかを、評価・測定・伝達・報告した結果なのです

サイバー空間における保証の測定

サイバー空間における保証の測定とは、ある前提条件において、適切なガバナンスのアクションがどの程度機能しているかを定性化/定量化することです。前述したように、ガバナンスの主要なツール/アクションはポリシーと管理策です。ポリシーとは、組織の運営を導くルールです。管理策とは、内外の世界との相互作用において、周囲の状況が期待されたとおりにふるまうことを確実にするために導入される尺度です。
これを信頼に戻すと、私たちは組織、サービスなどの信頼度を示すために「サイバー空間における保証」を使い、そのレベルを測るために「ポリシーと管理策のパフォーマンス」を使うわけです。

管理策のパフォーマンス

管理策のパフォーマンスとは、ある管理策が適用され運用される状況において、その管理策がどのように機能しているかを示すものです。個々の管理策の実績は、システム(ドメイン)およびサブシステムに集約され、統制システム全体のパフォーマンスを示します。統制システムとは、ガバナンスとリスクマネジメント戦略の実施結果です。
「良好な管理策」と「良好なパフォーマンス」を判断するためのパラメータは、リスクプロファイルに応じたユーザーの主観に基づきます。これらのパラメータは、標準、ベストプラクティス、ベンチマーク、法的・規制的要件によっても左右されます。
良し悪しのパラメータが何であろうと、下記を確実にするため、管理策のパフォーマンスはモニターされる必要があります

  • モニタリングしているものは、目的やスコープに関連がある
  • ロギングおよびモニタリング中に生成されたデータは、信頼でき、正確で、完全で、機密性がある
  • パフォーマンスは、目標パラメータ(通常、ポリシー、メトリクス、ベンチマークとして表される)の範囲内にある

どの管理策が必要か?

各組織が必要十分な保証を得るために導入すべき統制システムは、多くの要因によって異なります。これらの要因には、事業ニーズ、リスクプロファイル、対象市場、対象ユーザー、法規制要件などが含まれます。
規制、標準、ベストプラクティスは管理策の主要な情報源であり、特定の管理策に関する統合され標準化された定義を提供します。例えば、CSA Cloud Controls Matrix はクラウドセキュリティのための標準化された管理策フレームワークです。
一般には、適用する管理策の数が多ければ多いほど、また適用可能な範囲内で管理策が厳格であればあるほど、組織/サービス/取引/相互作用はより多くの保証を提供(すると主張)し、信頼できることに(潜在的に)なります。言い換えれば、統制範囲(誰かが適用する管理策の数)が高ければ高いほど、提供(主張)される保証のレベルも高くなります
例えばクラウドサービスではCCM v4 Lite、CCM v4、CCM v4 plus addendaのいずれかを、管理システムの基盤として使用することができます。CCM v4 plus addendaは管理策の数が最も多く、要求事項のカバー率も高くなります。したがってCCM v4 plus addendaは、より高いレベルの保証を提供します。

管理策をどう評価するか:統制のモニタリングと監査

管理策が望ましい効果をもたらしているかを判断するためには、証拠データを収集し、監視し、分析し、評価し、テストし、監査する必要があります。これは通常、モニタリング、評価、監査機能を通じて行われます。
統制のモニタリングは、組織がガバナンスとリスクマネジメント戦略の結果として導入することを決定した相互作用・取引・管理策を、可視化できるようにします。
統制の監査は、モニタリング中に収集されたデータ/情報が適切で、信頼でき、タイムリーで、完全で、正確であることと、パフォーマンスが期待される目標の範囲内であることを確認します。
理想的には、統制のモニタリングと監査は継続的であるべきです。そこでは、適用される管理策の文脈に適した定期的な頻度で測定が行われます。
統制のモニタリングと監査の目的は、内部統制の有効性を監督、評価、報告することです。また、その目的は、内部統制の信頼性と、確立された標準、フレームワーク、または適用される法規制への準拠を保証することにあります。
モニタリングと監査の精巧さ、頻度、厳格さ、正確さ、完全性が高ければ高いほど、提供される保証のレベルも高くなります。自己評価/監査、第三者監査、継続的監査は、統制評価の高度さ、頻度、厳格さ、正確さ、完全性の異なるレベルの一例です。

コンプライアンスと保証の関係

コンプライアンスの概念は、保証の概念に直接関連しています。コンプライアンスとは、内部ポリシー、適用される法律や規制、業界固有の行動規範、標準、ベストプラクティスから派生する要件を遵守することです。
適用される要件に従うことで、組織は以下のことが可能になります。

  • 社内の方針や倫理規定を満たす
  • 市場で安全に営業する
  • 競争上の優位性を得る

組織が適用される法規制を遵守しない場合、以下の対象になりえます。

  • 罰金
  • 罰則
  • 評判の失墜
  • 特定市場における事業の損失(欧州AI法その他多くの法律を参照)

私たちが管理策を用いるのは、ガバナンスポリシーが正しく実施され、事業環境のルール(法律、規制、行動規範、標準)が満たされていることを確認するためです

保証とコンプライアンスの課題

今日の規制に関する風景は、指数関数的に拡大しています。地域化、プライバシー重視、業界毎の縦割り(金融サービス、ヘルスケア、公共部門などを含む)が進み、フレームワークが増え続けています。このような法規制の要求の増大は、規制される側にとって大きな負担となっています。
コンプライアンス・フレームワークと、それを支える規制当局や第三者監査人の監査・評価活動は、大部分が手作業で行われ、人為的な判断ミスが発生しやすく、標準化が進んでいないために自動化が困難です。最近の調査によると、規制関連コストは企業の賃金総額の平均1.34%を占めています。
このような法律や規制の急増に伴い、組織にとって以下はますます困難になっています。

  • 原則ベースの法律や要件を、コンプライアンス要件を満たす定義された管理策に変換する
  • 膨大な要件を統合して、スケーラブルかつアジャイルで管理可能なガバナンスとリスクの枠組みを定義する
  • 複数の関係者が関与する複雑なサプライチェーンのコンプライアンスと保証を維持する
  • 保証とコンプライアンスの主張を裏付ける良い証拠とは何かを確立する
  • 保証とコンプライアンスのコストを許容範囲内に維持する
  • コンプライアンスや信頼の欠如のリスクを許容可能なレベルに維持する
  • 提供/要求されるサービスの重要度に見合った保証レベルを提供する

継続的な保証とコンプライアンス自動化で課題に対処する

規制対象となる事業者がグローバルな規制を効率的かつ正確に遵守しつながら事業を拡大していくためには、コンプライアンス活動の自動化を可能にするオープンな標準とツールが必要です。また、提供される保証のレベルは提供されるサービスの重要性に比例するべきであるという考えに基づくと、より成熟した保証へのアプローチを可能にする標準とツールが必要とされています。これは、顧客のリスク選好度と一致したものであるべきです。
保証に対する業界のアプローチの近代化に必要な要素は以下の通りです。

  • 共通の管理策言語:内部および外部の要件を満たすことができる、共通かつ標準化された言語で表現された管理策のカタログ
  • フレームワーク間のマッピング:異なるフレームワークの管理策間の関係と、それらがどのように要件を満たすかをマッピングし、理解するための体系
  • 機械可読形式の管理策:自動化を可能にするための、機械可読言語で表現された管理策
  • メトリックス:管理策の設計と実装の有効性や効率が、標準化されたメトリックス(測定基準)に基づき測定され、標準化された手法で記述されること

業界のコンプライアンスへのアプローチを近代化するために必要な要素は、以下の通りです(この後で詳しく説明します)。

  • 規制の枠組みの解釈 (Interpret)
  • これら枠組みの準拠の測定 (Measure)
  •  標準化された評価・監査活動 (Access)

解釈する (Interpret)

機械学習と業界標準の管理策カタログ(例:CSA CCMやNIST 800-53)の活用により、グローバルな規制を自動化された方法で分析し、機械可読化することができます。先行事例として、NIST 800-53 と FedRAMP 管理策カタログには機械可読フォーマットが存在します。これらの機械可読フォーマットは、規制要件の分析と解釈に要する時間をかなり削減します。
規制対象事業者は、これらの機械可読形式を既存のGRC管理システムに取り込み、自社の管理策カタログにマッピングしたり、新たな規制への適合状況を確認したりすることができます。
これを実行するために必要なツールは、様々な組織内に何らかの形で存在しており、急速に進化することが期待されています。この種のツールがより広範なコミュニティに開放されることで、規制やフレームワークの機械可読フォーマットを一元的なリポジトリで利用できるようになるでしょう。

測定する (Measure)

諸規制が明確に解釈され、業界標準の管理策マッピングに当てはめられると、管理策の有効性を判断するための測定基準を開発することができるようになります。CSAやEUのMedinaプロジェクトが作成した既存のメトリックス・カタログは、この取り組みのベースとして役立つでしょう。
より多くの規制が分析され、機械可読形式に変換されるにつれて、私たちは管理策のカタログを拡張し、新しい管理策をサポートするメトリックスを開発することができるようになります。

評価する (Assess)

フレームワーク全体を、オープンかつ拡張可能で、機械可読可能なデータフォーマットに合わせることで、規制当局や認証機関と規制対象事業者の間で、上記データを自由に交換できるようになります。
NISTの OSCALフレームワークは、前途有望な方法を提供します。メトリックスを定義し、OSCAL形式による評価パッケージのプロトタイプを作成するために、業界で著しい努力が払われています。この作業は、他の重要な規制やフレームワークに対応できるよう拡張されるでしょう。

継続的な保証とコンプライアンス自動化に向けた主要課題

継続的な保証とコンプライアンス自動化のビジネスケースは、リスクの定量化とマネジメントを中心に展開されます。(アセットとアイデンティティの把握、リスクの特定、管理策の実施、モニタリング、監査などの)保証とコンプライアンスのアプローチが十分に体系化されているなら、組織はリスク定量化のための適切なデータを収集することができます。
サイバーリスクは、組織の総リスクのかなりの比重を占めます。継続的な保証とコンプライアンス自動化により、リスクの測定と定量化が正確に行えるようになり、組織のミッションとビジョンに直接的・間接的な影響を与えるでしょう。
ガバナンスの観点では、リスクの正確な定量化は組織に以下をもたらします。

  • リソースを効果的かつ効率的に配分する
  • リスクマネジメントのアプローチと文化を成熟させる
  • ポリシーを効果的かつ効率的に策定し、実施する
  • 説明責任の戦略と体制を成熟させる
  • ベースライン、社内標準、プロセス、手順を成熟させる
  • 統制のフレームワークを成熟させる
  • イノベーションを効果的かつ効率的に管理する
  • コンプライアンスを効果的かつ効率的に管理する

事業運営の観点では、リスクの正確な定量化は組織に以下をもたらします。

  • リソースを効果的かつ効率的に配分する
  • デザイン・アプローチを用いた継続的なリスク管理を開発し、実施する(開発、運用、配信等において)
  • 社内標準、ベースライン、プロセス、手順を成熟させる
  • 統制のフレームワークを成熟させる
  • 変更管理の仕組みを成熟させる
  • 説明可能なマネジメントシステムを成熟させる
  • ゼロトラスト・アプローチを導入する

この重要なトピックについて、今後も続報をお楽しみに。

コンプライアンス自動化革命: 真の変革の時

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

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

コンプライアンス自動化革命:真の変革の時

2025年01月28日
Jim Reavis, Co-founder and Chief Executive Officer, CSA

最近、世界中のセキュリティ・リーダーと話をする中で、1つのテーマが常に浮上します。それは、コンプライアンス要件に溺れている一方で、本当の意味でのセキュリティ向上を示すのに苦労しているということです。平均的な米国企業では、従業員の報酬総額の1.3~3.3パーセントをコンプライアンスに費やしている(Cato Institute)と聞きます。また、GRCユーザーの60%がいまだにスプレッドシートですべてを管理している(Coalfire Compliance Report 2023)と聞きます。これらを聞くと、何かを変えなければならないと思うはずです。
そのため、CSA が以前から取り組んでいた新しい取り組みを紹介できることを嬉しく思います:The Compliance Automation Revolution。しかし、その詳細を説明する前に、なぜ私たちにこの変革が必要なのか、その原動力となったある見解をお話しします。

限界点(ブレイキング・ポイント)はここだ

最近、あるワーキンググループの会合で、ある人が、彼らの組織は137の国のデータ・プライバシー法を遵守しなければならないと話していました。これは 、GDPRのような州、セクター別、地域別の要件を数える前の話です。ITコンプライアンス上の義務をすべてマッピングしたところ、膨大な作業の重複が見つかりましたが、それでもまだ、何らかの形で抜けが残っていました。このような状況は、皆さんの多くにも思い当たる節があるのではないでしょうか。
数字が物語っています。Healthcare Financial Management Associationの調査によると、コンプライアンス違反によるコストはコンプライアンスへの投資額の3倍に上り、組織は1件あたり平均505万ドルのデータ侵害コストに直面しています(IBM’s Cost of a Data Breach Report 2023)。一方、世界の監査サービス市場は、2024年には2,266億ドルに達します(Mordor Intelligence社)。私たちはこれまで以上に支出を増やしていますが、本当に安全なのでしょうか?

前進のための現実的な道筋

CSA では、現実的な問題を現実的な解決策で解決することを信条としています。業界リーダーや会員コミュニティとの広範な協力の結果、私たちはコンプライアンスを変革するための3つの重要な柱を特定しました。

  1. ビジネスに合わせて拡張できる自動化
  2. 重複した作業を排除する規制の調和
  3. 全員が足並みを揃えられるようにリアルタイムの情報交換

これは単なるフレームワークや要求事項のセットではありません。私たちは、コンプライアンスと保証への取り組み方を変革するための広範な連合体として、根本的に異なるものを構築しようとしています。

一緒に作り上げていくもの

私たちが何を提供するのかを明確にします。

  • 継続的なモニタリングアーキテクチャにより、問題をリアルタイムで検出
  • AIを活用した規制の分析により、複雑な要件を理解
  • 自動化された管理策のテストにより、手動によるオーバーヘッドを排除
  • マシン・ツー・マシンのコンプライアンス通信を可能にする標準

しかし、おそらく最も重要なことは、豊富な実世界のデータ分析を実施し、最もリスク低減に貢献するセキュリティ管理策を特定することです(そのリストは、皆さんが考えているよりも少ないかもしれません)。私たちは、長年の業界経験から、管理策の数が多ければ多いほどセキュリティが向上するとは限らないことを学んでいます。

技術的根拠

この革命のタイミングはこれ以上ないほど最適です。2030年までに世界中で572ゼタバイトに達するなど、データ作成の指数関数的な増加に企業が直面することが予測されています。2025年までに750億台のIoTデバイスが存在し、クラウド市場は2030年までに2兆4000億ドルに達すると予測されています。従来のコンプライアンスのアプローチでは、この成長に単純に追随できません。
だからこそ、私たちはこの取り組みにクラウドとAIの最新技術を活用します。そして、AIが私たちのソリューションの一部であると同時に、新たなコンプライアンス上の課題を生み出しているという皮肉な事実についても、私たちは十分に認識しています。検討しなければならないAIに関する規制、基準、フレームワークはすでに204件に達しています(Cloud Security Alliance AI Safety Initiative、2024年)。

行動を起こしましょう:革命に参加しましょう

私はこの業界に長くいるので、私たちが協力し合うことで真の変革が起こることを知っています。Compliance Automation Revolution は単なる CSA の取り組みではなく、この業界のすべての人に影響を与える課題に対する私たちの集団的な対応なのです。
トムソン・ロイターの「2023 Thomson Reuters Risk & Compliance Survey Report」によると、コンプライアンス・リスクへの対処を阻む要因のトップ3は、知識のある人材の不足、リソースの不足、企業文化の貧弱さでした。この方程式を変える必要があります。
段階的な改善の時代は終わりました。銀行を破綻させることなく、また私たちの意欲を失わせることなく、コンプライアンスが実際にセキュリティの改善を推進する未来を私たちと一緒に築きましょう。
私たちは2025年後半に「Compliance Automation Revolution」を正式に立ち上げる予定です。現在、この重要なイニシアチブの創設者になりたい先見性のある人材を募集しています。コンプライアンスの未来にどのように貢献できるか、ぜひお問い合わせください。結局のところ、最高の革命とは、私たちが共に築き上げるものなのです。

________________________________________
Jim Reavis
CEO, Cloud Security Alliance

理想的なクラウドセキュリティ運用のために – 自動化されたセキュリティ対策

理想的なクラウドセキュリティ運用のために -自動化されたセキュリティ対策-

2025年1月15日
クラウドセキュリティ自動化WG
株式会社マクニカ
辻 紀彦
根塚 昭憲

パブリッククラウドサービスの普及に伴い、ビジネスでの導入事例も増えています。クラウドの利用により、従来のコンピューティングでは難しかった多くの利点を享受でき、市場優位性を得た成功事例も珍しくありません。

一方で、クラウドを標的とした攻撃も顕著に増加しています。CrowdStrikeのレポートによると、クラウド環境への侵入事例は2022年から2023年にかけて75%増加しました。(※1)

こうした攻撃の手法は多岐にわたります。たとえば認証情報を盗み取って不正アクセスを試みる手法や、クラウド環境の設定ミスを悪用してデータやシステムへアクセスする手法もあります。ランサムウェアを用いてサービス内のデータを暗号化し、その復号のために身代金を要求するケースも少なくありません。

このような脅威から守るため、クラウドに対するセキュリティ管理、運用管理が組織の中で大きな課題となってきており、業界標準や組織の規定に基づいたセキュリティ運用が必要です。しかし、セキュリティ対策に過度な手間や時間がかかると、クラウド利用のメリットであるアジリティやコスト効率化が薄れてしまう可能性があります。

意外な影響としては、セキュリティを厳しくしすぎるあまり、開発者が余計な手間を避けるために会社が許可していないテナントを利用して開発を進めるといった、新たな問題も発生しています。

もちろん、自動化やAIを使わないセキュリティでは、広がり続けるセキュリティカバレッジ、攻撃スピードに対応しきれなくなることは言うまでもありません。

課題を解決するため、自動化やAIを活用し人的負担を減らしながらも、迅速で柔軟なセキュリティ対策を講じることが重要となります。最近ではAIが組み込まれた機能が急速に拡充されており、複雑なセキュリティ課題にも対応できるようになっています。これにより、経験の浅いエンジニアでも効率的な調査やセキュリティ対策を講じることが可能となり、少人数でも高い水準のセキュリティを維持できる環境が整いつつあります。

今回は、CSPM (Cloud Security Posture Management) と CWPP (Cloud Workload Protection Platform) による自動化されたセキュリティ対策を取り上げ、最近注目されている CNAPP (Cloud Native Application Protection Platform) との関係についても解説します。

同じようなソリューションにSaaS環境の設定監査を行うSSPMというソリューションもありますが、SSPMの詳細に関してはこちらを参照ください。

サイバーセキュリティ管理における包括的なアプローチのNIST Cybersecurity Framework 2.0で「特定」「防御」「検知」「対応」「復旧」「統治」のフェーズに分けられますが、今回は分かりやすくするために「予防」「防御」「対処」の3つに分割します。予防はインシデントへの備え、防御はリアルタイムな攻撃に対しての対策、対処は発生したインシデントへの対応を意味しますが、様々なセキュリティソリューションが個々のフェーズの中に存在し、それぞれが必要なセキュリティ機能を提供しています。

今回はこれらの中からクラウドセキュリティとしての主要なソリューションであるCSPM (Cloud Security Posture Management)とCWPP (Cloud Workload Protection Platform)による自動化されたセキュリティ対策について取り上げ、最終的に近年大きな注目を集めているCNAPP (Cloud Native Application Protection Platform)との関係性について見ていきます。

  • CSPM (Cloud Security Posture Management)

CSPMはセキュリティベースラインの向上を目的とした予防ソリューションとして、クラウドインフラやクラウドアカウントを対象として、セキュリティ上あるべき設定、構成に準拠しているかをチェックするコンプライアンス準拠の役割やクラウド上に存在するOSやパッケージに代表される各種オブジェクトに含まれる脆弱性の検知を担います。従来のコンピューティングでは人間の手により、チェックシートを用いたセキュリティ監査を長いスパンの中で時間をかけて定期的に実行するセキュリティ運用が主流でしたが、単一のプラットフォームを複数のメンバーやプロジェクトで共通利用するクラウドコンピューティングではその変化のスピードに追従することは困難を極めます。こうした背景を元に機械的に自動化されたセキュリティ監査ソリューションの必要性が高まったことからCSPMが開発され、現在ではその効果が高く認められています。

CSPMによって予防できる可能性のあるセキュリティリスクの例

  • 【顧客情報の漏洩】
    顧客情報を格納しているデータストレージが設定ミスによりパブリック公開されていた
  • 【クレデンシャルの盗用】
    設定不備により、仮想マシンに格納されているクレデンシャル情報(メタデータ)が外部から認証を必要とせずに閲覧できる状態になっていた
  • 【クラウドダッシュボードの侵害】
    クラウドダッシュボードへのアクセス権を持つクラウドアカウントに対してMFA(多要素認証)を設定しておらず、攻撃者によりユーザー認証を突破された
  • CWPP (Cloud Workload Protection Platform)

CWPPは稼働中のワークロードに対するリアルタイムな攻撃を防御するための最後の砦として存在し、リスクのある挙動の検知と防御を提供するランタイム保護をメインとして、WAFやAPIセキュリティによってクラウド上で稼働するアプリケーションへの攻撃を検知、防御するアプリケーション保護の役割を担います。前述のCSPMと同様にCWPPの場合も、クラウドコンピューティングで発生する変化のスピードに追従するための自動化の仕組みが組み込まれています。例えばクラウド上にデプロイされた仮想マシンやコンテナのワークロードの平常時の挙動を学習し、その学習データに逸脱するプロセスの起動、ネットワークトラフィックの発生、ファイルシステムへの書き込みが発生した場合は検知と防御が自動的に実行されるセキュリティ運用が可能です。この仕組みにより、頻繁に増減を繰り返すクラウド上のワークロードに対するセキュリティポリシーの適用を簡素化しながら、脅威に対して効果的な防御を働かせることができます。

CWPPによって予防できる可能性のあるセキュリティリスクの例

  • 【不正プロセスの実行】
    攻撃者により侵害されたコンテナ内部で仮想通貨のマイニングスクリプトが実行された
  • 【攻撃の水平展開】
    攻撃者により既に侵害された仮想マシンから同一クラウドテナント上の別の仮想マシンに対してネットワークアクセスが実行された
  • 【ファイルシステムへの不正アクセス】
    攻撃者により侵害された仮想マシンがマウントしていたデータベースのエントリが不正に書き換えられた

  • CNAPP (Cloud Native Application Protection Platform)

CNAPPはCloud Native Applicationと呼ばれる、クラウド上で稼働することを前提として作られたアプリケーションの開発から運用までの一連のライフサイクルに対しての網羅的なセキュリティソリューションを統合したもので、その中には5種類のセキュリティ機能が含まれます。CNAPPには2021年頃から注目が集まり始め、CNAPPに含まれるセキュリティ機能に準拠しようとするクラウドセキュリティソリューションが現在も増加傾向にあります。CNAPPの構成要素の中で前述したCSPMはクラウドインフラ、クラウドサービスの設定監査を担うPosture Managementに分類されるセキュリティソリューションとして存在し、CWPPはクラウド上で稼働するワークロードを保護するためのセキュリティソリューションとして位置付けられています。クラウド上で稼働するアプリケーションのライフサイクルに対して自動化されたセキュリティ機能を実装できることはライフサイクルに含まれる一連のタスクの円滑な進行を妨害することなく、効果的なセキュリティ対策を組み込むための不可欠な要素として認知されています。また、アプリケーションの開発から運用までの一連のライフサイクルのタスクをクラウドサービスを活用して実行する場合は、本記事で主要なクラウドセキュリティソリューションとして解説したCSPM、CWPPだけでなく、CNAPPに含まれる全てのセキュリティ機能を網羅的に利活用するセキュリティ運用を検討する必要があります。

  • まとめ

クラウドサービスの利活用促進が活発化する一方でセキュリティ対策の確立が大きな運用課題になっています。クラウドセキュリティの導入を検討する場合は、最低限の運用負荷で最大限の導入効果を得られるソリューションとしてセキュリティ運用の自動化が重要な鍵を握ります。本記事では理想的なセキュリティ運用を実現するために予防ソリューションであるCSPMと防御ソリューションであるCWPPを主要なセキュリティソリューションとして優先的に活用し、必要に応じてCNAPPに含まれる様々なセキュリティ機能の追加活用を検討する必要性について解説しました。パブリッククラウドサービスを活用することによる様々な利点を享受しながら、堅牢なセキュリティ機能が実装されている理想的なコンピューティングプラットフォームを実現するための参考材料になることを願っています。

参考文献

※1 参考:CrowdStrike プレスリリース https://www.crowdstrike.com/ja-jp/press-releases/2024-crowdstrike-global-threat-report-release/

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等の要求事項となっているので、こちらの理解も深めていく必要がある。

以上