本文へ移動

第2回次世代セキュリティアーキテクチャ検討会

概要

  • 日時：令和4年（2022年）3月15日（火） 13時から15時まで
  • 場所：オンライン開催
  • 議事次第：
    1. 開会
    2. 議事
      1. ゼロトラスト・アーキテクチャ適用方針について
      2. 常時リスク診断・対処（CRSA）の導入に関する技術レポートについて
      3. 自由討議
    3. 閉会

資料

参考情報

議事概要

日時

  • 令和4年（2022年）3月15日（火）13時から15時まで

場所

  • オンライン開催

出席者

委員

  • 上原哲太郎（立命館大学情報理工学部教授）
  • 河野省二（日本マイクロソフト株式会社技術統括室チーフセキュリティオフィサー）
  • 木村滋（シスコシステムズ合同会社セキュリティ事業担当エバンジェリスト/アーキテクト ※1）
  • 後藤厚宏（情報セキュリティ大学院大学学長）
  • 崎村夏彦（OpenID Foundation理事長）
  • 田原祐介（株式会社ラックインテグレーション推進事業部インテグレーションサービス＆企画部 部長）
  • 楢原盛史（タニウム合同会社 チーフ・IT・アーキテクト）
  • 名和利男（株式会社サイバーディフェンス研究所 専務理事／上級分析官）
  • 前田典彦（株式会社ＦＦＲＩセキュリティ社長室長）
  • 丸山満彦（PwCコンサルティング合同会社パートナー）

※1　令和4年（2022年）3月17日（木）にメールにてコメントを受領

オブザーバー

  • 内閣サイバーセキュリティセンター（NISC）

デジタル庁（事務局）

  • 戦略・組織グループセキュリティ危機管理チーム

独立行政法人情報処理推進機構

  • デジタルアーキテクチャ・デザインセンター

議事要旨

  • 事務局より、資料1「ゼロトラスト・アーキテクチャ適用方針について」、資料3「常時リスク診断・対処（CRSA）の導入に関する技術レポートについて」、資料5「CRSAの実装を見据えた今後の対応方針ついて」について説明。
  • 「ゼロトラスト・アーキテクチャ適用方針について」に関する自由討議において、主に以下の発言。
  • ガイドラインの記載にはアクセスを受ける資産以外に、組織内のリソースにアクセスを求めるサブジェクトの評価も重要になるが、そのサブジェクトに関する記載がなかったため、設ける必要がある。
  • 「資産の把握」の「把握」という用語はガイドライン等の文書では利用しない。「識別」や「特定」といった次の作業プロセスにつながる用語に変更する方が適切と考える。
  • 言葉の定義が不明瞭な個所や、ゆらぎが見られる。例えば「きちんと」という言葉は定性的な表現となるため、ガイドライン上では利用を避けた方がよい。「リソース」という言葉が複数の意味で利用されている。言葉については見直す必要がある。また、「ジャーニー」という言葉への理解が得られない可能性がある。読み取り方が読者によって変わるため、利用を避けた方がよい。
  • 資産の管理と特定・識別・評価では地方の役所に見られるシャドーITの問題につながる。そもそも地方の役所ではゼロトラスト・アーキテクチャ適用の前段で躓く状態だが、この施策によりシャドーITの問題を浮かび上がらせることが可能となる。
  • BYODの記載が見られなかった。各省庁では公用のデバイスよりBYODの利用の方が多いというデータもあるため、含めることを検討する方がよい。
  • ゼロトラスト・アーキテクチャに向かった結果どういう変化が起こるのかの記載があった方がよい。現在のシステムのイメージとゼロトラスト・アーキテクチャ適用後の世界をイメージしてもらう必要がある。
  • 「図1：ゼロトラストのコア論理コンポーネント」では厳密なゼロトラスト・アーキテクチャの世界を表現できていない。テレワークやリモートアクセスのみが対象というように誤解を与える可能性がある。また実際にはアクセス要求に対して様々なインタラクションがある。例えばリスクベース認証では追加の要素を確認するなど。そういったインタラクションが表現できていない。
  • ゼロトラスト・アーキテクチャの世界を理解するには様々な用語の説明が必要となる。現状の用語は少なく、もっと拡充させる必要がある。
  • サブジェクトとオブジェクトは時として変化する。この全体を元にリソースの整理が必要となる。
  • 「図1：ゼロトラストのコア論理コンポーネント」ではID管理が直接PEPに向かっているが、本来であれば、その前段にエンティティ認証が入る。認証された結果ポリシー実行ポイントで制御がかかる。こういった仕組みが表現できていない。
  • ゼロトラスト・アーキテクチャを適用困難な従来システムの利用を継続しなければならない事情がある場合は、機能アップグレードするなどで、相互運用性を確保する努力を求めていることも必要と考える。
  • 適用（移行）プロセスにおいてはユーザーが困惑する可能性があるため、一時的に新旧システムを共存させるなどの移行期間などを設けるなど配慮も検討する必要がある。
  • ゼロトラスト・アーキテクチャの周辺、例えば人事管理システムやID管理、資産管理、調達管理といった各システムとゼロトラスト・アーキテクチャとの関連が必要と思われる。
  • ユーザーやアセットをゼロトラスト・アーキテクチャの原則に基づき管理することで、実際に管理している側の人々にも関係する内容として理解が得られる。
  • 用語含め、また全体を通して、言葉の使い方が粗く、見直しが必要である。書き手の中で定義を明確にして書き進めることを求める。
  • ゼロトラストはコンセプトとアイディアのコレクションであり、サイバーセキュリティプランということもあり、システムデザインやアーキテクチャリファレンスではないが、設計者、導入検討者では常に実装方法を意識して考える。「Forrester’sZeroTrusteXtended（ZTX）」のゼロトラスト適合技術エリア、1）Networksecurity,2）Datasecurity,3）Workloadsecurity,4）People/workforcesecurity,5）Devicesecurity,6）Visibilityandanalytics,7）Automationandorchestration、は参考にできると思う。
  • ゼロトラスト適用の事例を提示する。
  • ゼロトラストに関連する民間企業で期待されるDX化の目的例は「システムのオープン化」「全体的なテレワーク適用」「Proxyのクラウド利用」「テレワーク端末のセキュリティ強化」「クラウド利用に適したネットワーク環境の変更」といったものが挙げられる。
  • 「境界型セキュリティ」「ゼロトラスト・アーキテクチャ（以降、ZTA）」の用語が定義されているが、ここは参照文献の定義を参照するべきと考える。
  • 記載のソリューションについてはNISTSP800-207では「インテリジェントスイッチ」「ルータ」「Firewall」「特殊用途のゲートウェイ」「ソフトウェアエージェント」「エンドポイントFirewall」「SDP」「低レイヤーのネットワークスタック」「SDN」IBN」というに合わせた記載の検討を求める。
  • 「常時リスク診断・対処（CRSA）の導入に関する技術レポートについて」に関する自由討議において、主に以下の発言。
  • 通常状態をベンチマークとして作り続け、アラートを上げる、その保存先がASOであり、モデリングをASOで回していく。またASOレポジトリとダッシュボードのそれぞれの観点等を要約部分に記載した方が良いと感じた。
  • 米国CDMにて定義のないネットワークセキュリティの範疇が現在定義されていない。ここについて検討が必要。
  • スレットインテリジェンス等実際に起きている事象自体の深堀についても今後検討していく必要がある。
  • 海外の取り組みでは、CVSSでは判別つかなかった場合に、「システムコンプライアンス（公開されているCISベンチマークの活用等）」、「特権ID（最少特権モデルのモニタリング等）、パスワード（プレーンテキストによる保存等）」、「契約切れの証明書（証明書の失効ステータス等）」、「セキュアでないTLSやSSL（TLS1.3以外やSSL3.0以外）」という5つのトータルスコアで管理を行おうとしている。
  • 資料3についてはGSOC、政府情報システム管理データベース（ODB）など既存のシステムとの位置づけを整理する項目を追加すべきと考える。
  • 「2.1.常時リスク診断・対処（CRSA）の位置づけ」について、現在の書き方だとCRSAは、ゼロトラスト・アーキテクチャを実現するための1要素としてだけとらえられてしまうため、前段にCRSA自体の仕組みの説明が必要と考える。
  • 「（3）ネットワークで何が起こっているのか？どのようなシステム間のトラフィックパターンやメッセージが発生しているのかを把握する」は意図が伝わりづらいため、記載を改める必要がある。
  • 「2.1.常時リスク診断・対処（CRSA）の位置づけ」について「ゼロトラスト・アーキテクチャを構成している論理コンポーネント間の関係を示した概念図があるが、そもそもはゼロトラストがCDMを参照しうるという程度の関係であり、ゼロトラストに利用されるべくCDMが規定される、あるいはCDMの存在意義がゼロトラストに依拠している、といったものではないと考える。
  • 「図2-2ゼロトラスト・アーキテクチャの展開サイクル」は、ゼロトラストの実現方法なのでここでは不適切。第2回検討資料の「DADCにおける次世代型セキュリティアーキテクチャの検討について」のP10「常時診断を実現する日本ToBeモデル概要」の図をなどに差し替えるのはどうか。
  • 「常時リスク診断・対処（CRSA）は、資産管理ツールなどを活用して資産の把握を推進することを目的としている。（2.4.ゼロトラスト・アーキテクチャの適用方針との関係（1）資産の把握について）」だと、CRSAの目的が資産管理だけのように見えため、「常時リスク診断・対処（CRSA）は、資産管理ツールなどを活用し、資産を把握して、3.2.1に記載された（1）-（4）を実現することを目的としている」という記載に変えるのはどうか。
  • 「（2）資産の状態確認について」について、現在の記載では、CRSAとして実現すべきことが伝わりづらい。属性ベースの認証・認可はゼロトラストで実現することで、CRSAとしては、属性情報をゼロトラストに提供するという位置づけになると考えるため、そのことが伝わるように修正してはどうか。
  • 「3.1.アーキテクチャ全体」について、CDMの「ToolsandSensors」にあたる、ダッシュボードに取り込まれる一次情報（IT資産情報、認証ログ、ネットワークログ、アラート情報、データ監査ログ、クラウド情報）がどこにあたるのかが明確でない。政府内の参照データベースシステム」単体、もしくは「政府内の参照データベースシステム」「政府外の参照データベースシステム」「府省庁の政府情報システム」がそれにあたるのであれば、それとわかるように明確に記述、表現するべきと考える。
  • 「3.2ガバナンスレイヤー」について、ガバナンスレイヤーの記載についてはおおむね問題ないと考える。「3.2.2対象領域（1）端末とサーバ装置等の管理」について、今後、監視対象を通信回線装置、その他機器（複合機やIoT機器等）、クラウドに拡張することが必要であるため、そのことを明記すべきと考える。
  • 資産管理の把握の点について、脆弱性管理を追加し、機能要件だけでなく、実運用を見据え、運用が破綻しない運用要件の言及のご検討をお願いする。
  • 資産管理＋脆弱性管理が必要と判断される場合、米国のCISAの潮流なども鑑みて、「サイバー・ハイジーン」というキーワードを改めてご検討頂きたい。

以上