アカウント名:
パスワード:
素人であるユーザーにとってはどういう経緯で証明書が発行されていようが、そんなことはどうでもいいわけですから、そこら辺が現場の腕の見せ所なんでしょう。
証明書の値段そのものよりも、期限切れの証明書を保守し続けるコストの方が気になります。
ひどいサイトだね。怖くて近寄れん。
CP/CPS のようなものは一応書いてあるものの、3行だけ。
・ルート証明書は、通信路の暗号化、サーバ証明書による IPA側のWEBサーバ(e-ipa.ipa.go.jp)の認証、クライアント証明書による申請者クライアントの認証を行なうために使用されます。 ・サーバ証明書とクライアント証明書は、IPAが電子的に申請、応募、応札等を受理する目的で使用されます。 ・IPAでは、ルート証明書の秘密鍵の管理については、十分注意を致します。 ルート証明書のダウンロードとインストール [ipa.go.jp]
安全な通信を行うための証明書についての詳しい説明 [mof.go.jp]の3.あたりに、フィンガープリントを確認したうえで、財務省が発行する証明書をブラウザに登録してください、などとありますが、、、。
#よくわかってなくて恥をさらすようでも ID
財務省の電子申請システムも、第三種オレオレ証明書になるのかな。
ご利用方法:安全な通信を行うための証明書に関する手順/フィンガープリントの確認 [mof.go.jp] を見ると、これは危険な確認方法を提示しているので、「インストール方法として安全な手段が用意されていないもの」に該当するでしょう。
ググってみた。このへんかな。
[memo:3458] 総務省「電子申請・届出システム」のセキュリティ上の問題点 [ryukoku.ac.jp] セキュリティホールmemo 2002.3 総務省「電子申請・届出システム」は信頼できるか [srad.jp] wakatonoによる 2002年03月29日 15時38分の掲載 <電子政府>総務省の認証基盤に欠陥 個人情報盗用も [mainichi.co.jp] 毎日新聞ニュース速報 2002年10月31日 総務省:「電子政府に100%の安全はなく、やむを得ない」 [srad.jp] Oliverによる 2002年11月02日 2時25分の掲載 GPKIおよびLGPKIにおけるルート証明書配布方式の脆弱性と解決策 [ryukoku.ac.jp] セキュリティホールmemo 2002.11
毎日の記事が消えてるけど Internet Archive にあった。 http://www.mainichi.co.jp/digital/solution/archive/200211/08/2.html [archive.org]
電子政府や電子自治体の利用者は、パソコンに詳しいとは限らない。全国民が対象なのだ。片山さんのように、(繰り返してごめんなさい)パソコンモニターとタッチパネルの区別が難しい人々でも、安心して簡単に使えることこそ求められている。要は、片山さんが「これなら簡単」というようなシステムを作ればいいのである。 その点を頭に入れて、政府認証基盤(GPKI)について考えてほしい。総務省の担当者は「利用者の利便性を考えると、インターネットとブラウザーの利用は避けられない」と言う。全くその通りだ。だが、(繰り返してごめんなさい)片山さんのような方々にとって、ブラウザーにルート証明書を組み込み、なおかつフィンガープリントを確認することは容易だろうか。 そのうえで、「ブラウザーにルート証明書を安易に組み込んだら危険だ」ということを理解、徹底させ、なおかつ暗号化されていないサイトからダウンロードしたルート証明書が、万一改ざんされて被害が発生した場合の法的責任について、納得していただくことができるだろうか。 (snip) 総務省側は、フィンガープリントの確認サイトのためだけにでも、標準的な暗号化方式SSLを利用することについて、「民間認証機関が発行するサーバー証明書が必要で、認証の根底には政府認証基盤ではなく、民間認証機関を置くことになって問題」とコメントしている。
一方、総務省大臣官房企画課の阿向泰二郎課長補佐は、毎日新聞の取材に対し.... 「仮に電子申請システムのルート証明書が、通信上で改ざんされ、改ざんされたルート証明書がユーザーのブラウザに組み込まれたとしても、電子申請システムのサイトに接続すれば、『信頼できない』としてはじかれるわけで、ユーザーは問題を認識できるはずだ」と主張。
「仮に電子申請システムのルート証明書が、通信上で改ざんされ、改ざんされたルート証明書がユーザーのブラウザに組み込まれたとしても、電子申請システムのサイトに接続すれば、『信頼できない』としてはじかれるわけで、ユーザーは問題を認識できるはずだ」と主張。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
証明書の取らせかた (スコア:2, 興味深い)
この手の隙をついた攻撃があまり無いから具体例として被害の例も挙げることが出来ないですし、イマイチ良い説得方法が見付かりません。
...みなさんどうやって説得してるんですかね?
Re:証明書の取らせかた (スコア:1)
詳しい図解入りの説明書作ったって良いだろうし、解説しているサイトに誘導するのでも良いのでは?
口で言ってまくし立っても、それをイメージ出来ていない奴がぱっとイメージ出来る訳ないよ。
言われた方が上司を説得するにしても、資料が無いと説明し難いだろうし。
Re:証明書の取らせかた (スコア:2, 興味深い)
素人であるユーザーにとってはどういう経緯で証明書が発行されていようが、そんなことはどうでもいいわけですから、そこら辺が現場の腕の見せ所なんでしょう。
Re:上司の承認プロセスにおけるマーフィーズロウ (スコア:3, すばらしい洞察)
しかも、その階層図は2ヶ月後にはあてにならなくなる。
・上司の技術的バックボーンが異なり、畑違いの言葉で説明をつけたすため
伝言ゲームでのやりとりをすると、必ず意味合いが変わってしまう。
・技術説明ミーティングを開けば良く集まり、よく理解したような手ごたえがある。。
しかし、必ず後で倍のフォローが必要になる。
・技術的説明が必要な人間は必ず同じフロアにいない。
そういう人間が会議に出たときに限って機材が原因不明のトラブルに遭う。
・すべての承認を取り付けたと一息ついた所で
別部門に対して同じプロセスが必要だと知らされる。
(振り出しにもどる)
この条件に当てはまる数が多いほど、そのプロジェクトが
正月休み等のイベントを台無しにする可能性が高いです。
気をつけましょう。
Re:上司の承認プロセスにおけるマーフィーズロウ (スコア:0)
Re:上司の承認プロセスにおけるマーフィーズロウ (スコア:0)
Re:上司の承認プロセスにおけるマーフィーズロウ (スコア:0)
素人の意見は・・・ (スコア:1)
ホントはどうでも良いどころか大事なことなのに、理解できないのが根本的な問題かも。
素人の反応を予測すると
・住所が西の人
「よくわかんないけどしっかりしてね。」
・住所が東の人
「ウチは東だから大丈夫なんでしょ?」
Youthの半分はバファリンでできています。
Re:証明書の取らせかた (スコア:0)
タダで取れるならともかく、結構な額がかかるものですから、結局予算の話の中でコストとリスクを評価されて、真っ先に削られる候補になるんです...。
Re:証明書の取らせかた (スコア:3, おもしろおかしい)
だから証明書の購入コストってのは全然大したこと無いと思います。
ただ、証明書の値段そのものよりも、期限切れの証明書を保守し続けるコストの方が気になります。
一つのプロジェクトで最初にかかるコストが数千や数万円かかるくらいはたいしたことがないと思います。
でも証明書の更新ってのは1年後か長くても数年後には確実に来るものです。
そしてその頃当時のメンバー(特に証明書のことをきちんと分かっている人)が居るかどうかは分かりませんし、更新時期にはプロジェクトに全く関係の無い人間しか居ないこともざらかと思います。
プロジェクト開始時には何の問題も無かったのに、分かる人が居ないかも知れない未来に託して、期限切れが放置されて客からクレーム(第3者から騒がれたとか、突然ダイアログが出るようになったとか)を受けて、自分たちのプロジェクトに泥が付くというのはやりきれないでしょう。
きちんとした運用マニュアルを作ってその通り運用すれば良いと言う意見も当然ですが、そうすることが出来ないケースも多いでしょうし。
そこで「暗号化はされますがサイトの身分証明は出来ないので第3者に誘導された場合の改竄や盗聴の防止にはなりません。それにダイアログも当然出るのでユーザにOKボタンを押して貰うことになります。」
ということを顧客に説明して一度妥協してオレオレ証明書でスタートしてさえしまえば、
後に証明書の期限切れになったとしても、ダイアログが出たらOKを押して進めるというのに慣れたユーザはそのダイアログに期限切れの注意マークが増えていることに気づくことも無くクレームはおきにくい。
という保守コストも削れる駄目駄目な楽チン解の方が良いということも多いでしょう。
技術者ってのは当面のコストよりも将来の保守を嫌う傾向があるようですし…。
なので証明書のコストを議論する際は、証明書1枚の値段よりも証明書の更新の簡単さ(出来れば人が何もしなくても自動更新できると嬉しい)が必要だと思ってます。
Re:証明書の取らせかた (スコア:0)
ひどいサイトだね。怖くて近寄れん。
Re:証明書の取らせかた (スコア:0)
例えば IPA セキュリティセンターの脆弱性関連情報の届出 [ipa.go.jp]が活用されると状況も変わってくるんじゃないかな。
# IPA から修正依頼が何度か来たので AC
Re:証明書の取らせかた (スコア:1)
CP/CPS のようなものは一応書いてあるものの、3行だけ。
Re:証明書の取らせかた (スコア:0)
Re:証明書の取らせかた (スコア:2, 参考になる)
それだけではなく、運用の厳密さは私の関わっていた金融関連(金融機関のシステムは金融庁のガイドラインでかなり細かく運用方法が縛られている)のシステムとも比べものになりません。
私はとても同じとはいえませんね。
Re:証明書の取らせかた (スコア:1)
安全な通信を行うための証明書についての詳しい説明 [mof.go.jp]の3.あたりに、フィンガープリントを確認したうえで、財務省が発行する証明書をブラウザに登録してください、などとありますが、、、。
#よくわかってなくて恥をさらすようでも ID
Re:証明書の取らせかた (スコア:0)
ご利用方法:安全な通信を行うための証明書に関する手順/フィンガープリントの確認 [mof.go.jp] を見ると、これは危険な確認方法を提示しているので、「インストール方法として安全な手段が用意されていないもの」に該当するでしょう。
Re:証明書の取らせかた (スコア:1)
ところで、これの確認方法どのあたりが危険なのでしょうか?
比較するフィンガープリントを暗号化されていない(改ざん対策されていない)ページに載せていること?
Re:証明書の取らせかた (スコア:1, 参考になる)
>比較するフィンガープリントを暗号化されていない
>(改ざん対策されていない)ページに載せていること?
ググってみた。このへんかな。
[memo:3458] 総務省「電子申請・届出システム」のセキュリティ上の問題点 [ryukoku.ac.jp] セキュリティホールmemo 2002.3
総務省「電子申請・届出システム」は信頼できるか [srad.jp] wakatonoによる 2002年03月29日 15時38分の掲載
<電子政府>総務省の認証基盤に欠陥 個人情報盗用も [mainichi.co.jp] 毎日新聞ニュース速報 2002年10月31日
総務省:「電子政府に100%の安全はなく、やむを得ない」 [srad.jp] Oliverによる 2002年11月02日 2時25分の掲載
GPKIおよびLGPKIにおけるルート証明書配布方式の脆弱性と解決策 [ryukoku.ac.jp] セキュリティホールmemo 2002.11
毎日の記事が消えてるけど Internet Archive にあった。
うーん、なんだかなあ。http://www.mainichi.co.jp/digital/solution/archive/200211/08/2.html [archive.org]
Re:証明書の取らせかた (スコア:0)
Re:証明書の取らせかた (スコア:1)
万が一 (攻撃者にとって万が一、ですよ) ユーザが正しいサイトにつなげて
しまったとしても、警告も出ないのでは?
ルート証明書の一覧を確認すれば載ってますが、普通は気づかないでしょう。
Re:証明書の取らせかた (スコア:0)
よくそういう言い訳を聞くけど、それは全体のコストの何パーセントなの?
1パーセント以下でしょ、普通。
Re:証明書の取らせかた (スコア:0)
Re:証明書の取らせかた (スコア:0)
って、「んなこた滅多に起こらんだろう」とか言われて、「想定利用者数×500円×限りなく0に近い数字」で計算されたら、やっぱり削減対象か。うーん……。