要旨

Google Cloud Next Tokyo ’23、 Day1 / Day2 にフル参加しました。
私は、ガッツリ講演タイプの参加でしたので、会場はまったくまわらず講演を聞いてブログを上げる生活をしていました。

時間に追われ、 5分 10分の余裕もなく駆け回ったような 2日間でした。
2日間のエネルギーをくれた、フィナンシェと大量のコーヒーに感謝します。

ここでは、セキュリティ系の講演を中心に聞いた内容を総括します。

時間も少なく、全てに参加は出来ませんでしたが、私の参加した講演の中からまとめていきます。

参加セッション

私の参加したセッションは以下のとおりです。

セッションID タイトル
D1-KEYNOTE DAY1 基調講演
D1-SEC-01 【初級】国内提供開始へ|統制を要するワークロードのための Assured Workloads 環境とは
D1-PL-07 【中級】機密データを安心してお使い頂ける AMD が提供するコンフィデンシャル コンピューティング
D1-SEC-02 【初級】金融システムのセキュリティ対策要点と最新版 FISC リファレンスのご紹介
D1-AIML-09 【中級】生成 AI 時代の MLOps 実現方法とは?
D2-KEYNOTE DAY2 基調講演
D2-COL-01 【上級】Google Workspace で実現する生成 AI 時代のセキュリティとデータ保護
D2-PL-12 【中級】クラウドからの情報漏えいを防ぐ!WAF の自動運用で工数削減・セキュリティ強化する方法
D2-SEC-01 【中級】侵害事例から読み解くクラウド セキュリティと対策のポイント
D2-SEC-03 【中級】What’s Next for Security?|最前線のインテリジェンスと AI によるセキュリティの変革
D2-SEC-02 【中級】Google Cloud のセキュリティ機能、基本のキ|Security Command Center で実現するリスク管理

改めて見ても、意味の分からない参加量です。
この中から、気になった話題などをピックアップしてお伝えします。

総括

データ主権を守る Assured Workloads の日本提供

多くのセッションで、Assured Workloads 関係の話題が出ていました。

講演のメインとして触れられていたのは『国内提供開始へ|統制を要するワークロードのための Assured Workloads 環境とは』 ですが、それ以外の多くの講演でもデータ主権とともに触れられていました。

データ主権については下記のブログでまとめています。

Google Cloud Next 講演から考えるデジタル主権のあり方
統制を要するワークロードのための Assured Workloads とは

データ主権という考えは、『自社のデータは自国の法令の元で保護する』という考え方が中心にあるものです。
地政学的リスクを回避しようとするもので、 US / EU を中心とした国の企業に広がっています。

Google Cloud を含めた大手クラウドは米国法を排除することが難しく、またリージョンの概念は、リージョンを有する国の管理下にデータが置かれるということです。

個人情報や、国防情報、製造業の CAD 図面など、企業は法規制を受ける情報や他国の攻撃から防ぐ機密情報を多く有しています。
従来のクラウドのようにグローバルで情報を保管しようとした場合、法令違反や自社に対する不当な開示要求などのリスクに曝されます。

近年の地政学的リスクの増大は、これらのリスクが加速的に増加していると考えられます。

Assured Workloads は、データの日本国内での確実な保管と、顧客管理暗号鍵の使用を提供します。

Assured Workloads を利用することで、多くの企業は日本国内にデータを保管することができ、他国の法令による影響を最小限にすることができます。
地政学的リスクというと、防衛、金融などの法令遵守が強く求められる企業の話かと思われます。
しかし、 Assured Workloads は機密情報を扱うすべての企業に利用してほしいサービスです。

クラウド上のデータ主権を、クラウドの管理下から自社の管理下に取り戻すサービスが、Assured Workloads と考えます。

What’s new in Assured Workloads: Japan regions, move analysis capability

使用中のデータを保護する Confidential VM

Confidential VM は、あまり注目されていない、また AI ほど大々的に宣伝されていませんが、必須としてもよいと考えるサービスです。

データ保護というテーマで考える時、保管中 (At rest) や転送中 (In transit) 中の安全性がよく語られます。
Assured Workloads でも Cloud HSM による CMEK の暗号化を推奨していますが、これは保管中の暗号化です。

データは、活用されることに意味があります。
Google Compute Engine (GCE) や Google Kubernetes Engine (GKE) などのコンピュータ上でデータが処理される状況まで考えて機密性を考えなければなりません。

一般的で忘れがちなことですが、クラウドは仮想化技術を活用しています。
仮想化は、1台の物理サーバーを論理的に複数の組織で利用しています。
そのため、メモリ、CPU などのハードウェアを複数の組織で共有しているということになります。

Virtual Machine は、CPU の仮想化支援機能 (Intel VT / AMD-V 等) で特権レベルで分離されています。
しかし、Meltdown や Spectre などの CPU レベルの脆弱性が発生することもあり、安全が保証されるものではありません。

AMD VM で利用可能な Confidential VM はこの問題を解決するものです。
講演の中では『機密データを安心してお使い頂ける AMD が提供するコンフィデンシャル コンピューティング』で詳細に解説がありました。

Confidential VM は、仮想マシン毎に一時的な暗号鍵を作成し、実行中のメモリを透過的に保護します。
たとえ、Google Cloud の管理するホストマシンや、他社が管理するインスタンスからメモリ内容を盗聴できたとしても、Confidential VM を利用するインスタンスのメモリは暗号化され、機密性が担保されます。

Confidential VM については下記のブログでまとめています。

機密データを安心してお使いいただける AMD が提供するコンフィデンシャルコンピューティング

この機能が他社より優れている点は、透過的に利用でき、AMD64 命令系であり、オーバーヘッドが最小である点です。

Confidential VM は透過的に利用できるため、ユーザー側のアプリケーション修正は不要で、インスタンス上で動くすべてのソフトウェアを保護できます。
AMD64 命令系 (x64 命令系) は、Windows や Linux などのサーバー用途で主に使われる命令系です。
Intel などの他社の CPU でも、AMD64 命令系が利用されています。
そのため、既存アプリケーションの互換性を考える必要はなく、再コンパイルなども必要ありません。
また、ハードウェア上に実装される専用サブシステムで実行されるため、CPU の動作に対して影響は殆どありません。

機密情報を処理する可能性のあるすべてのインスタンスは、Confidential VM を利用すべきであると、私は考えます。

AI によるセキュリティ運用支援 Google Workspace

Google Cloud ではありませんが、Google Workspace の AI 支援は目を引きました。

ISMS などのマネジメントシステムでは、組織が自身のポリシーを定めて運用することを求めています。
その中で、情報資産の管理台帳を作り、情報資産の利用方法、流通方法などの定めに応じて運用することを求めています。

ISMS を取得している組織では、情報資産管理規定などの規定が存在し、すべての従業員はこの規定に則った運用が求められます。

ところで。
『普段、文書を作るときに情報資産管理規定に基づき情報資産を分類し、適切なラベル付けを行っていますか?』
『社員の皆さんは、組織が定める情報資産管理規定を適切に運用できていますか?』

おそらく、多くの組織が『出来ていない』と答えると思います。

今の ISMS の運用は従業員に任されています。
組織は、適切な運用が出来るように従業員に対して教育を行います。

しかし、この運用は限界に来ていると個人的に考えています。
なぜなら、従業員の皆さんはお客様に対して価値を提供することが目的であり、自社のセキュリティ運用は二の次、となるからです。

これは、多くの組織が抱える課題であると考えます。

今回、『Google Workspace で実現する生成 AI 時代のセキュリティとデータ保護』の講演にあった生成 AI によるセキュリティ対策は、この課題に対するパラダイムシフトになると考えます。

組織は、自社の定める運用ルールを生成 AI に学習させることで、社内にあるすべての文書を生成 AI が分類し、適切な運用を提案してくれます。

今まで、従業員に対して学習をさせていたように、生成 AI に学習をさせることで、自社のセキュリティ運用の専門家がすべての従業員に対して付くようなものです。

Google Workspace は、多くの法規制やガイドライン制約を受ける金融機関でも利用されています。

一昔前までは、情報を自組織に閉じ込めることで守ることが一般的でした。
組織ファイルサーバーや、組織ネットワークなど、組織の境界を定めて守ってきました。

この方法の大きな課題は、情報連携にあると考えています。
ビジネスは、関係者と情報を連携して成り立ちます。

しかし、関係者との連携する際に、ファイルをメール添付しパスワードもメール送付するなど、意味のないセキュリティ対策を量産する結果になりました。

Google Workspace を活用することで、自組織のコントロールをすべての段階で適用できます。

  • 作成された際、変更された際に最適な情報分類を実施する。
  • 情報分類に従い、情報の流通を強制する。
  • 許可された利用者に対して、許可された操作を強制する。 (複製禁止など)
  • 法規制などで禁止された操作を、実施させない。(マイナンバーの漏洩など)

当たり前のことを、当たり前にするために、クラウドを活用すると考えてください。

Google Workspace については下記のブログでまとめています。

Google Workspace で実現する生成 AI 時代のセキュリティとデータ保護
金融システムのセキュリティ対策要点と最新版 FISC リファレンスのご紹介

ISMS を推進するすべての事業者に対して、これからの時代どのように情報を保護するのか、改めて考えてほしいと思うセッションでした。

攻撃者の視点から見る、セキュリティ対策

これまでのセキュリティ対策を考えた場合、多くの点において受け身だったと考えます。

  • 構成をチェックする。
  • 脆弱性を管理する。
  • 脆弱性診断を行う。

これらの対策はすべて重要で、サービスを保護するために必要なことです。
しかし、攻撃者側の視点でみると全く見え方が変わります。

攻撃者にとって、目的を達成することが全てであり、過程はどうでもいいというのが基本です。
被害者が気が付かない段階で、被害者が対策を取るまえに、被害者が想定してない方法で、被害者に対して攻撃を成功させれば勝ちです。

これまでのセキュリティ対策に足りなかったのは、攻撃者の視点であると改めて考えさせられました。

Security Command Center の機能は、攻撃者に対してよりプロアクティブな対応を支援してくれます。

Attack path simulation では、攻撃者が利用可能なネットワーク / 権限を可視化できます。
データベースやストレージに対して侵入可能な経路が存在するのか? 攻撃者が特権を詐取できるパスは存在するのか? これらの問題を確認することが出来ます。

これにより、組織は具体的に危険なリソースに対して対策を取ることができるようになります。

Security Command Center では、脆弱性の他に脅威を検知することも可能です。
脆弱性と脅威は、似たようなものに見えますが全く異なるものです。

脆弱性は、悪用されうる内包したリスクを表します。
いまは悪用されていないが、いずれ悪用される可能性があるものです。

脅威は、今目の前にあるリスクです。
侵入されている、改ざんされている、暗号通貨 (仮想通貨) がマイニングされているなど、今行われているリスクです。

VM Threat Detection では、暗号通貨のマイニングや、攻撃ツールの一つである Rootkit がインストールされるなど、被害を受けていることをエージェントレスで検知できます。
Sensitive Actions Service では、攻撃者が侵入した後に『通常行うこと』を検知できます。

いずれも、今現在攻撃が行われ、何らかの被害が発生していることを表すものです。

プロアクティブな対策については下記のブログでまとめています。

侵害事例から読み解くクラウドセキュリティと対策のポイント
金融システムのセキュリティ対策要点と最新版 FISC リファレンスのご紹介

これらの攻撃者視点の対策を行い、第三者から報告を受けて気がつくのでなく、攻撃者を自社のコントロール下に置くための対策が必要であると考えました。

継続的な運用の継続

SIEM、SOAR、CSPM、WAF など、多くのセキュリティソリューションは入れることが目的ではありません。
導入して、チューニングして、訓練して、インシデント時にしかるべき対応を行うことが求められます。

しかし、多くの場合においてセキュリティ製品は導入後に適切な運用がされていないように見えます。

これらには、人材の不足や、即応体制の難しさ、アラートの洪水、能力の不足など多くの要因が絡まっていると考えています。

セキュリティ製品を導入すると、日々多くのアラートが発生します。
脆弱性の検知、脆弱性情報の更新、脅威の検知などのアラートの他、サービス影響の発生などビジネス側のアラートも発生します。

これらを適切に管理運用するのは、多くのリソースを必要とします。

Chronicle はセキュリティ運用をモダナイゼーションできます。
Chronicle は、ログを探索するだけの今までの SIEM とは一線を画しています。

私が考える Chronicle が優れた点は、Unified Data Model (UDM) と Enrichment にあります。

たとえば、tim.smith というユーザーが悪意ある操作を行ったとします。
古典的な SIEM の場合で、キーワードを tim.smith とすると見つかるのはログの中に tim.smith と含まれるものだけです。

Chronicle は違います。
Chronicle では、データの取り込み時に Enrich という操作が行われ、構造化データとしてデータが拡張されます。
tim.smith と検索すると、推移的に拡張されて関係するであろうすべてのログを横断的に検索できます。

この操作に、JOIN のような結合処理は必要なく、誰でも容易に検索することができます。

Chronicle SOAR では、脅威インテリジェンスと組み合わせ、必要な対応を自動化出来ます。
たとえば、マルウェアを検知した際の対応として情シスに連絡し、スキルを持った社員が検体から Hash を作成、VirusTotal で調査するなどの対応を行っている場合もあるかと思います。

Chronicle SOAR では、この一連の動作を自動化できます。
情シスに求められるのは、評価されたマルウェアの対応を検討することだけです。

また、Web アプリケーションに対する攻撃を防ぐ WAF についても運用の検討が必要です。
WafCharm では WAF 運用をオフロードできます。

WAF の運用も、WAF の適切なルール選定から、日々検知されるアラートへのチューニングなど、運用が不可欠です。
標準の WAF ルールで検知されなかったものは、IP ベースでブロックするなど、柔軟な運用が求められます。

これらの運用は、WAF に精通したセキュリティエンジニアが常時対応する必要がありました。

WafCharm を利用することでこれらの対応を自動化できるとともに、問題が発生した際のテクニカルサポートも WafCharm に任せることができます。

WafCharm は、iret のパートナーでもあり、多くのお客様に利用されているソリューションとなっています。

セキュリティ運用については下記のブログでまとめています。

Google Cloud Next Tokyo ’23 Day1 Keynote
Cloud からの情報漏洩を防ぐ WAF の自動運用で工数削減・セキュリティを強化する方法

その他

セキュリティではありませんが、大規模データの転送に用いることができる物理デバイスである Transfer Appliance が東京リージョンでも利用可能になっています。

先般、実際に発注を行い、日本での注意点などをまとめたブログを載せました。

最速レビュー! 日本で GA された Transfer Appliance を使い倒す
こちらの内容は多くの方に高評価をいただいております。
大規模データのほか、クラウドへのセキュアなデータ転送に興味がある方、単純に物理デバイスに心躍る方は、ご一読をいただけると嬉しく思います。

まとめ

2日間にわたって実施された Google Cloud Next Tokyo ’23 のセキュリティ関係のセッションに関する総括は以上です。

多くのセッションで言われていたのは、セキュリティ運用など日々発生するタスクは AI や専門家に任せて自身はビジネスのコアに注力してほしいということかと思います。
総括としても、運用負荷を自動化したり、任せたりといったことを中心としてまとめさせていただきました。

AI による支援は、これからビジネスを変えていくと考えます。
これらの価値をお客様にお届けできるよう、これからも知見を高めて発信していきたいと思います。