タグ別アーカイブ: CSA

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

以上

CSAの認証制度:STAR認証について

STAR認証について

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

本ブログでは、CSA(Cloud Security Alliance)が提供するSTAR(Security, Trust & Assurance Registry)認証について、その概要、特徴、利用方法、CSAジャパンの活動について説明します。特に、STARレベル1(セルフアセスメント)について、プロバイダがクラウドサービスの自己評価レポートをCSA本部のウエブサイトより公開する方法について記述します。

  1. STAR概要

    STARは、CSAが提供するクラウドセキュリティの認証制度です。大きなフレームワークは以下の図1で示すように、3つのレベルを持っています。また、それぞれのレベルに対して、「セキュリティ認証」と「プライバシー認証」の2つのカテゴリーがあります。

    図1 STARフレームワーク

まず、「STAR認証レベル」について説明します。

  • STAR Level1

    STAR Level1はセルフアセスメントです。これは、クラウドサービスプロバイダが、CSAが提供しているCAIQ(Consensus Assessment Initiative Questionaire)に基づいて、自身が提供するクラウドサービスのセキュリティを独自に評価し、CSAのウエブサイト(https://cloudsecurityalliance.org/star/registry/)から公開するものです。CAIQは、CSAが提供するクラウドセキュリティの管理策集であるCCM(Cloud Control Matrix)のそれぞれの管理策について、いくつかの質問形式にブレークダウンしたものです。質問形式になっているため、クラウドサービスプロバイダは「YES」「NO」で回答することができます。また、回答に対するコメントを入力し、追加の情報を記述することができます。
    STAR Level1の特徴は、クラウドサービス利用者が、利用しようとしているクラウドサービスが自組織のセキュリティ要求事項を満たしているかどうかを、公開されている情報をもとに確認できることです。つまり、プロバイダの透明性が実現できているということになります。また、プロバイダの立場では、セキュリティ情報を積極的に公開することで、たくさんの利用者に対して統一したメッセージを出すことができますし、この情報をビジネス上の差別化要因として利用することもできます。
    STAR Level1の登録方法について、以下のウエブサイトに日本語で記述していますので参照してください。
    https://www.cloudsecurityalliance.jp/site/?page_id=1005

 

  • STAR Level2

    STAR Level2は、第三者評価になります。クラウドセキュリティの評価としてCCMを使用しますが、以下の示す他の業界認定や標準を基にして、クラウドセキュリティを評価しています。

    • CSA STAR CERTIFICATION: ISO/IEC 27001
    • CSA STAR ATTESTATION: SOC2
    • CSA C-STAR: GB/T22080-2008

STAR Level2の特徴は、認証だけでなく成熟度も評価していることです。クラウドサービスの成熟度を「ブロンズ」「シルバー」「ゴールド」のレベルとして認定します。
以下の図はSTAR CERTIFICATIONを表しています。

図2 CSA STAR CERTIFICATION 成熟度モデル

  • STAR Level3

    STAR Level3は、継続的モニタリングです。認証取得後も、その対応状況を継続的にモニタリングし保証する制度で、FedRAMPなどのハイレベルの情報を扱う際に要求されているものです。こちらは、まだ準備中になりますので、提供され次第ご案内できると思います。

それから、Level1、Level2には、Continuous Self-assessmentがあります。これは、通常の1年に1回の認証に対して、より頻度を上げた認証を行うようにしたものです。

次に「セキュリティ認証」と「プライバシー認証」について説明します。

  • セキュリティ認証

    セキュリティ認証は、上記で記述したように、CCMあるいはCAIQを用いて認証を行うものです。

  • プライバシー認証

    プライバシー認証は、クラウド環境におけるデータ保護法令遵守に必要な要件を定義した管理策であるCode of Conduct for GDPRを使用して認証を行うものです。GDPR向けの行動規範に準拠しているかどうかを認証します。

 

  1. STAR認証の特徴

    STAR認証では、今までの認証制度の課題として以下の3点を挙げ、それぞれに対して取り組んでいます。

    • 認証の継続性

      認証は「ある時点 (point-in-time)」あるいは「ある期間 (period-of-time)」を対象とするアプローチです。これは、変化の激しいクラウド環境においては不十分であることが指摘されています。STAR Level1/Level2 Continuous Self-assessmentでは、頻度を上げた形での認証を行うことで、より現実に近い認証を行っています。これにより、クラウドサービス利用者に対して、セキュリティ管理策の実施状況に関する詳細な最新情報を提供できるようになります。また、STAR Level3が提供されるようになると、よりリアルタイムに近い認証が実現できることになります。

    • 認証の透明性

      第三者認証(STAR認証ではLevel2)では、クラウドサービスの可視化を高いレベルで確保することが難しいです。STAR認証の各レベルは、それぞれ独立して運用するのではなく、組み合わせることでより高いレベルの認証を実現できます。たとえば、Level1とLevel2を組み合わせることで、高い保証(第三者認証)と高い透明性(セルフアセスメント)の両方を実現できます。以下の図は、STAR認証の各レベルの関係を表現したものです。

      図3 保証と透明性

    • 相互認証スキーム

      STAR認証のベースになるCCMは、数多くの国単位/分野単位の基準/規格へのマッピングを提供しています。CCMでは、各規格とのマッピングとリバースマッピングを提供し、それぞれの規格との差異(ギャップ)を分析し、その情報を公開しています。理想としては、1つの認証を取得することで、その他の認証に関してはギャップ分だけやればよいことになり、1つの認証の取得から別の認証の取得までの労力を最小化することができます。あくまで最小化のレベルであり、これで相互認証できるというわけではないことは注意が必要ですが、様々な組織(EU-SECやFedRAMPなど)とのフレームワークの検討が進んでいますので、その進捗に期待したいと思います。

  2. STAR認証に対するCSAジャパンの取り組み

    CSAジャパンでは、以下の取り組みを行っています。

    • STAR認証に関する情報発信

      以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=429

    • CCM/CAIQの日本語化および情報発信

      以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=2048#ccm

    • STAR Level1(セルフアセスメント)の日本語での公開

      CAIQの評価レポートを日本語で作成し、それを公開する手順について以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=1005

    • 日本語CAIQ評価レポートを登録されたプロバイダ・クラウドサービスの公開

      CSAジャパンでは、STAR Level1 セルフアセスメントの登録において、日本語CAIQ評価レポートを登録されたプロバイダおよびそのクラウドサービスに関する情報を公開しています。CSA本部のSTAR Registryでは、CAIQ評価レポートとして日本語で提供されているかどうかを判断するのが難しいです。そこで、CSAジャパンでは、日本語CAIQ評価レポートを登録されたプロバイダ・クラウドサービスの情報を公開することで、日本の利用者が利用できるようにしています。
      公開ウエブサイトは以下になりますので参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=19811

以上

 

MS、アマゾン、グーグルらがクラウドデータの保護など目指す「Trusted Cloud Principles」について

Microsoft、Amazon、Googleらが、「Trusted Cloud Principles」という新たな業界イニシアチブを発表しました。これから関わってくる可能性が高いと思われるので、その内容について翻訳してみました。なお、ここの翻訳は、あくまで個人的に行ったものであり、正式な形で翻訳の承認を取ったものではないことに注意してください。ここの訳はおかしいよというところがありましたらご指摘ください。
原文は、こちらです。

Trusted Cloud Principles(信頼できるクラウドの原則)

原則

世界中の組織は、イノベーションを推進し、セキュリティを向上させ、新しいデジタル経済で競争力を維持するためにクラウドテクノロジーを採用しています。クラウドサービスプロバイダとして、国境を越えて利用されるサービスとインフラストラクチャを運用することにより、あらゆる規模の企業、公共部門のエンティティ、非営利団体を含むこれらの組織をサポートします。

Trusted Cloud Initiativeは、イノベーション、セキュリティ、プライバシを妨げる国際的な抵触法を解決し、クラウドにデータを保存および処理する組織の基本的な保護を確立および確保するために、世界中の政府と組んでいくことを目指しています。このイニシアチブを通じて、私たちは政府と協力してデータの自由な流れを確保し、公共の安全を促進し、クラウド内のプライバシとデータセキュリティを保護することを約束します。

このイニシアチブは、社内の人権影響評価を実施するなど、この分野で各企業が行った既存の取り組みに基づいています。これは、企業が取り組むベースラインとして機能します。

クラウドプロバイダとして、以下を主張します;

  • グローバルクラウドサービスを使用する個人および組織の安全性、セキュリティ、プライバシ、および経済的活力を保護することへの世界中の政府の関心を認識します。
  • 国際人権法がプライバシの権利を大事にしていることを認識します。
  • 利用者の信頼と、利用者のデータの管理とセキュリティの重要性を認識します。これには、利用者がクラウドで所有するデータの保護と、その信頼を確立、維持、強化する製品とポリシーの作成の両方が含まれます。
  • 国際的に認められた法の支配と人権基準を遵守する透明なプロセスを通じて、政府がデータを要求できるようにする法律をサポートします。
  • データアクセス、プライバシ、および主権に関連する抵触法を解決するための国際的な法的枠組みをサポートします。
  • データアクセス、プライバシ、および主権に関連する抵触法を解決するための国際的な法的枠組みをサポートします。
  • クラウド利用者の安全性、プライバシ、セキュリティ、およびデータの所有権を保護する、国内および国際レベルでの改善された規則と規制をサポートします。
  • 政府のデータ要求に関する集計統計を詳述する透明性レポートを定期的に公開することの重要性を認識します。

私たちの目的を達成するために、私たちは世界中の技術部門、公益団体、および政策立案者と協力し、特にデータセンタとクラウドインフラストラクチャを運用または運用する予定の国で、法律とポリシーが実質的に次の原則に沿っていることを確実にします。

政府は、狭い例外を除いて、最初に利用者を関与させる必要があります。政府は、例外的な状況を除いて、クラウドサービスプロバイダではなく、企業の利用者から直接データを手に入れようとする必要があります。

利用者は通知を受ける権利を持っている必要があります。政府がクラウドサービスプロバイダから直接利用者データにアクセスしようとする場合、そのクラウドサービスプロバイダの利用者は、データへの政府アクセスの通知を事前に通知を受ける権利を有する必要があります。その通知は、例外的な状況においてのみ遅らせることができます。

クラウドプロバイダーは、利用者の利益を保護する権利を持っている必要があります。関連するデータ保護当局への通知を含め、クラウドサービスプロバイダーが利用者のデータに対する政府のアクセス要求に異議を申し立てる明確なプロセスが必要です。

政府は法の抵触に対処する必要があります。政府は、ある国でのクラウドサービスプロバイダーの法令遵守が別の国での法律違反にならないように、相互の対立を提起し解決するメカニズムを作成する必要があります。

政府は国境を越えたデータの流れをサポートする必要があります。政府は、イノベーション、効率、セキュリティのエンジンとして国境を越えたデータの流れをサポートし、データの常駐要件を回避する必要があります。

クラウドにおける医療ビッグデータのプライバシー保護/セキュリティ管理(前編)

医療ビッグデータセキュリティに関連して、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2020年7月に「クラウドにおける医療ビッグデータ」(https://cloudsecurityalliance.org/artifacts/healthcare-big-data-in-the-cloud/)を公開している。この文書では、新型コロナウイルス感染症(COVID-19)対応下の医療分野におけるビッグデータのユースケースを紹介した上で、クラウド環境におけるプライバシー保護/セキュリティ管理策を整理している。

ビッグデータの特徴と分析機能

本文書では、まずビッグデータについて、従来の手法を利用して処理することが難しい大規模なデータ容量と定義し、以下の通り、6つのビッグデータの特徴(6Vs)を挙げている。

容量(Volume):生成されたデータのサイズは通常膨大で、1ペタバイト以上の容量になる。医療においては、電子健康記録(EHR)だけで大容量のデータとなる。加えて、このデータは、新たなテストデータとして導入される度に変更することができ、国際疾病分類(ICD)コードのようなものが更新される。

  • 速度(Velocity):データユーザーが、データにアクセスし、分析することができる速度。医療においては、医療提供者がタイムリーな方法で、データを交換・利用できるようにするために、速度が必要である。
  • 多様性(Variety):構造化、半構造化、非構造化など、データの種類。医療は、マルチメディア、ソーシャルメディア、金融取引など、多様なデータソースを有している。
  • 正確性(Veracity):生成されたデータの品質。生死に関する意思決定は正確な情報に依存するため、医療データは、適切で、信頼性があり、エラーのないものでなければならない。
  • 価値(Value):既存データの分析から得られる価値であり、ビッグデータの最も重要な側面である。現段階では、医療データの価値は、大半が研究に限定されている。
  • 可変性(Variability):時を超えたデータの一貫性に関することとみなされる。

そして、医療ビッグデータの基本的な分析機能として以下の4つを挙げている。

  1. 記述的分析:医療に関する意思決定を理解し、新たな情報に基づく意思決定を行うために、データを検証する。そのモデルは、有益な情報を抽出するために、データをカテゴリー化、特定、結合、分類するのに利用することができる。
  2. 予測的分析:将来を予測するために推定可能な関係性のパターンを特定する目的で。古いまたは要約された医療データを検証する。医療データに隠れたパターンを特定して、医療リスクを予期し、患者に関するアウトカムを予測し、健康関連サービスを向上させるために、データマイニングを利用することができる。
  3. 処方的分析:多くの代替手段を含む課題を解決し、記述的/予測的分析を実行不可能にするために、情報や健康医療知識を利用する。
  4. 発見的分析:データから未知の事実を特定し、将来を向上させるために、知識に関する知識を利用する。新しい病気や病状、医薬品、治療法を発見するのに役立てることができる。

台湾に学ぶ医療ビッグデータにおける予測的分析の有効活用

医療ビッグデータの代表的なユースケースとして、電子健康記録(EHR)がある。電子健康記録には、病歴や検査画像結果、人口統計などの情報が含まれており、各患者の変更状態および医療記録を継続的に追跡して、検査の重複および関連する費用を削減する役割を果たす。

また、医療機関の電子健康記録は、クラウド上にある地域医療情報連携ネットワークに接続され、すべての医療機関が患者情報にアクセスできるようになっている。消費者中心の環境への医療の移行とともに、電子健康記録のデータを、継続的に患者データをクラウドに送信するウェアラブル機器と連携させて、院内の処置を削減し、費用のかかる入院を回避することも可能となっている。さらに、一般住民の健康状態を評価し、パターンを特定するために、ビッグデータを利用することも可能である。

このように、医療機関のIT化や地域医療情報連携ネットワークの整備が進んだところでは、医療ビッグデータ利活用のユースケースが生まれている。たとえば、台湾の新型コロナウイルス感染症(COVID-19)パンデミック対応時には、公衆衛生当局が、旅行歴や臨床症状に基づいたビッグデータ分析を利用し、迅速な対応に当たっている。加えて、フライト情報や旅行歴に基づいて感染症リスクを分類し、リスクの低い患者に対しては入国審査を許可する一方、リスクの高い患者に対しては、自宅で隔離し、潜伏期間中はモバイルフォン経由で追跡する措置をとるなど、データに基づく意思決定を行っている。

台湾のケースは、予測的分析をうまく活用しながら、早期認識や日々のブリーフィング、健康メッセージにより、迅速・正確で透明性のある疫学情報を提供することによって、社会が迅速な危機への対応を実現し、パンデミック期の市民の利益保護を確実なものにする方法を示している。

(後編は後日公開)

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

認証基盤のモダン化とCASBのValue

三井情報株式会社
橋本 知典

今回は、企業のデジタルトランスフォーメーション(DX)に必要な認証基盤のモダン化とCASBのValueについて説明していく。

■2025年の崖

経済産業省が2018年に公表した「DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~」では、DXの実現ができない場合、2025年以降最大12兆円の経済損失が生じる可能性があると推定している。2020年は新型コロナウイルスの影響でテレワークが必要になり、セキュリティ対策の不備等、企業は環境に合わせて自社のビジネスを迅速に変革しなければ生き残ることができない問題に直面した。この問題は正に「2025年の崖」問題の先触れといえる。

企業は、DXに取り組むことが求められているが、DX推進に向けた大きな課題としてレガシーシステムの刷新がある。2025年には21年以上の基幹系システムを抱える企業が6割を超える。レガシーシステムを刷新しない場合、保守切れのシステムが増え、保守運用費のコストが大きくなる。またIT人材が不足していくと予想され、多くの技術的問題を抱え、運用が困難になることが想定される。さらに、システムのサポート終了などにより、障害によるシステムトラブル、サイバー攻撃によるデータ流出等のリスクが高まる。

図1 2025年の崖

2020年12月には、経済産業省からデジタルトランスフォーメーション(DX)の加速に向けた研究会の中間報告書「DXレポート2(中間取りまとめ)」が公表された。国内223企業がDX推進状況を自己診断した結果、2020年10月時点で9割以上が未着手や一部での実施の状況であり、想定以上に進捗が悪いことが判明した。

【引用元】
DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~
https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html

デジタルトランスフォーメーションの加速に向けた研究会の中間報告書『DXレポート2(中間取りまとめ)』
https://www.meti.go.jp/press/2020/12/20201228004/20201228004.html

■認証基盤のモダン化

「2025年の崖」問題に対する打開策としては、基幹系システムなどをクラウドサービスにマイグレーションすることである。クラウドサービスを活用することで、時間や手間をかけずに基幹システムを移行でき、業務標準化による生産性向上やコストの削減を容易に実現することができる。政府から「クラウド・バイ・デフォルト原則」の方針が出て、クラウドサービスの利用に主軸を置いたITモダナイゼーションが進められ、クラウドの信頼性も大幅に向上してきている現在であれば、安心して移行できるだろう。

クラウドサービスにマイグレーションした場合、IDの認証の連携先としてSAMLなどの認証プロトコルに対応した認証基盤が必要である。多くの企業は認証基盤にオンプレミスのActive Directory(AD)を利用しているが、AD単体ではクラウドサービスとの連携ができない。

また、昨今のサイバー攻撃の多様化・高度化により社内であっても安全とは言えず、オンプレミス環境は徐々にリスクが高まっている。特にランサムウェアは従来型とは変わってきており、企業に搾取した情報を公開すると脅し、高額の身代金を要求する暴露型のものが増えてきた。実際にADの乗っ取りや個人情報が漏えいした事例もある。サイバー攻撃を検知するにもオンプレミス環境では対策ソリューションの導入コストや運用負荷が大きくなる。

これらの課題に対し、認証基盤をモダン化することで解決ができる。クラウド認証基盤であれば、クラウドサービスとも連携でき、サイバー攻撃対策の強化やクラウドサービス毎のIDを一元管理することができるなど、セキュリティ面でも対策を進めることができる。また、境界ネットワークがなくなり、いつでも、どこからでも安全にシステムが利用可能になり利便性も向上する。

図2 認証基盤のモダン化

■CASBのValue

認証基盤のモダン化が進むと、基幹系システムや多くのオンプレミスのシステムがクラウドへ移行しやすくなる。そして最終的にはオンプレミスのシステムを無くすことができ、システムの全てをクラウドサービスに移行する企業も増えてくる。そこで新たな問題として、複数のクラウドサービスの管理やセキュリティが課題になる。クラウドサービスへの統一した組織のセキュリティポリシーの適用やガバナンスの強化が必要になるだろう。

CASBは企業でクラウドサービスの活用が増えるほど真価を発揮する。もしクラウドサービス毎にセキュリティ対策を個別で行った場合、コストが高額になってしまう。CASBを導入すれば複数のクラウドサービスに対し、CASBのコストのみでセキュリティ対策が可能になる。また、CASBでは一つの管理画面から連携しているクラウドサービスのポリシー設定が可能であり、統一したポリシー管理が可能である。他にも、クラウド認証基盤と連携することで、リバースプロキシアーキテクチャによりエージェントレスで、連携したクラウドサービス内のファイルダウンロードなどのアクティビティに対し、リアルタイムでセッション制御が可能になる。例えば、社給端末以外からクラウドサービスのファイルの閲覧はできるが、機密情報のファイルのダウンロードをできないように制御が行えるなど、高度な情報漏洩対策ができる。このようにコスト面・管理面・セキュリティ面でもCASBのValueはさらに上がっていくことが想定される。

以上のように、企業は「2025年の崖」問題の対策として、認証基盤のモダン化を行い、基幹システムをクラウドサービスに刷新していくことでDXを促進できるだろう。そしてクラウドセキュリティ対策として今一度CASBの活用を検討してみてはどうだろうか。

〈お断り〉
本稿の内容は著者の個人的見解であり、所属企業・団体及びその業務と関係するものではありません。

SPA (Single Packet Authorization)解説

SPA (Single Packet Authorization)解説

2019年8月27日
CSAジャパン
諸角 昌宏

本ブログは、SDP(Software Defined Perimeter)の中核の技術であるSPA (Single Packet Authorization)が、どのようにゼロトラスト環境で有効であるかについて説明します。特に、インターネット上に安全なサービスを提供するため、認証が取れるまでは全てのアクセスを拒否する”Deny-ALL”が、どのように実現できているかについて説明します。

インターネットのアクセスにおける課題とSPA

リクエスト-レスポンス型であるインターネットのアクセス方法は、クライアントからのリクエストを受け取るために必ず口(ポート)を開けて待っています。これは、正しいユーザだけでなく、悪意のある人にも開いているということで、セキュリティ上の問題を引き超す可能性を高めています。悪意のある人は、ポートスキャン等を行って、インターネット上に開いているポートを探し、それに紐づくサービスを特定し、そのサービスの脆弱性を突いて攻撃を仕掛けることができます。また、開いているポートに対してSYNフラッド攻撃によりDoS/DDoS攻撃を行い、サーバを接続不能にすることができます。
このようにインターネットがもともと抱えている課題に対して、アクセスが許可されるまでは全てのポートを閉じておくという、いわゆる”Deny-All”を実現することで対処することが求められています。このための方法として、大きく以下の2つがあります:

  •  ポートノッキング
  • SPA

これらについて、以下で説明していきます。

ポートノッキング

ポートノッキングは、決められたポートを決められた順番でアクセスすることでファイアーウォールに穴を空ける仕組みです。例えば、ポート1000、2000、3000に対して順番にTCP SYNパケットを送った場合のみ、ポート22 (SSH) へのアクセスが許可されるというような設定ができる機能になります。この場合、最初の状態ではポート22は閉じられており、ポートノッキングに定義されたTCP SYNのシーケンスが来た時のみ、一定時間ポート22を開放します。クライアントは、この開放している時間内にポート22に対してアクセスすることで接続できます。これにより、通常はDeny-Allの状態を維持しつつ、決められたポート番号に決められた順番でパケットが送られてきた時のみアクセスを許可するということが実現できます。

したがって、ポートノッキングには以下のようなメリットがあります。

  • パケットはデフォルト・ドロップ
    サーバに送られてくるパケットは、デフォルトでは全てドロップすることが可能になります。つまり、Deny-allを実現できます。これにより、サーバが提供しているサービスを非可視化することができ、サービス自体を悪意のあるアクセスから保護することができます。
  • ポートスキャンしても空きポートを見つけることができない
    悪意のある攻撃者がポートスキャンを行っても、開いているポートや稼働しているサービスを見つけることができません。したがって、悪意のある攻撃が非常に困難になります。
  • DoS/DDoS攻撃を最小化できる
    ポートノッキング用のシーケンスにならないパケットは全てドロップされますので、SYNフラッド攻撃のようにもともと開いているポートに対する攻撃を行うことができなくなります。

一方、ポートノッキングには以下のようなセキュリティ上の問題があります。

  • リプレイ攻撃に弱い
    ポートノッキングに利用するパケットは、暗号化されずにそのままネットワーク上を流れます。したがって、ネットワークを盗聴し、クライアントからのパケット・シーケンスをそのまま送ることで接続できてしまいます。
  • 悪意のある第三者によるポートノック用のシーケンスの破壊
    正しいクライアントに代わってポートノック用のシーケンスの一部を送ることで、シーケンスそのものを破壊することができます。
  • IDSあるいはポートスキャンによるポートノック用のシーケンスの探索
    ポートノック用のシーケンスは一連のパケットの流れになるので探索が可能です。

SPA

SPAは、ポートノッキングの利点を持ちながら、ポートノッキングの課題に対処したものになります。” Software-Defined Perimeter: Architecture Guide”では、SDPの最も重要な要素の1つである「接続前認証(authenticate-before connect)」を実現するために、SPAを通してこれを実現していると述べています。また、このガイドでは、SPAはデバイスまたはユーザの身元を検証し、それから追加のアクセス制御を実施するシステムコンポーネント(コントローラまたはゲートウェイ)へのネットワークアクセスを許可するだけの軽量プロトコルで、これは、TCP / IPの根本的にオープンな(そして安全でない)性質を補うものとしています。SPAにより、要求者のIPアドレスを含むリクエスト情報は、単一のネットワークメッセージの中で暗号化および認証が行われ、デフォルトドロップのファイアウォールを通してサービスを見えなくすることができます。

SPAはプロトコルとして、SDP 1.0の中に仕様として記述されていますが、従わなければならないというような厳格な仕様では無いようです。したがって、SPAは実装の仕方においていくつかの異なる方法が取られています。ただし、SPAを実装するにあたっては、以下の3つの共通の原則を備えることを要求しています。

  • SPAパケットは、暗号化し、認証機能を持たなければならない。
  • SPAパケットは、必要な情報をすべて1つのパケットの中に含めなければならない。
  • SPAパケットを受け取ったサーバは、応答しないし、何も送信しない。

ここでは、SPAの実装方法を説明するにあたって、fwknopが提供するオープンソフトウエアを参照します。これは、LINUX JOURNAL Issue #156, April 2007 ” Single Packet Authorization fills the gaps in port knocking.”の内容を元にしてします。

  • SPAパケットの構成
    fwknopが用いるSPAのパケットは、以下の構成になります。

    • 16バイトのランダムデータ
    • クライアント・ユーザ名
    • クライアント・タイムスタンプ
    • fwknop バージョン
    • モード (アクセス、あるいは、コマンド)
    • アクセス (あるいは、コマンドストリング)
    • MD5 チェックサム

これらのフィールドの内容について以下に説明します:

  • 16バイトのランダムデータ、および、MD5 チェックサム
    16バイトのランダムデータを含み、パケット全体のMD5チェックサムを持つことで、1つ1つのSPAパケットが必ずユニークになることを保証します。これにより、サーバ側では、以前来たことのあるパケットと同じパケットが来た場合には、リプレイ攻撃であると判断し、接続を許可しないということができます。
  • クライアント・ユーザ名、クライアント・タイムスタンプ
    クライアント・ユーザ名、クライアント・タイムスタンプは、もう一段のレベルの認証・認可をサーバ側で行うのに用いられます。
  • fwknop バージョン
    fwknopとして、SPAのバージョン管理、特にバックワード互換性に用いられます。
  • モードとアクセス
    サーバ側に、クライアントからの要求が、サービスへのアクセスなのかコマンドの実行なのかを示します。たとえば、SPAでコネクションが許可された後、SSH(TCPポート22)のアクセスを許可するように設定できます。アクセスの場合には、アクセス・フィールドに直接ストリングを含めます。

この例を元に、SPAの特徴をまとめると以下になります:

  • Deny-Allの実現
    SPAパケットがクライアントからサーバに送られても、サーバがこれに応答することはありません。サーバは単にネットワーク上送られてくるパケットをスキャンする(たとえばlibpcapなど)だけで、SPAパケットでないものは全てドロップし、SPAパケットを受け取ると、その内容に基づいてクライアントとの接続を許可するかどうかを判断します。
  • リプレイ攻撃への対処
    上記の例では、1パケットの中に16バイトのランダムデータを含み、全体のパケットのハッシュ値を入れています。これにより、SPAパケットがユニークになることを保証します。サーバ側では、今まで来たパケットと同じパケットが来た場合には、リプレイ攻撃であると判断し、接続を許可しないということができます。
  • DDoS攻撃への対処
    Deny-Allであること、また、SPAパケットは1パケットであり、シーケンスではないことにより、DDoS攻撃の可能性を非常に下げることができます。
  • パケット・シーケンスの探索や破壊への対応
    SPAパケットは1パケットであることから、スプーフィングしたり解析したりすることが難しくなります。
  • 様々な認証情報の送信が可能
    SPAパケットの中には、様々な情報を含めることが可能なため、クライアントのユーザ名など、ユーザに対応した追加の認証等の処理が可能になります。

以上のように、SPAは、ポートノッキングのメリットを維持しつつ、課題を解決し、ゼロトラスト環境における最適なネットワーク環境を提供できるものと考えています。また、ここでは触れませんが、SDPが他に提供している機能(mTLS等)とSPAが組み合わされることにより、ゼロトラスト環境におけるさらに強固なネットワークセキュリティが提供できます。

なお、SPAは、fwknopからオープンソースとして提供されていますので、さらに理解を深めていただければと思います。

 

CSAジャパン関西支部、ついにキックオフ!(前編)

CSAジャパン関西支部、ついにキックオフ!(前編)
~キックオフセミナー概要と基調講演(データ政策とクラウド安全性評価)

CSAジャパン運営委員 有田 仁
2019年8月21日

  • はじめに

法人化から5年が経過、CSAジャパンは2019年(令和元年)度の取り組み目標の一つにWG活動等の「多拠点化へのチャレンジ」を掲げ、その第一弾として「関西支部」活動が新年度(本年6月)より本格スタートした。関西支部は、CSAジャパンの事業内容やワーキンググループ(WG)活動等に関して、関西地域における紹介や認知度向上をその活動目的とする。また関西地域のクラウドユーザーが有する潜在的交流ニーズの受け皿として、国内「面展開」の試金石となる。

図1:大阪城公園(天守閣)を一望  図2:キックオフセミナー会場

上記を受け、7月11日(木)午後より、広大な大阪城公園と壮大な天守閣を窓から眼下に一望できる(図1)、大阪ビジネスパークのクリスタルタワー20階E会議室を会場(図2)として、関西支部キックオフセミナーが開催された。当日プログラムは以下3名の講師による講演で構成された。

  1. 【基調講演】「今後のデータ政策の展開とクラウドサービスの安全性評価について」
    経済産業省 商務情報政策局 情報経済課 課長補佐 関根 悠介氏
  2. 「CSAジャパン関西支部の立ち上げにあたり」
    一般社団法人日本クラウドセキュリティアライアンス 業務執行理事 諸角 昌宏
  3. 「CSA Japan Summit 2019: Recap」
    一般社団法人日本クラウドセキュリティアライアンス 運営委員 有田 仁(※本レポート筆者)

本年は観測史上最も遅い梅雨入りとなり、あいにく当日午後の天候は小雨模様となった。それにもかかわらず、関西を地盤とするICT・電機・医療分野等の企業、監査ファーム、大学・研究機関、また官公庁関連団体などから幅広く、クラウドサービス導入やセキュリティ対策に関心をお持ちの参加者46名のご来場を得た。本稿前編では、上記講演プログラム1(基調講演:今後のデータ政策の展開とクラウドサービスの安全性評価について)に関する所感報告について以下に述べる。

  • 講演プログラム報告
  1. 【基調講演】「今後のデータ政策の展開とクラウドサービスの安全性評価について」(経済産業省 商務情報政策局 情報経済課 課長補佐 関根 悠介氏)
    本セミナーの基調講演として、経済産業省 商務情報政策局の関根氏より、データ政策とクラウドサービスの安全性評価制度の検討状況に関してご講演いただいた。これは本稿後編で述べるCSA Japan Summit 2019(本年5月15日開催/会場:東京大学伊藤謝恩ホール)の招待講演プログラムで、同省の松田洋平氏から事前に講演いただいた内容に通じ、これに近時のパブリックコメントの集約状況等をアップデートの上、関西地域のユーザーへも是非とも聴講機会を頂戴したいとの当会依頼に対し、ご快諾いただいたものである。本講演内容は2つの柱、すなわち①データ流通政策(DFFT:Data Free Flow with Trust)の展開②クラウド・バイ・デフォルト原則とクラウドサービス安全性評価制度の検討状況、からなる。
    DFFT(Data Free Flow with Trust)は、本年1月23日開催の世界経済フォーラム年次総会(ダボス会議)で日本の安倍総理により提唱された「信頼性のある自由なデータ流通」を促進するコンセプトである。すなわち国際的なデータ流通網を構築し、データの囲い込みを防止してその活用最大化を目指すものである。これは本セミナーの直前(本年6月28日・29日)に、インテックス大阪を会場に開催されたG20 Osaka Summit 2019で大阪トラック立ち上げ宣言として盛り込まれたこともあり、参加者の関心は高かった様に思われる。

    ここでの主な論点は、DFFTによる国際的なデジタル経済の成長促進とプライバシーやセキュリティの確保とのバランスをいかに図っていくかにある。これへの対策として、個人情報や知的財産等の安全性確保に向けた個人情報保護法の3年毎の見直し、現行ペナルティのあり方、外国事業者に対する法執行の域外適用や越境移転のあり方、また各国の関係法制度との相互運用性の確保等が検討されていることが説明された。

    クラウド・バイ・デフォルト原則は、2018年6月に「政府情報システムにおけるクラウドサービスの利用に係る基本方針」として採用された「クラウドサービスの利用を第一候補として政府情報システムの検討を行う」とするものである。しかしながらその一方で、適切なセキュリティ管理への懸念等から、(とりわけ)政府におけるクラウドサービス導入が円滑に進んでいない現状を鑑み、官民双方においてクラウドサービスの安全性評価の仕組みの必要性が掲げられている。また「サイバーセキュリティ戦略」(2018年7月27日閣議決定)において、政府プライベートクラウドとしての「政府共通プラットフォーム」への移行の推進が掲げられた。これらを受け、経済産業省と総務省で「クラウドサービスの安全性評価に関する検討会・WG」が2018年8月から複数回開催されるとともに、本年3月16日から4月16日にかけて、中間とりまとめ(案)のパブリックコメントが実施されている。なお同検討会WGメンバーには、当会運営委員の小川隆一氏(独立行政法人 情報処理推進機構/IPA)も名を連ねている。本評価制度は、政府調達における利⽤を第⼀に想定しつつ、民間の特に情報セキュリティ対策が重要となることが想定される重要産業分野等においても、検討結果の活用推奨が目されている。

    本講演で説明いただいた、同検討会における最新整備状況の細部について本稿で逐一再掲することは差し控えたいが、30分間用意していた質疑応答の時間帯は大いに活況を呈したことを報告させていただく。今回、中央省庁関係者からダイレクトに関西ユーザーに対して、取り組み最新状況についてお伝えいただく機会を設定できたことは幸いに思う。また、参加者からの活発な質疑に対し逐一懇切丁寧に応答いただき、セミナー後の懇親会(立食式)までお付き合いいただいた関根氏に、この場であらためて深く感謝の意を表したい。余談であるが、本セミナー開催から日を置かずに、某海外大手クラウドサービス事業者が上述の「政府共通プラットフォーム」に採用決定との報道が流れた。これに対し今後の世論において、様々な観点から議論が惹起されるであろうと予測される。
    (本講演資料は非公開)

※講演プログラム2 (CSAジャパン関西支部の立ち上げにあたり)、同3(CSA Japan Summit 2019: Recap)、及び関西支部の今後の展望について、本稿後編に続く。

以上

本当のSDPよ立ち上がれ! ~ Will the real SDP please stand up?

本ブログは、Optiv Security Inc.が公開している “Will the real SDP please stand up?” の日本語版になります。本ブログは、著者およびOptiv Security Inc.の許可を得て翻訳し、公開するものです。本ブログの内容と原文の間で相違があった場合には、原文が優先されます。


本当のSDPよ立ち上がれ!

原文: 2019年7月10日
日本語版: 2019年7月23日

Software Defined Perimeter(SDP)という用語は、ゼロトラスト(Zero Trust)モデルで安全なアクセスを提供するための新たなアジャイルな方法として最近普及してきています。SDPは、クラウドセキュリティアライアンス(CSA)によって定義された要件で、VPN /ファイアウォール/ NACの組み合わせよりも効果的で安全な方法でリモートアクセス機能を提供します。

ただし、SDPはアーキテクチャ的に異なる点があるため、多少新たな考え方が必要です。SDPは、データプレーンとコントロールプレーンを分離するネットワークの概念に基づいて作られています。これは、認証コンポーネントを拡張したポリシー決定ポイント(PDP)とポリシー実行ポイント(PEP)モデルになります。SDPの認証プロセスにおいては、「コントローラ(Controller)」はアクセスを認証するためのポリシー決定ポイントであり、「ゲートウエイ(Gateway)」はサービスへのアクセスに許可または拒否を与えるポイントになります。ゲートウェイから分離されたPDPトラフィックを使用することで、ハイブリッドクラウド環境全体でユーザーが同時にアクセスを許可される集中型のポリシーモデルと認証をサポートしているため、この機能は他のアプローチとの大きな違いになります。接続が確立され、ゲートウェイがユーザーに対して識別されると、ゲートウェイは、コントローラからの変更を定期的に確認しながら、デバイスの状態(device posture)や定義された条件に基づいてリアルタイムで決定を行うというハイブリッドな役割を果たします。これにより、コントローラが停止した場合の可用性が向上するだけでなく、障害ゾーンの分離とコントーラ/ゲートウェイのスケールアウトによりパフォーマンスも向上します。

SDPモデルは包括的で、アーキテクチャ的に異なる点があるため、従来のアクセスメカニズムやトンネリングには依存しません。つまり、SDPに加えてVPNやファイアウォールを必要とするものがあるとすれば、パフォーマンス、セキュリティ、アジリティに制限をかけるようなものであり、今日のリモートアクセスやハイブリッドクラウドにおけるワークロードの要求を満たさない可能性があります。

通信前の認証

SDPのもう1つのユニークな要素はSingle Packet Authorization(SPA)です。これは、すべてのネットワークセッションの最初のパケットで暗号化認証を要求し、許可されたクライアントだけがネットワークにアクセスできるようにします。

もともと2007年に作成されたSPAは、最初のネットワークパケットを暗号検証することで、DDoSに対する認証メカニズムを提供します。また、許可されたデバイスのみにサービスが公開されるため、エクスプロイトに対する保護も提供します。SPAで開始されていないTCPストリームはSDPによってドロップされ、コントローラまたはゲートウェイによって処理されることはないため、DDoSの影響を軽減します。SPAは、なりすまし防止や不正なデバイスによる保護されたリソースへのアクセスの防止など、DDoS防止以外の追加のセキュリティ対策を提供します。これにより、ユーザー名とパスワードが危険にさらされた場合に、資格情報を再利用する攻撃から保護されます。

SDPはどのくらい強力ですか?

2014年2月、CSAはSoftware Defined Perimeter ハッカソンのスポンサーとして、Black HatとDEFCONにSDPセキュリティを破ろうと挑戦する人のため環境を提供しました。世界全体で100億パケットを突破しましたが、攻撃は成功せず、賞品は求められませんでした。これは、SDPアプローチの長所をよく示しています。

私たちは、CSAのSDPワーキンググループに深く参加し、SDPソリューションをまとめることを経験しているSDP分野のリーダーです。ForresterとGartnerの業界調査の専門家が、今後数年間で安全なアクセス環境を大きく変えるであろうと予測しているゼロトラスト・ジャーニーにご参加ください。

原文 “Will the real SDP please stand up?” は、こちらを参照してください。

CASBWGリレーコラム(第6回)「IT規制改革を支えるCASB」

IT規制改革を支えるCASB

2018-05-08
CASBワーキンググループ
渡辺 慎太郎(個人会員)

「シャドーIT」という言葉を見かけることがあります。IT部門が知らぬ間に導入されるITシステムを指すようです。そして、シャドーITを発見するための道具としてCASBが紹介されることもあります。

ただ、個人的にはこの単語には違和感を覚えます。デジタルトランスフォーメーション(DX)が喧伝され、RPAなど企業活動におけるIT依存が高まる中、すべてのITシステムをIT部門が開発・調達することは現実的ではないでしょう。シャドーというと良からぬ響きを与えますが、事業部門や機能部門の自律的なIT利活用は、むしろ推奨されても不思議ではありません。

政府のサイバーセキュリティ戦略本部は「サイバーセキュリティ人材育成プログラム」(2017年4月18日)の中で、「新しいITの利活用における体制例」を掲げました(p.8)。そこでは、事業部門がIT部門を介さず、直接ベンダー企業やクラウド事業者と契約してITを利活用する姿が描かれています。

出典 サイバーセキュリティ戦略本部「サイバーセキュリティ人材育成プログラム」(2017)

上の文書を読んだとき、20年以上前に橋本内閣の下で「金融ビッグバン」として実行された金融規制改革を私は想起しました。過度な行政指導による護送船団方式が生み出す非効率な状況から脱却すべく、自由・公正・国際化を旗印にして改革を推進した当時の課題意識が、現在の企業においてIT利活用を推進する際の課題意識と重なって見えたのです。デジタルトランスフォーメーションの実現には、IT規制改革が不可欠だと思わされました。

規制改革の基本は、事前規制から事後チェックへとコントロールの力点を移すことです。そのためには、(裁量ではなく)明快なルールと適切な証跡とを必要とします。各部門の自律的なIT利活用が進めば、企業が利用するクラウドサービスの数は自然と増大するでしょう。

CASBを追加的なセキュリティ対策とみなすよりも、事前規制を緩和してIT利活用を促進するために必要な措置だと考えるほうが適切かもしれません。次回は、事前規制の緩和にCASBを利用する方法を検討します。

 

〈お断り〉
本稿の内容は著者の個人的見解であり、所属企業・団体及びその業務と関係するものではありません。