EN

NRIセキュア ブログ

パブリッククラウドの包括的なセキュリティに向けて|CSPM, CWPP, CNAPPs

目次

    blogtop

    クラウド上の公開Webセグメントを防御する2つの要素:クラウド設定とワークロード

     クラウドを活用するうえで必ず考慮しなければならないのが、責任共有モデル(共同責任モデルとも)です。これは、クラウド利用時の各コンポーネントの利用について、クラウド事業者(以下CSP: Cloud Service Provider)と、クラウド利用者(以下利用者)のどちらが責任を持つべきか、を示したものです。

     

     この「責任」には、セキュリティ管理ももちろん含まれます。公開しているCSPによって内容は少し異なるのですが、概ね下に示した図のようになります。オンプレミスでは利用者が全責任を負っていたものが、IaaS・PaaS・SaaSと進むにしたがって、徐々にCSPの責任範囲となるものが増えてきます。クラウドサービスの提供方式による責任範囲の違い

    新規CTA

     

     しかし、どこまで行っても利用者の責任がゼロにならないことも分かります。図で赤色となっている部分が原因となって発生したセキュリティインシデントは、すべて利用者の責任となります。

     

     この図は、CSPの責任放棄を表しているのではありません。この図で赤色となっている部分は、利用者に裁量が与えられている部分と理解することもできます。簡単に言ってしまえば、「管理主体が責任を持つべき」という、至極当たり前のことを言っているに過ぎません。


     簡単さを追求するのであれば、全業務をSaaS化することで、セキュリティの責任範囲は劇的に減少するでしょう(実際には、SaaSにはSaaSの難しさがあり、それをコントロールする手段がCASBです)。しかし、独自色、言い換えればセールスポイントを押し出すことは難しくなります。

     

     社内インフラならともかく、社外向けサービスの基盤をすべてSaaSに置き換えるのは、あまり現実的ではないでしょう。IaaSやPaaSを活用し、自らシステムを構築することで、差別化は容易になります。そのために発生するリスクは利用者が負うべき、ということです。ともあれ、この図で赤色となっている部分について必要なセキュリティ施策・管理は、利用者自身が行う必要があります。

     

     本稿では、いわゆる3大クラウドプロバイダ(AWS・Azure・GCP)によって提供されるIaaS・PaaS上にシステムを構築するケースを想定して、責任共有モデルにおいて利用者責任となる項目をカバーするためのソリューションである、CSPMとCWPPについて紹介します。

     

     

    image03

    クラウドの設定を司るCSPM

     責任共有モデルにおいて利用者責任となっている部分のうち、ワークロード(VM・コンテナといった、利用者が作成したソフトウェアの実行基盤)以外のコントロールは、クラウドの設定という形で与えられます。セキュリティに関連する設定の代表的なものには、公開設定・暗号化設定・ID管理などが挙げられます。

     

     設定不備におけるセキュリティインシデントの代表例は、ストレージサービス(Amazon S3等)や管理ツール(Elastic Search等)のインターフェイスの公開設定不備です。本来は関係者のみが閲覧可能であるべきデータを、誤って外部公開と設定してしまうことで、誰でも閲覧できる状態としてしまった結果情報漏洩に発展してしまう、という事案です。このインシデントは以前から数多く発生しており、CSPも「非公開」をデフォルト設定としたり、公開設定とする際には警告を出すなどの対策を加えているのですが、未だに新しいインシデントも報告され続けています。

     

     難しいのは、クラウドで新しいリソースを用意するのも、設定を変更するのもとても簡単なことです。簡単なことは良いのですが、ふとした拍子に設定を誤り、それが見過ごされてしまうリスクも相対的に高くなります。さらに困ったことに、設定不備はあくまで不備であって、脆弱性であると機械的に決めつけられないということです。

     

     脆弱性は必ず修正すべきものですが、設定を修正すべきかどうかについては必ず適切な判断が必要です。設定項目というものは、必ず意味があって存在しています。前述のAmazon S3にしても、外部公開するという用途が想定されているからこそ、外部公開という設定が存在します。問題は、その設定が利用者の(暗黙の)想定とズレてしまっていることであり、究極的にはクラウド利用者自身にしか、設定の妥当性を判断することはできません。

     

     また、インシデントに即座に直結するような不備とは言えないけれど、やっておいた方が良い設定もあります。例えば、ログ取得の有効化やストレージの暗号化などが該当します。これも、実施しておいた方が良い内容が多いことは多いのですが、実際に適用するかどうかはリソースのオーナーに委ねられます(実施することで追加コストがかかるものも多いです)。

     

     これらの、考慮すべき設定をまとめたベストプラクティスとして、CIS Benchmarksなどの公開ガイドラインが存在しますが、このガイドラインの準拠状況を人手でチェックしていくのは現実的ではありません。このように、クラウドの設定については、100%の正解がありません。ただし、経験的に設定不備の可能性が高いものを機械的に指摘することはできます。

     

     これが、CSPM(Cloud Security Posture Management)の基本的なコンセプトです。Posture(態勢・姿勢)という言葉が表す通り、CSPMはクラウドの設定が「良い状態」となっているかどうかを継続的にチェックします。

     

     前述の通り、設定が本当に「不備」であるのかどうかはそのリソースのオーナーにしかわかりませんので、不審な状態の「指摘」が主な用途となります。明らかに危険な状態(設定を強制修正することによりサービスへ影響を及ぼすことよりも、セキュリティリスクの方が高いと考えられるもの)を即座に修正するよう予め設定しておくことも可能です。

     

    CSPMの良いところは、

    • 継続的に設定をチェックし続けてくれること
    • CSPMサービスプロバイダが、チェック項目を追加していってくれること(新機能や新しいレギュレーションに追随してくれること)

    です。逆に言うと、このあたりがしっかりしていない製品は選ぶべきではないでしょう。
    また、CSPMの活用にあたっては、運用方針をきちんと決めておくことをお勧めします。CSPMによる検知は、ベストプラクティス的な対応を含めると多岐にわたります。漫然とした方針で導入すると、運用が形骸化してしまう恐れもあります。

    • どのような検知(アラート)について、どのようなスピード感で、対応を行うか
    • どのような検知については、自動での設定修正の対象とするか
    • どのガイドライン(公開、あるいは社内ガイドライン等)を基準として考えるか
    • 定期的なレビューなど、どのように運用を進めるか

    といった考慮点が考えられます。運用が難しいと考えられる場合、マネージドサービスを利用することを考えても良いでしょう。

    CSPMについては、こちらの記事もご一読ください。

    CSPMとは?クラウドの設定ミス防止ソリューション|選定で失敗しない3つのポイント

    ワークロードを守るCWPP

     もうひとつの重要な要素が、ワークロードのセキュリティです。ワークロードというのは聞き慣れない言葉かもしれませんが、従来の考え方に当てはめれば、サーバや仮想マシン、ひいてはそこで動作しているソフトウェアが該当します。


     ワークロード保護の考え方は、「ワークロード」という言葉でこそ明示されてはいませんでしたが、クラウド普及以前からあったサーバ保護(脅威防御)の考えとほぼ同じです。Webサイトを例にとると、例えばファイアウォール、IDS/IPS、WAF、サーバ向けアンチウイルス等のソリューションが挙げられます。これらのソリューションは、Webサイトがクラウドに移っても引き続き有効に機能するのですが、やや扱いに困るパターンが出てきてしまいました。その傾向が顕著なのが、マイクロサービスアーキテクチャです。

     

     セキュリティソリューション(CWPP)の説明の前に、マイクロサービスアーキテクチャについて、簡単に説明します。


     「コンテナ」「Docker」「Kubernetes」「サーバレス」というような言葉を聞いたことがある人も増えてきたのではないでしょうか。これらはみな、マイクロサービスアーキテクチャに関連する用語です。図は、従来型(モノリシック)アーキテクチャとマイクロサービスアーキテクチャの違いをごく簡単に表したものです。

     

     ここでは、簡単な例として、ログイン・残高照会・送金・預金の4つの機能を持つ、非常に簡単なバンキングアプリを考えてみます。このアプリを、従来型(モノリシックアーキテクチャ)と、マイクロサービスアーキテクチャのそれぞれで実装します。マイクロサービスアーキテクチャは、コンテナを使って実装するものとします。

     

    従来型アーキテクチャとマイクロサービスアーキテクチャ

      モノリシックアーキテクチャにおいては、1つのサーバで複数の機能が動作します。もしもサーバの性能が不足していた場合、サーバ単位での増設を行うことになります。サーバ内の複数の機能は密接に関係しており、一つの機能(例えば送金機能)だけに変更を加える場合についても、他の機能への影響を考え、サーバ全体のテストが必要になるケースすらあります。

     

     これに対して、マイクロサービスアーキテクチャは、機能ごとに専用のノードを必要なだけ生成し、そのノードの集合体としてWebサイト(サービス)が構成されます。この一つ一つのノードが提供するサービスをマイクロサービスと呼びます。コンテナを活用する構成の場合、このマイクロサービスを提供する個々のノードが「コンテナ」です。


    ※ 技術的には複数の要素がありますが、簡略化しています。「コンテナとは何か」の詳細については、本稿では扱いません。

     

    クラウド+コンテナを用いたマイクロサービスアーキテクチャには、例えば下記のような特長があります。

    • 高速で簡単なデプロイ・更新
      アップデートを行う際の対象が、(サービス間のインターフェイスに変更が無い限り)各マイクロサービスに限られる。つまり、更新の影響を最低限に抑えることができる。
      また、アップデートの対象はソフトウェアではなくマイクロサービス自体(コンテナイメージ)となる。つまり、変更のリリースは、ソフトウェアの書き換えではなく、サービス(コンテナ)の差し替えとなる。これは、リリース・テストの考え方を簡素化することができ、CI/CDツールを用いたリリースの自動化にも大きく寄与する。
    • スケーラビリティ
      必要に応じて、動的にマイクロサービスを追加・削除可能。負荷状態に合わせて自動的に増減させることもできる(オートスケール)。クラウドサービスの利用と組み合わせることで、コスト的な柔軟性を得ることができる。
    • 障害範囲の極小化
      ソフトウェア障害発生時の影響範囲を、特定のマイクロサービスに抑えることができる。これは、いわゆるシステム障害だけの話ではなくセキュリティインシデントの文脈においても同様で、仮にひとつのマイクロサービス(コンテナ)が侵害されたとしても、そこから他のコンテナへの侵入(ラテラルムーブメント)を防ぐことができれば、インシデントの被害を最小限に抑え込むことができる。

     

     しかし、従来通りのセキュリティソリューションを適用し続けると、これらのメリットを薄れさせてしまう恐れがあります。これが前述の「扱いに困る」というポイントなのですが、例えば下記のような問題があります。

     

    • 動的IPアドレス
      コンテナは動的に増加・減少する。アップデート(デプロイ)の際にはコンテナの差し替えが行われる。前述の通り、アップデートは頻繁に行われる。そのたびにコンテナのIPアドレスは差し変わる。従来のようなIPアドレスベースのコントロールの考え方を当てはめるのが難しい。
    • オートスケール
      ネットワーク型セキュリティソリューション(仮想アプライアンス)は、技術的・ライセンス的に簡単にスケールアップさせづらいことがある(単純にインスタンスを増やしても機能しない、インスタンスを増やしたり高性能なインスタンスに交換するにあたり、ライセンスの追加が必要となる等)。このため、ワークロードを機動的にスケールアウトできる設計としておいても、途中にあるセキュリティソリューションがシステム全体の性能に対するボトルネックとなってしまう可能性がある。
    • サービス間通信
      マイクロサービスアーキテクチャにおいては、各マイクロサービスが互いに大量の通信を行うことで、全体としてのサービスを成立させる。この通信をEast-Westトラフィックと呼ぶ (これに対して、インターネット~サーバ間のような外部~内部間の通信をNorth-Southトラフィックと呼ぶ)が、従来のFW・WAFのようなネットワーク型セキュリティソリューションでは、East-Westトラフィックを検査することができない。

     

     これらの課題を踏まえ、今後普及が期待されるソリューションが、CWPP (Cloud Workload Protection Platform)です。


     CWPPは、従来のアンチウイルスソフトウェアのように、各ワークロードあるいは仮想化基盤にソフトウェアをインストールすることで動作します。このような方式をとることで、従来のネットワーク型セキュリティソリューションよりもワークロードに近いところで防御機能を提供することができ、さらにワークロードと一緒にスケールアウトすることで、性能問題にも対応します。


     また、East-Westトラフィックの検査は、従来のサーバセグメントに設置したIDSに近い位置づけと考えると理解しやすいかもしれません。ただし、「障害範囲の極小化」で触れたとおり、サービス間での侵害の検出は、マイクロサービスアーキテクチャではより大きな意味を持ちます。East-Westトラフィック向けセキュリティ機能は、今後重要性が高まってくると考えています。

     

    課題例 CWPPによる解決方針

    IPアドレスベースのアクセスコントロールがコンテナアーキテクチャに馴染まない

    IPアドレスではなく、Identity (コンテナ名など)によるアクセスコントロール

    ネットワークアプライアンスの動的なリソース増強が難しい

    ワークロード側に防御機能を実装し、ネットワーク上のボトルネック化を回避
    ※ CWPPを動かす基盤側でのキャパシティ設計は必要

    サービス間通信(East-Westトラフィック)のセキュリティ

    ワークロード側で防御機能を実装し、North - South, East - Westトラフィックの両方を検査

     

     Platform(基盤)という言葉が表すように、CWPPは何か特定のセキュリティ機能を指すのではなく、セキュリティ機能を提供する統合的ソリューションを指すカテゴリ名です。具体的にどのような機能を持つのか製品によって異なります。

     

     提供される機能の例としては、マルウェア対策、ホスト型FW・IPS、アプリケーションセキュリティ(WAF・APIセキュリティ)、ランタイム保護(EDRに近い機能)、脆弱性管理などがあります。つまり、対応するセキュリティ対策の内容が様変わりしたというよりも、提供する場所と、適用の方法を最適化し、各種機能を統合することで、よりクラウド活用に相性のよい使い方ができるようになったソリューションと考えるとよいでしょう。

     

     また、CWPPというカテゴリ自体は必ずしもマイクロサービスアーキテクチャを前提としたものではなく、ホスト向け、コンテナ向けなど、得意とするアーキテクチャにも違いがあります。当社では、今まで述べたような理由から、CWPPの中でも特にマイクロサービスアーキテクチャに強いソリューションが今後必要とされると考えています。image02

    CSPMとCWPPの統合 - CNAPPs -

     今まで述べてきたように、監査・管理の側面が強いCSPMと脅威防御を主目的とするCWPPでは、保護の対象や、提供する機能は大きく異なります。しかし、クラウド上に配置したシステムを防御するという目的は同じです。セキュリティ担当者という枠組みから考えると、この2分野は同じ担当者(チーム)が取り扱うことになることも多いのではないかと思います。

     

     この観点から、CSPMとCWPPを一つのプラットフォーム(製品)で扱えるようにしよう、というのは自然な流れです。Gartner社は、CSPMとCWPPに、さらに実装前のセキュリティ(リポジトリ向けの脆弱性検査など)を組み合わせた統合ソリューションカテゴリとしてCNAPPs(Cloud Native Application Protection Platforms)と名付け、CNAPPsが今後求められていくと予想しています*

     

     CNAPPsに限らず、セキュリティソリューション全体の大きな流れとして、複数機能を一つのソリューションとして統合していく流れがあります。SASEはその好例です。統合型ソリューションを扱うことで、必要なセキュリティ機能を円滑に、齟齬の無い形で扱うことができます。

     

     何でもかんでも統合すればよいというものではないのですが、(CWPP自体も統合型製品ですが、さらに)CSPMとCWPPは統合されるべきである製品群である、と筆者も考えます。当社で取り扱っている、Palo Alto Networks社のPrisma Cloudは、CNAPPsの思想に非常に近く、設定管理からワークロードセキュリティ、リポジトリ向け脆弱性管理まで一括して行うことができます。

     

     また、複数のクラウドアカウントやシステムを包括して扱うことに長けており、組織単位で横断的にクラウド向けセキュリティを扱うことに向いています。Palo Alto Networks社は、Prisma CloudをCNSP(Cloud Native Security Platform)と位置づけ、クラウド向けの包括的なセキュリティ製品として拡張を続けていく方針です。

    Prisma_Cloud_CNSP

    図:Prisma Cloud のCNSPモデル

    Prisma_Cloudの実装前フェーズ(図左側)へのひろがり図:Prisma Cloudの実装前フェーズ(図左側)への広がり

     

     クラウドサービスが整備され、マイクロサービスアーキテクチャ・アジャイル開発・DevOpsといった概念・技術に支えられる形で、より高速に、ビジネス主体でのシステム開発が可能となりました。しかし、セキュリティまで十分に考慮してシステムを構築・運用するのはなかなか難しいのではないでしょうか。ツールを上手に使うことで、包括的にセキュリティを担保していくことを考えてみてはいかがでしょうか。


     システムの開発・運用は各組織で行いつつ、個々のビジネス固有の要件が少ないセキュリティ部分については組織横断的にツールを使い、一定のベースラインを確保するような運用を構築して、各組織のセキュリティ関連の負担を下げるようなことができます。ツール選定の際には、CNAPPsの観点に基づくような、必要な機能が統合されたソリューションを選定し、包括的なセキュリティ運用を目指すことで、負荷の低減や整合性の面でメリットを出すことができます。


     なお、CNAPPsという言葉はまだ発表されたばかりで、必ずしも自社製品のカテゴリをCNAPPsと名乗っているものばかりではないので、名称や謳い文句ではなく、機能が実際にCNAPPs的な観点で構成されているか、を確認すべきです。

     

     NRIセキュアでは、CSPM・CWPP (CNAPPs)をはじめとした、クラウドに親和性の高いソリューションを、設計・導入コンサルティングからマネージドサービスまで幅広く提供しております。システムやプロジェクトの運営に課題を感じるようでしたら、ぜひ当社にご相談ください。

     

    おすすめのサービス

    統合クラウドセキュリティマネージドサービス powered by Prisma Cloud from Palo Alto Networks

     

     

    *参考:Gartner, Inc. "Top Security and Risk Management ", "Market Guide for Cloud Workload Protection Platforms" (ともに2020年版)

     新規CTA

    CSPM製品活用セミナー ~クラウドの情報漏洩を引き起こす”設定ミス”をいかに無くすか~

     

    新規CTA