本サイトは、過去のIT総合戦略室の情報発信サイトです。2021年9月以降、原則として更新を停止します。(一部ページ除く)
現在のデジタル政策に関するデジタル庁の公式サイトはこちらをご覧ください。

ディスカッションペーパーへの意見

掲載日

ここでは以下の15件についての意見を募集しています。


注意: 投稿後にコメントの確認を行いますので、コメント一覧に反映されるまで数日から数週間かかる場合があります。

コメント

はじめてコメントします。
民間の小さなセキュリティ技術の研究開発会社を経営している、
保倉 豊(やすくら ゆたか)と申します。

たまたま情報関係の調べ物をしている最中に、
政府CIOサイトの、CIO補佐官様たちのディスカッションペーパーを拝読しました。

https://cio.go.jp/dp
パブリック・クラウドを利用した情報システムにおける計画・構築時の基本的な考え方
情報システムのパブリック・クラウドへの移行方式について

少し古いもので、検討が途中で終わっている感もありますが、
今日の課題を先回りして、その原因等の基本的性質を分かりやすく表現していて、
素晴らしいなと感じました。

合わせて、
「デジタル・ガバメント推進標準ガイドライン」
説明会資料(2019年3月)
初版(2019年3月15日)
も、拝読させていただきました。

現状のサービスをフルに利活用する際の手引きとして、
有用と感じました。もっと、広く知っていただけると良いですね。

また、
接触確認アプリに関する仕様書等の公表
令和2年5月26日
https://cio.go.jp/node/2613

も、拝読させていただきました。

現行の個情法、行個法観点からの課題整理、
これもわかりやすく良い資料と感じました。

他方、すでに皆さまは近未来の社会システムや、
プラットフォームのイメージを持っていらっしゃると思います。
そうしたイメージの共有も行ってはいかがでしょうか。
皆様のポジションは、社会をリード役割も担っていると考えます。
その意味では、
もう少し先の姿にも触れていても良いように感じました。

その際、果断な対処をしなければならないITシステムの世界を踏まえると、
既公開の方針や業界の相場観等が、
必要以上の足かせにならないよう勇気をもって新たなデザインや、
方向性を示していただいて良いと感じます。

その一石が、日本発のグローバルスタンダードを生み出す可能性は十分あると、
考えております。
お忙しい皆さまに、勝手なコメントをしてしまい申し訳ありません。
しかし、皆様の今日の役割は、日本や世界の未来に対し、
非常に大きなものだと考えております。

個人的には、今後の情報システムは、
自己完結可能でありながら、対象となる情報資産オナーの、
自己情報コントロール権の下、チーム化可能な情報環境構築の時代になる。
と、考えております。

今後も皆さまの勇気あるご活躍を、
期待しております。

2020年06月12日
東京都渋谷区笹塚在住、
ITセキュリティ業界小規模企業経営者、
保倉 豊より。

サービス利用が広範囲にわたる現在、その提供形態や業務内容に応じた体制を取ることは大変良い試みだと考えます。
特にNW監視系やセキュリティソリューションは管理を海外のSaasで実施していることが多く、現実的かと考えます。
半面、Iaas、Paasについては多くが組織内のオンプレシステムの移行によってその形態をとっていたり、公開サーバーとしてSaasを提供する環境として使われており、本質的になんらかのデータを持っていることが多いと考えますので慎重な対応が必要かと存じ上げます。特に、機微な個人情報、決済情報を持つものに関しては、海外設置のインフラを利用することは避けるべきではないかと考えます。

封書を郵送する場合、届いたかどうかを確認したり本人に渡したかどうかを確認したりするための特定記録や簡易書留等使い分けたりします。これは郵送のコストに影響をあたえるのですが、問い合わせに対応するために自治体にとっては必要な使い分けです。オンラインにおいてもこのような使い分けができるのかどうか、送信者が確認する方法等より深く議論いただけるとありがたいです。

相手の属性によって通知文の表現を変えられるようになることや紙面の量を気にしなくて良いのはデジタル化のメリットだと考えます。やさしいにほんごやルビ入り、他言語対応など議論されるとありがたいです。

拝読させていただきました。今後のDXや働き方改革の下地を作るという意味で、ゼロトラストアーキテクチャへの移行ロードマップを示していただいたことは大変前向きにとらえています。ありがとうございます。

以下コメントさせていただきます。

1. Pure Zero Trustを最終的に実現するためには、ステップとしてHybrid Zero Trustとして境界型に残る部分の識別を挙げられていますが、Hybrid状態の時に、やはり境界型に残る部分もマイクロセグメント化を推進して、Trustする面積を減らしていくことは必要だと考えます。

2. 同時に、マイクロセグメント化された多くの境界型領域を、ゼロトラスト化された部分と並行して運用することで増加する運用コスト増加の懸念もあります。

3. 最終的にPure ZeroTrustへの移行のためカルチャーチェンジが必要となり、その方針を示す必要があると考えています。※カルチャーチェンジ(クラウドネイティブ化に対応したOA環境の利用、日本の古い伝統的な印刷やハンコ、承認方法の変化、OT領域では製造や開発スタイルの革新など)には、DXを見据えた人の意識の変化、法的ガイドラインの整備などを具体的な)はZeroTrust環境において生産性を維持・向上するためには必須と考えます。

4. AAAの統合管理については、3で述べたような生産性の維持、向上を同時に満たす必要があり、Zero Touchなどイノベーションフレンドリーな状態を保つという要件も必要になると考えます。

乱文失礼しました。

政府情報システムにおけるクラウド設置場所等に関する考え方について、
サービスを軸に纏めている印象を受けるが、データを軸に纏めてはどうか。
地理的な検討を行う際、検討すべきはデータの保管・処理・転送をする場所をどこにするか、に尽きると考える。データの保管、処理、及び保管データを守る暗号化や認証のシステムをどこに置くか、といった観点で纏めてはどうか。
IaaS/PaaSやSaaSの区別は不要ではないか。

皆様、

F5の小野寺です。
いつもお世話になっております。

”AIシステムにおけるデータ利用の特性と取扱い上の留意点”を拝読しましたので、コメントさせていただきます。

P10の5.精度検証方法にConfusion Matrixについて記載されてますが、更に、PrecisionとRecallやPR曲線、ROC曲線、AUCについてもモデル評価の材料として記載するとより実用的なものになるかと思います。

また、冒頭に、説明可能なAIとして、線形回帰、ロジスティック回帰、ディシジョンツリーが例として記載されておりますが、これらを実施する際には、オーバーフィッティング(過学習)の防止も重要な論点になると考えております。

既にご存知の内容かと思いますが、モデル評価と過学習についての資料を以下URLにアップロードしましたので、ご参考になれば幸甚です。
https://15.gigafile.nu/0722-b3a9e2c45a216edcf2771e19675add7b5
ダウンロード用パスワードは、別送します。

なお、AIでは、多重共線性については議論されることは少ないかもしれませんが、決定係数が著しく高くなる可能性を考慮しますとこちらも重要な論点になるかと考えております。

なにとぞよろしくお願い申しあげます。

F5ネットワークスジャパン合同会社 
公共・社会インフラ営業本部
小野寺 誠(Makoto Onodera)
Mobile: 080-9506-0216
Email: [email protected]

先ほどお送りしたリンクからのダウンロードパスワードですが、f5AIです。

なお本文は筆者個人に属しており所属先の公式見解を示すものではありません。

政府情報システムにおけるゼロトラスト適用に向けた考え方についてのコメント

ディスカッションペーパー全体的でクラウド化○○等の記述が散見されますが、クラウド利用は方法論であって、クラウドありきで話を進めることは拙速だと考えます。しかしながらクラウド利用によって期待できる低コスト化、標準化、ガバナンス等の推進等合理的記述・説明を記載することで、国民/政府職員に理解を得ることが期待できるかと思います。

P3 “USB~"の下りについては、ソーシャルエンジニアリングであるためゼロトラストであっても同様に脅威(なりすまし等)が存在します。したがってネットワークを経由するサイバー攻撃とソーシャルエンジニアリングは分けて考える必要があると考えます。

P3 "`最も重要なセキュリティ対策である~"`の下りも数字の根拠がなくミスリードであると考えます。数万ホストに対するペネトレーションテストの実務(ペネトレーションテスト・セキュリティ診断およびセキュリティコンサルティングの実務経験での観測)における傾向としては、認証を起点とし攻略されるセキュリティ課題が7−8割であり残りは脆弱性や設定等となっています。
多要素認証には様々な実装があるためめ、NIST800-63のAALレベルを参照もしくは同等のガイドラインを策定も併せてすべきだと考えます。

ゼロトラストの概念の実現に向けての提言
1. 認証/認可プロトコルの標準化/ガイドラインの策定 ~ 電子政府推奨の認証認可プロトコルの安全性を評価・監視し、暗号技術の適切な実装法・運用法 (CRYPTRECの認証/認可プロジェクト版)
2. 規格/実装のオープンソース化
3. スマートカード認証を利用した既存システムの保護およびZERO TRUSTを実現する基板テクノロジーの規格化/開発および

1について
ゼロトラストに限らず、オンラインシステムはセキュアな認証(適切な運用を含め)によって情報セキュリティにおける可用性・完全性・機密性が担保可能となります。従ってセキュアな認証を定義し利用する必要があります。
現在政府機関等の対策基準策定のためのガイドライン P171では認証プロトコルにかかる技術規定、利用しなければいけない条件(どういったシステムにおいてどのような認証規格を利用すべきか等のマニュアル等もない)は具体的に明記されておらず、省庁にて統一したセキュリティガバナンスは期待できません。また認可にかかるプロトコル・技術規格・ガイドラインについては記述さえありません。今後情報セキュリティレベルを高める・確保するためには日本においてはNIST800-73, NIST800-63B、欧米のeID/eIDAS規格を参考とし国家公務員ICカードのオープンな規格化、民間への解放・利用促進の必要があると考えます。認可プロトコルにつては現状規格化され実利用されているプロトコルはXACMLしかなく、ルールのメンテナンス、スケーラビリティ等に難があります。NISTでは次世代アクセスコントロール規格(https://csrc.nist.gov/projects/policy-machine/ )を公開しており、ベンダーに採用を呼びかけているので、日本でも参考としつつ日本版NIST組織が規格化を行い、規格に準拠したサービスの利用を推進する等が考えられます。なおZero Trust, TNC, NGAC等で参照されるポリシー判定/エンジン(PDP/PEP)はスケーラビリティに難があるため、その課題を解決する認可プロトコルの開発が求められます。

2について
各省庁で同一の機能を有するシステム/機能を個別実装することで独自アプリケーションが乱立しており、省庁間で情報・ソフトウェア知財は共有されておらずを再利用がされておらず、無駄が生じています。税金で開発したソフトウェアは公共財産でもあるためセキュリティにかかる実装ソフトウェア等をオープンソースとして公開し広く民間にも利用可能とし、既存のオープンソースにコントリビューションを行い開発にかかる負担を低減しつつ持続可能なソフトウェア提供を行う等の施策が必要と考えられます。具体的には欧州主要国のスマートカードが対応されているOpenSC(Windows, Mac, Linuxに対応)がマイナンバーカードも利用可能とするようなコントリビューションを行うことが期待されます。
※残念ながら個別に開発されたソフトウェアのメンテナンス品質はベンダのケーパビリティ次第であり環境の変化に追従できないソフトウェアは最終的には利用者にコスト・セキュリティ的な問題が転嫁されます。

3について
既存のシステムのZERO TRUST化はアプリケーションレイヤーの実装レベルで対応しなければ実現は不可能です。既存のシステムの保護テクノロジー/Zero Trustの認証基板としてスマートカード認証+RFC5755: Attribute Certificate Profile for Authorizationを利用することでTLSレイヤーでの認証/認可を行い、不特定多数からの攻撃やAPT攻撃において行われるラテラル・ムーブメント等の攻撃を防ぐ対策手法があります。
なお米国連邦政府ではDHS, CIA, NSA, DoD等様々な組織においてスマートカード認証(PIV, CAC)を利用した認証を既に運用されています。

Re:はじめてコメントします。
渋谷区笹塚在住保倉豊 様
ディスカッションペーパーをご覧いただきまして、有難うございます。本文書は政府情報システムに対しての検討をしたものながら、一般の方へのご参考にもなりますと幸いでございます。今後、より官民による連携が必要とされますため、引き続きご支援、ご協力いただけますようお願い申し上げます。

Re:サービス利用が広範囲にわたる現在
川田 康友 様
ご意見ありがとうございます。「政府情報システムにおけるクラウド設置場所等に関する考え方」では、クラウドの設置場所における利用者データの可用性、業務サービスの継続性、データ保護を各々の観点で整理しており、個人情報、決済情報についても、設置場所のみならずこれらの観点から評価を行うことが必要と考えています。

Re:今後のDXや働き方改革の下地を作るという意味で
鈴木克明 様
ご意見ありがとうございます。1.と2.については我々の問題意識も同様であり、「政府情報システムにおけるゼロトラスト適用に向けた考え方」では「システムのクラウド化徹底と旧ネットワークセキュリティ依存の最小化」と「システムの積極的なクラウド化」によって対応すべきではないかと提言しています。3.と4.についてもご指摘のように、より広範・包括的な取り組みが必要と考えており、本考え方では、その前段部分にとどまっていますが、今後、具体化が必要な領域と考えています。

Re:皆様、
F5ネットワークスジャパン合同会社 小野寺誠 様
「AIシステムにおけるデータ利用の特性と取扱い上の留意点」へのコメントありがとうございます。
本ペーパーは、学習モデルの品質、保証および権利関係に影響を与える要素とその関係について考察を試みています。ご指摘のとおり評価指標も様々にあり、またアルゴリズム、分野によってはよりコンテキストに依存した指標を用いる場合もあると思います。本ペーパーでは昨今取り上げられる事の多いCV、NLPだけでなく、深層学習、機械学習全般に共通した先に述べた3つの考慮すべき課題について検討を行いました。次回ペーパーをアップデートする際は、頂いた評価方法についても検討したいと思います。
マルチ・コリニアリティは、行政が扱うデータ、特に統計において直面しやすい問題である一方で機械学習ではその目的の違いから注意を必要とする場合は限られるかもしれません。次回ペーパーをアップデートする際に考慮すべき事項として検討したいと思います。

Re:政府情報システムにおけるクラウド設置場所等に関する考
山口弘行 様
ご意見ありがとうございます。「政府情報システムにおけるクラウド設置場所等に関する考え方」では利用者データの可用性、業務サービスの継続性、データ保護の各々の観点で整理を行っており、利用者が具体的なクラウドサービスの評価を行う際の実用性からIaaS/PaaS、SaaS等での場合分けを行っています。一方でIaaS/PaaSの区別に意味がなくなりつつあること、SaaSも含めて境界が曖昧になっていることへの問題意識も強く、XaaSでの場合分けも適宜、見直しを検討していきます。

Re:なお本文は筆者個人に属しており所属先の公式見解を示す
TORU TOMITA 様
認証については「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」にてとりまとめておりますが、ご指摘いただいたような認可プロトコル等の具体的なソリューションについては、今後の課題としております。また、ゼロトラストに向けての取組は政府内でも議論が進んでおり、利便性と両立したセキュリティの在り方についても議論を進めてまいります。

Re:封書を郵送する場合
森 大樹 様
コメントを頂きありがとうございます。法令等により通知が到達したかどうか確認しなければならないものについては、現行の運用を踏まえつつ適切な情報通信技術の利用を検討いたします。

Re:相手の属性によって通知文の表現を変えられるようになる
森 大樹 様
コメントを頂きありがとうございます。条件に応じた表現のカスタマイズや利用者の特性に配慮したコミュニケーション手法の採用は情報通信技術の特性が発揮できる分野と考えますので検討の参考にさせていただきます。

Re:○自治体パーソナルデータの利用
松下邦彦 様
パーソナルデータを含む機微な情報の流通については、セキュリティを確保しつつ利用者のユーザビリティに配慮した検討を行います。
行政機関から取得したデータについて、個人での利用や他機関への提出等が想定されますが、本検討ではまず前者に重点を置き取り組みます。後者については、原本性の確保やリスクの少ない通信経路等、より慎重な検討が必要と考えております。

「政府情報システムにおけるゼロトラスト適用に向けた考え方」のディスカッションぺーパーを拝読させて頂きました。
昨今、ゼロトラストがバズワードとなり多くのベンダーがゼロトラストを謳ってくるようになりました。
本件で参考にされている、Google、PaloAlto、MicrosoftなどSASEと呼ばれる分野のベンダーさんもその1つです。
ですが、ゼロトラストを提唱したForrester社が9月24日に発表した2020年のゼロトラストレポートで上位にいるのはIllumioやAppgateなどSASEではないゼロトラストベンダーとなっております。
PaloAltoはぎりぎりLeader位置ですが、GoogleやMicrosoftはLeaderでもありません。

彼らはクラウドサービス提供のため、どうしてもクラウドを中心とした概念となりますが、
実際にはオンプレ環境も残り続けます。
無駄にクラウドに移行すると、内部から内部の通信すら全て一旦インターネットに出ていかなければならないというネットワーク帯域などを無駄に消費する通信フローとなり、また、Web経由とすることでのプロトコル制限などシステムによっては対応できない環境となってしまいます。

クラウド化も一つの要素ではありますが、全てでは無いと認識しております。
そのため、SASEのマーケティング用語としてのゼロトラストだけではなく、ローカル環境などにも視点を置いたSDPなどのゼロトラストも是非ご覧になっていただければと存じます。

○自治体パーソナルデータの利用
マイデータの本命はパーソナルデータと思われます。
残念ながら自治体セキュリティポリシーや三層分離の原則によってパーソナルデータをインターネット側に送出することが困難です。
管見の範囲では、会津若松市が健康データを住民のオプトインに基づいて母子健康手帳アプリに連携させています。
特別定額給付金のオンライン申請も、自治体のパーソナルデータを利用できればスムーズな申請が実現できました。
自治体のパーソナルデータを利用・活用できる環境が実現されることが強く望まれます。

○eシール
以前マイデータの検討会に出席したとき、あるCIO補佐官は「都度サイトから最新データをダウンロードする方式もある」とお話しされていましたが、報告書では、マイデータは基本的に何らかのメッセージ手段上の添付ファイルで流通します。
原本性を確保する手段として、将来はeシールも採用できるのではないかと考えます。

Thales DIS CPLジャパン前田と申します。

「政府情報システムにおけるゼロトラスト適用に向けた考え方」を拝読し、その中の4 具体的な取り組みの頭で「4.1 パブリック・クラウド利用可能システムと利用不可システムの分離」と、クラウドシフトの方向性について、わかりやすい明記と感じました。

このクラウドシフトにおいて、最大限クラウドのメリットを享受しつつ、セキュリティを担保するモデルとして、「暗号化」を選択されるケースでは「Bring Your Own Key:BYOK」があります。
政府情報システムにおけるクラウド サービスの利用に係る基本方針に「データの暗号化に使用する鍵については、クラウドサー ビス提供者側よりも利用者側で管理することが望ましく、選択可能な場 合は利用者側で鍵管理が可能な暗号機能を選ぶものとする」と記載があり、これがまさしくBYOKで、データコントロールを顧客自身が制御できるようにすることで、「インフラストラクチャ」としてのクラウドについて、より自由な選択・利用を後押しいたします。
https://cio.go.jp/sites/default/files/uploads/documents/cloud_%20policy.pdf

このBYOKモデルには、暗号鍵をクラウドベンダーのインフラ環境にアップロードするタイプもあります。この場合、ユーザー側が暗号鍵のコントロールを保持しているとは断定しづらいという側面があり、より強固なセキュリティモデルとして、
*クラウドベンダー環境とは別環境に暗号鍵を管理するBYOKモデル
*ユーザー自身が暗号ソフトウェア・暗号鍵を用意する「Bring Your Own Encryption:BYOE」というセキュリティモデル
があり、暗号モデュールを基点としたこのようなセキュリティモデルが、現在も各国政府基盤にて採用されており、日本の行政サービスにおいてもクラウドセキュリティに「暗号化」を選択される場合、他国同様に推奨されるセキュリティモデルと考えております。

お世話になります。ワードリンクを開くと、({REF_Ref60751828¥r¥h})などが出てくるのですが、PCの設定でPDFのように表示できるのでしょうか。

「自治体からの通知物デジタル化と、それにより加速する民間サービスへの連携」において情報アクセシビリティが触れられていません。学習障害や視覚障害など、普通のものが読めない人は全人口の10パーセントぐらいでしょうか。デジタル庁は、情報アクセシビリティにきちんと取り組んでいただきたいと思います。

いつも勉強になります。ありがとうございます。
希望・IT総合戦略室のメールマガジン発行を希望します。

意見
・p5ベース・レジストリについて、土地、建物、資格等に関するデータは、国家資格、公的職務(例えばCIO補佐官)については納得です。個人、法人に関するデータは、具体的内容が必要だと思います。
・p5 町字/町字レベルについて、用語自体がどういう意味なのか分かりませんでした。意味で市区町村の下層とあるのに、町を含めるという意味でしょうか。○○市○○町などの意味なのだろうと思いますが、少し分かりづらい用語だと思います。私なら、市区町村/町字レベルとします。
・p5 番地号/番地号レベルについて、地番や街区符号(2番など)、住居番号(3号など)が番地号。番地と番号のことなのか、地番(所在)と番地(住居表示)は違うので地番号がしっくりくるような気がします。それとも番地に統一していこうという考え方なのかなと思いました。
・p5 地番は土地の特定、住居表示は名前の通り住居を表示するため(建物を建てなくても、建てた場合に表示できるようにするため。)。同じ場所を示す2種類の方法が存在することになる、というよりは、そのように定めたのは国なので、存在することにした、という表現にした方が良いのかなと思います。
・p8 なぜ、不利益に対する心配がなくなったのか、私には分かりませんでした。
・p20 住所と所在地は、一元的に管理される必要があるのかな、と思いました。土地の住所が所在地、建物の所在地が住所であるという理解ではないのだと思います。
・p20 不動産登記法に基づく、土地の登記における地番に変化が生じる登記(新たに生じた土地等の表題登記、土地の滅失、分筆、合筆等)の業務は個々の登記所が実施するが、広く一般に情報公開はされない。よって情報・資料の集約に労力がかかる、に関しては、現在でも国税庁、市区町村との連携はあるので、広く一般に情報公開されていないからといって、行政内で公開出来ない理由にはならないと思います。
p21 登記所は国(法務省)の機関なので、ここでいう国とはデジタル庁、内閣府内閣官房 情報通信技術(IT)総合戦略室のことだと思います。
・p22 ベース・レジストリとしての住所・所在地マスターデータ群の入力先がもし不動産登記(土地)表題部だけなら、省庁内の行政内部で完結するのではないかなと思います。市区町村が入るからややこしくなっていて、そこを一元管理するための住所・所在地マスターデータ群だと思っていました。
・p25 地目・地積は必要ない、ということは住所と所在地の特定に絞っているということなのかなと思います。農地や宅地の面積は他の省庁で統計を取るということでしょうか。住居を買うために土地を探している人がいるとして、宅地割合や農地割合を知りたい人もいるのかなと思いました。
・p26 整備レベル3の整備内容で、住所・所在地としての表示を網羅出来るのでしょうか。町字+住居表示の街区・住居番号+地番がないと所在地としての表示を網羅出来ないのではないかと思います。
・p26 名称が何を指すのか、分かりませんでした。
・p27 町または大字から地番という住所もあるのではないかと思います。
・p28 定義は存在しない、統一されておらず、データ間流通を難しくしている、というのは、省庁の行政内部の問題なので、定義をしていない、統一していない、そのためデータ間流通が難しい、の表現になると思います。
・p36 住居表示住所と地番住所は別で管理するということでしょうか。データセットを別にしてもデータ群として一元管理出来るということなんでしょうか。
・p37 地番(所在地)と住居表示は、結局別のマスターデータでいいのでしょうか。
・p39 住居番号は家屋番号のことなのでしょうか。
・p49 ほとんど数字が繋がらない場合もあるのだなと初めて知りました。
・p51 最小と最小で合っているのでしょうか?
・p55 海外でポリゴン情報を使用する場面は、どのような場面があるのでしょうか。

p5 番地号/番地号レベルについて、地番や街区符号(2番など)、住居番号(3号など)が番地号。番地と番号のことなのか、地番(所在)と番地(住居表示)は違うので分かりませんでした。

p8 なぜ、不利益に対する心配がなくなったのか分かりませんでした。

p9本社住所に関して、登記されていない本社住所を許容してしまうと、実在性が担保されないのではないでしょうか(会社法976条)。

p20 住所と所在地は、一元的に管理される必要があるのかな、と思いました。

p26 名称が何を指すのか、分かりませんでした。

p27 町または大字から地番という住所もあるのではないかと思います。

p39 住居番号は家屋番号のことなのでしょうか。

p51 最小と最小で合っているのでしょうか?

p55 海外でポリゴン情報を使用する場面は、どのような場面があるのでしょうか。

鏡「本ディスカッションペーパーは、政府 CIO 補佐官等の有識者による検討内容を取りまとめたもので、論点整理、意見・市場動向の情報収集を通じて、オープンで活発な議論を喚起し、結果として議論の練度の向上を目的としています。そのため、ディスカッションペーパーの内容や意見は、掲載時期の検討内容であり、執筆者個人に属しており、内閣官房 情報通信技術(IT)総合戦略室、政府の公式見解を示すものではありません。」について、ディスカッションをオープンにした情報ではなく、ディスカッションの結果を示した情報なので、実質はベース・レジストリとしての住所・所在地マスターデータ整備についての検討報告書だと思います。

「オープンで活発な議論」について、シビックテック関係者には厳しいと思います。
https://note.com/shi_sunao/n/n11aabbd5b800

「政府情報システムにおけるゼロトラスト適用に向けた考え方」を拝見させていただいた中、例としてAWSやGoogle等クラウド事業者を上げてご説明されておりましたので、外資系サービス利用についてコメントさせていただきます。
今回のような活発なクラウドサービス利用において、ナショナルセキュリティリスク=安全保障上のリスクをどう回避するかが重要と考えます。
海外、主に欧米と日本を比べた場合、海外でのサイバーセキュリティはある意味国策でありその対策も自国のクラウドサービスベンダーのサービスで対応できますが、日本の場合国産サービスは限定的で、もちろんAWS、MS Azure、Googleなどは他国サービスです。
このような海外企業のクラウドサービスを使う場合、当然データ保存先も海外企業下で海外政府の管轄下にありますので、その保存データが当該政府に非公開であり続ける担保をどうとっていくか、が重要になります。

クラウドサービス利用において外資系サービスを外すことも一案ではありますが、おそらく現実的ではない為、このような海外サービスありきでどのようなセキュリティ対策を講じるか、それを考慮に入れる必要があります。

今回具体的な対策には入っていなかった、「クラウド上保存データの暗号化」では、クラウドベンダーが発信するBYOK(Bring Your Own Key)の考え方の更に上位、より強固なセキュリティコンセプトとしてBYOE(Bring Your Own Encryption)があり、この考え方は今後のゼロトラストセキュリティを考える上で非常に有効と考えております。

政府情報システムにおけるクラウド設置場所等に関する考え方を拝見し、その中
3.1 IaaS/PaaS の検討
1)利用者データの処理や保管を行うサービス(利用者データ取扱サービス)
 (4)にて、クラウドHSM(耐タンパー装置)があればOKである記載がありましたのでご参考までにコメントいたします。
クラウドセキュリティアライアンス、通称CSAでは、EKM-04にて、鍵は(当該クラウド事業者の)クラウド内に保管するのではなく、クラウドの利用者または信頼できる鍵管理事業者が保管しなければならない。鍵の管理と鍵の使用は、異なる責務として分離されなければならない、
と推奨しております。
HSMは非常に強力なセキュリティソリューションではありますが、管理者アクセスについても検討が必要である為、データ保存先のクラウド環境とは別環境での鍵管理が重要と考えます。

6/4に公開された「行政サービス・制度データモデル(β版)」(標準ガイドライン群 ID:1016-X)で言及されている、データ定義(個人用)ですが、現状公開している「項目名」「説明」に加えて、『プロパティ(「キー」と言われる場合もある)』を定義していただきたいです。

理由としては、オープンデータの形式が統一されていくのは前提として、プロパティが統一されていないと、情報がストックされないからです。

必要になった経緯は、Code for Japanで対貧困プロジェクトという、公共制度を検索できるサイトを作成する際に、CPSVに辿り着き、この問題を抱えております 詳細:https://scrapbox.io/c4j/proj-poverty_2021-08-11_MTG#6113a34fbb24d4000060...

ベース・レジストリとしての 住所・所在地マスターデータ整備について
で訂正してほしいところ

https://cio.go.jp/sites/default/files/uploads/documents/dp2021_03.pdf

過去の議論したデータを消すこと自体が間違っている 議論の経過がわからなくなるので良くない。

秘密にしなければいけないもの以外全て公開するという方針には反している。それがなぜ悪いのかわかっていないようなので理解した上で方針を変更してほしい。

https://imi.go.jp/ns/core/Core242.html#ic:%E9%A7%90%E8%BB%8A%E5%A0%B4%E5...

物事を整理するときに継承を使用しないでください。
上記の共通言語基盤は下位の階層になればなるほど、事前条件を強めているのでリスコフの置換原則に反しています。

4.2 ベース・レジストリとしての要件

間違っている方針

住所・所在地マスターデータは、継承性のある固有の ID を持つ。

固有のIDに意味をもたせるな。IDはランダムであり、県境が変わったときに振り直されるのはだめ。

IDは識別のみに使う方針にするべき。
派生型で条件が強まる形式になっているのに継承を使って表現している。この提案をしたのが誰か教えていただきたい。

図 4-1・所在地マスターデータ関連データ等の関係
は以下の方式が正しい。

https://github.com/koyakei/locationAdministrator

6.1 番地号レベル住所・所在地マスターの ID 体系・データ項目の検討

地番も住所表示も重複した識別子を持たない同じデータセットで管理するべき。
別にするべきなのは土地建物と住所の結びつきである。
地番と住所が全く違う建物に住んでいる住人がいた場合、居住している建物の地番は建物の登記情報につける。そして、登記情報に送達先としてつかえる住所を登録し、個人情報に居住先の区画IDを紐付ける。

6.2 番地号レベル住所・所在地マスターデータのデータフォーマット案

すべてのデータにはデータの更新日時が必要

地番マスターデータ フォーマット案
地番IDをキーにするので、地番のない無番地に対応しないようだがなにか理由があるのか?
自衛隊駐屯地など地番がない無番地に人が住んでいる。

住居表示実施新旧対照データの構造

表示側はこれでもいいが、記録する方はイベントソーシングで表現するべき。

https://cio.go.jp/sites/default/files/uploads/documents/1018_code_guideb...
の3.1.4 には

頻繁にコードの追加や変更が行われるような場合、固定的な設計になる有
意コードでは拡張が難しいため、無意コードの採用を推奨します。

と書かれているが、一度でも識別子が変更される可能性がある場合は無意コードを採用するべきである。変更コストがかかり、変更に失敗すると、過去の記録が不整合になり、行政データとして許されない問題であるからだ。

一度でも識別子が変更される可能性がない場合は原則無意コードとするのが正しい。

そして、これに反する事例が、

ベース・レジストリとしての住所・所在地マスターデータ整備について
9.2 町字の異動に対するレコード更新ポリシー

旧レコードを削除(または廃止状態化-廃止日に有効値を収録)し、町
字 ID を新たに付番して新レコードを作成するケース:
‐ 全国地方公共団体コード(市区町村コード)に変更が生じる事案(市
町村合併、政令指定都市移行、市制施行、他の都道府県への編入、な
ど)- 但し、同一コードが重複しない等、異動前の町字 ID をそのま
ま継承できるケースは継承することを妨げない

住所・所在地マスターデータは、継承性のある固有の ID を持つ。

に存在している。

方針には頻繁かどうかなど上界と下界がある定義を用いるべきではない。
なぜなら、程度問題には合意が必要である。程度問題の合意を国民全体とするのは難しい。

一方、上界と下界がない定義は合意がかんたんである。
上界と下界がない定義の例
お金を気にして病院に行けないような生活しなければいけない人が少ないほうがいい。
単一の識別子によって、識別子が表す対象を全て検索結果として拾える保証ができるシステムにするべき

頻繁とはどの程度なのかを合意してから、実現可能性を探って妥協するよりも、
目標については完全に合意があるところから、実現可能性を探って妥協するほうが簡単である。

そもそも方針とは、上界と下界がない努力目標である。
識別子一つとっても、紙ベースの項目の番号にも応用できることであり、デジタル化に限定されないデータ整理の方針である。
デジタル化に限定されない影響範囲がある方針についてより上位の文書に書き、デジタル化に限定されるものについては下位の文書に書くべき。

以下の方針には方針の作り方や方針の方針や方針の定義を書くべきである。
https://cio.go.jp/sites/default/files/uploads/documents/dp2021_05.pdf

デジタル化するにあたって明らかになった、デジタル化していないデータに対して適用するべき方針について書かれていない点が デジタル社会実現のためのアーキテクチャ設計 の間違いである。早急に訂正してほしい。

コメントを追加