ガバメンタル・クラウドの提言
デジタル社会における行政のデータは、その性質上、国外や民間に渡さないようにお願いしたい。 そのために、行政機関に物理的に閉じたクラウドを構築し、クラウドは行政機関内で内製するべきです。 自衛隊と同じように、国あるいは地方自治体内で、技術者を育て、クラウドシステム... » 詳しく
- 5ポイント
- 9票
- 23コメント
郷田史介さんのマイページ
投稿したアイデア 2
デジタル社会実現のため、まず強固な土台作りを
統計によると、情報システムへの脅威の侵入経路は９９％が電子メールです。 電子メールの誕生当時には、犯罪被害を誘発するような脅威を全く想定していませんでした。 現在に至っても電子メールの基本は誕生当時と変わらず、情報システムにおいては最も脆弱なシステムです。 近... » 詳しく
- 6ポイント
- 6票
- 6コメント
お気に入りアイデア 0
まだお気に入りがありません。
投稿したコメント 16
デジタル社会実現のため、まず強固な土台作りを
#003 DMARCを降る実装しないまでも、最低限SPFには対応していただきたいですね。
DMARCの機能は、SPFとDKIMの２つの仕組みを使って、はじめて機能します。
DMARCの機能は、２つです。
① １つは、SPFあるいはDKIMの認証に失敗したメールの扱いをどうするか。
どうするかとう言うのは、「受け取る」か、「隔離する」か、「拒否する」か。
② ２つ目は、SPFあるいはDKIMの認証に失敗したメールについて、ドメインの所有者にレポートを返すこと。
レポートというのは、認証されないメールが送られてきた、「送信元のipアドレス」や「送信メールアドレス」などです。
なので、SPF・DKIM・DMARCには導入に「順序」があります。
SPFとDKIMをまず機能させなければ、DMARCは機能できないということになります。
現在のように、詐称された電子メールが氾濫しているインターネット上で、DMARCの②の機能を有効にした場合、無数のレポートメールが送りつけられることになります。
そして、DMARCに未対応のメールサーバーもあります。
つづく
#003 深津さん
go.jp domainにおける普及率は３％以下なんですね。
＞ 官民挙げて推進し、DMARCを導入している事業者・個人で信頼できるコミュニティを立上げ、仲間を増やす方向性がよいと思いますが、
おっしゃるとおりだと思います。
ガバメンタル・クラウドの提言
#022 MOSMOSさん
＞コメント１２の「採算を考えなくて良い」には同意しかねます。
ごもっともな、ご意見だと思います。
デジタル庁のメンバーに、終身雇用という形態が良いかどうかも合わせて、じっくりと検討する必要があると思います。
私は、終身雇用をベースとするのが良いと思います。
そして国をリードしていく技術者に育て上げる。
給与は民間に比べて低く抑えるのが良い。
そのかわり、技術を取得するための、最大の「自由」と「権限」を与える。
待遇は、まず自衛隊を参考にしてみる。
天下りなどの過去の轍（てつ）を踏まないようにする必要もあるのでしょう。
技術者として民間に移れば、古巣との関わりを制限するような制度が必要でしょう。
IT技術と「心中（しんじゅう）」する覚悟のある「公僕」を中心に、日本国のシステムが展開される。
デジタル庁の職員は、その技術力で、たとえ民間に下っても食いっぱぐれることはない。
誤解を恐れず、妥協のない正論を書かせていただきましたが、あくまでも提言です。
妥協は、制度や組織を立ち上げ、実行する方々にやっていただければOKだと思います。
#019 つづき
オープンソースは、その名の通りソース（設計図）が公開されています。
不具合があれば、私たちの使用環境に合わせて発展させればいい。
そして、オープンソースの精神にのっとって、私たちの手で発展させたものを公開して、世界に恩返しをすればいいんです。
※ソフトウエアを公開するのであって、データを公開するわけではありません。
オープンソース・ライセンスは、平和憲法を持つ私たちの日本に、とても似合うライセンスだと思いますし、
今みたいな時代だからこそ、もう一度その価値を見直してみるべきだと思います。
#019 たしかに、楽天とAmazon では大きな差を感じます。
世界企業と、日本周辺で活動している企業では、投資の規模もスタッフのレベルも違ってくるでしょう。
これだけの規模の差を埋め合わせながら、同じ商品と価格で勝負しているわけですから、楽天は健闘していると言ってあげてもいいかな。
ご存知かもしれませんが、Amazon のAWSや、google 、Facebook のシステムは、基本的にオープンソースです。
だから、私たちは、彼らと同じ技術を使ってクラウドを構築することができます。
ソフトウエアにかかる費用はゼロです。
勝手に宣言してしまいますが、NTTは、問題なく作ることができます。
※私はNTTと何の関係もありません。経営スタンスも知りません。
私もGAFAMに感謝しています。
彼らはオープンソース•ソフトウエアに多大なる貢献をしています。
※Appleはわかりません。
オープンソースの哲学は、「共助」です。
誰かが開発したソフトウエア（技術）を無料で使うことができます。
だから、彼らが開発した技術を使って、私たち日本国のクラウドを作ればいいのです。
つづく
#014 私も大好きです。マイクロソフト、アップル、グーグル、アマゾン。
デファクトスタンダードだからなし得る、洗練された使い心地から、離れたくはありません。
だけど、弊害があるから、アメリカ国内でも、独占問題で議論になっている。
彼らは日本国に納税してますか？
５０歩ゆずって、彼らに日本国民を預けるとするなら、日本法人化し、収益を日本国で計上し、日本国内で税金を払わなければならない。
外国企業に、国民を預けるような国は、売国的な勢力に支配された、発展途上国、に見えませんか？
#007 コロナで不手際だったと言って、デジタル化をこれほど急ぐのも、胡散臭い。
不手際がデジタル化の遅れだけのせいではないだろうし、紙ベースでも効率を上げる方法はあるんじゃないでしょうか？
少し時間をかけて、議論しないといけませんね。
アイデアボックスでお祭り騒ぎして、国民の同意を得たことにするのだけはやめてほしい。
#010 そう思いますね。
今の政府の進み方だと、全部マイクロソフトとアマゾンに渡してしまいそうで、不安になりますよ。
これだとAWSやazureを使う技術はあっても、クラウドインフラの構築技術がなければ、それがいろんな意味でダメになった時、どうにもならない事態になってしまうのではないかと心配します。
国と全ての行政機関を合わせると、結構なボリュームになると思うんですよね。
内製しても十分いけるんじゃないかとおもいますし、こういう分野を採算で考えるべきでないと思うんです。
今でも本気で若い人たちに任せれば、オープンソースを使って、自前でクラウドを作る技術は十分あると思いますよ。
#007 そういう意味では、同感。
私もそう思います。
そこまで全てをデジタルにする必要はない。
結構多くのひとが、全部をクラウドに乗せてしまうようなデジタル化に、不安を感じていると思います。
雪見餅さんに、同感。
#008 この提言の意図を読みとって頂いていると思います。
ここもAWSなんですが、AWSってアメリカの会社の持ち物ですよ。
MicrosoftやAmazonみたいにアメリカだったら、そこに国民を預けてもいいとおっしゃるんですね。
おそらく多くの国民の皆さんは、そういう意識でおられると思います。
ここであえて、今後の世界情勢を考えると、それではやばくなるんじゃないですか？
ほんとに情勢がやばくなったとき、彼らはアメリカより日本のことを考えてくれますか？
ものが日本にあれば、本当に大丈夫ですか？
中国は西側でスパイ活動してますが、アメリカは日本にスパイを仕掛けたりしませんか？
という提言をさせていただきました。
#005 どの部分に対する反対ですか？
① クラウドについて反対？
② 個人情報を民間や国外に委託しないことに反対？
もし①なら、
内製にしろ外部に委託するにしろ、デジタル社会をクラウド以外で運用することはないと思いますよ。
このサイトだってクラウド上にあるんだから。
ここで提案しているのは、クラウド利用は避けられないことを前提に、
それを
a. 内製にするか
b. 外部に委託するか
で、
aがいいんじゃない。
という提言です。
デジタルデータを完全に安全に保管できる技術が確立するまでは、紙でも保管するべき、という雪見餅さんの意見には賛成します。
#003 誤解を招く表現でしたので、訂正させていただきました。
ここで提言させていただいたガバメンタル・クラウドから、特定の企業に、未承認の国民の情報が提供されることはないと考えます。
それは、現在以上に厳密に運用されるべきであると考えます。
『知らない間に企業とかに、情報が伝わって、知らない会社から営業の電話がかかって来たり』することはありません。
#001 ここで閉じたネットワークと表現させていただいたのは、インターネットと全く通信できないというものではありません。
セキュリティーゲートウェイを通して、インターネットと通信するのとができます。
逆にインターネットから、安全に情報を吸い上げる仕組みは、問題なく、可能です。
行政のシステムにおいては、インターネットとの接続に、より安全性の高い機構が求められますが、問題はありません。
デジタル社会実現のため、まず強固な土台作りを
投票履歴 5
高評価コメント 0
他のユーザからの評価（★の数）の平均が4以上のコメントを表示しています。
#003 つづき
そういう意味では、DMARCをフル実装しているドメインは少ないかもしれません。
メール受信者の立場からすると、SPFが厳格に設定されていれば、詐称メールをブロックすることができます。
SPFはDNSに設定するものなので、メールサーバーのアップグレードも必要ありません。
SPFの設定に関しては、以下の配慮が必要です。
(a) SPFのDNSレコードを~all（チルダオール）ではなく-all（マイナスオール）で締める。
(b) 送信サーバーのheloはサーバー名ではなくメールのドメイン名を名乗る。
つまり、エンベロープだけでなく送信元メールアドレスでもSPFのチェックができるように配慮する。
マルチドメインをホストするメールサーバーは、送信メールごとにheloをメールのドメインに合わせて名乗る。
これだけで、ほとんどの詐称メールはブロックできます。
SPFの正しい設定はメールサーバー管理者の義務だと思います。
by 郷田史介さん - 2020/12/07 16:29 問題を報告