カテゴリー別アーカイブ: CSAジャパン

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ジャパンの豊富な翻訳資料・講演資料に大いに助けられました。どうもありがとうございました。

以上

グローバルプロバイダが日本語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が公開しているコンテナおよびサーバーレスのセキュリティに関する資料を参照しながら説明してきた。コンテナのセキュリティについては整理されてきているが、サーバーレスについてはまだ適切なセキュリティが明確になっていない。今後、様々な形で情報が提供されてくるので、それを見ていきながらサーバーレスとしてまとまった形でのセキュリティについて説明できるようにしていきたい。

以上