アカウント名:
パスワード:
hhmmssでファイル名作ってたとか恥ずかしい問題という話まぁ恥ずかしいのはともかくこんなシステム作って問題起こしちゃったら胃が痛いだろうな…
ファイル名を128bit乱数とかにしとけば、相当運が悪くない限りバッティングしなさそう
「念のため」でも付けとけば実際問題にはならんかったよなぁ とか思ってしまうでもそういうののあったらもし起きたら解析大変なんだよなー
これって本来はファイル名は固定でも問題ないはずの処理になってて、「念のため」に日付にしといただけだと思う。
はっはーんありそうかもそしてそのせいで検査すり抜けちゃったとか…
乱数でも衝突しないわけじゃないので、どうしてデータベースに同じのがないか確認しないの?1個if文入れることすら納品前にできない人間に作らせてるのは怖い
> どうしてデータベースに同じのがないか確認しないの?法律上の理由。
処理用の乱数IDにも法律引っかかるん?
むっちゃひっかかる
番号法2条8項 この法律において「特定個人情報」とは、個人番号(個人番号に対応し、当該個人番号に代わって用いられる番号、記号その他の符号であって、住民票コード以外のものを含む。第七条第一項及び第二項、第八条並びに第四十八条並びに附則第三条第一項から第三項まで及び第五項を除き、以下同じ。)をその内容に含む個人情報をいう。
マイナンバーの代わりに乱数IDを振ったら、それもマイナンバーとみなす、というのが法律の立て付け。
詳しくないので教えてほしいのですが、それはマイナンバーと乱数IDが紐付けられる場合であって、重複チェックの対象であるところの、証明書のテンポラリファイルや発行履歴テーブルにマイナンバーが含まれていないならば関係ないですよね?
逆に言うと、マイナンバーと紐付けなくても重複チェックは出来そうな気がするのですが。
マイナンバーと紐づかないのなら、DBテーブル全件とかディレクトリ中ファイル一覧とかから乱数IDで検索して1件とか一致したときに、それが自分ナンバーのモノか他人ナンバーのモノかわからない気がしてくる…
重複が検知された場合、すべての問合せに対して業務を止めるって仕組みならできそうではある。当件においてセキュアだけど、もしそれが発生したらたぶんその時も大臣は文句を言うと思う。
そもそもマイナンバー単位で印刷ファイル名のID振るなよ印刷要求単位で振れよ
いや、そもそも最初の出力要求と住民票データ引っ張り出すとこまでしかマイナンバーいらんでしょ。印刷イメージの作成に入った時点でセッション管理なりでUUID送るとかマイナンバーと別の情報で送付先管理しなさいな。
印刷イメージ内にマイナンバー入ってたりしないん?
入ってることも入ってないこともあるけどそれがどうした?
印刷イメージのファイル名をデータベース管理とかコスト意識なさすぎて逆にこえーよUUID使えば済む話だろ
実機でテストできるのが、リリース1カ月前だからに決まってるじゃないですか。それまではF様の下請け先に作らせ、下請けが開発完了したところで、DVDに入れて一次受けに持ってくる。そこで実機投入。
1カ月でバグ全部潰せ、リリース日は変えられない、実にウォーターフォールモデル。
被らないファイル名を作成して応答で教えてやればいいだろ
それな絶対に衝突を許してはならないシステムなのに採番の手間くらいケチるなと
XTECH(要ログイン)によると [nikkei.com]、ファイル作成は逐次処理で、本来は先の人の処理が終わるまで後の人のファイル作成は待たされる作りになっていたとのこと。hhmmssどころかファイル名固定なんじゃないかな。
どうして逐次処理にこだわるか不明だけど(FujitsuとのことなのでListCreatorを使ってそうだけど設定を弄れば100並列できそう [fujitsu.com])、それならそれで、適当にカウンタ付けて「###通目.pdf」とかにすりゃいいのに…
古いPerl CGIで見かけたような雑な排他制御でもしてたのか
ちな雇用調整助成金の受付システム [nikkei.com](2020年)も、他人の情報を閲覧できるバグをやらかし。今後も、また同じようなバグを作りこむでしょう。
早々に不具合を認めて改修されたようでよかった。他人の住民票が発行された(保持している)状態で、富士通Japan様が不具合を認めなければあの神奈川県警に逮捕されるところだった。
まあさすがのヨコハマ県警でもそれはしないとは思うが、だが富士通は現実にイギリスで大規模冤罪事件の原因になっていて場合によっちゃ本気でシャレにならん事態を引き起こすことがあるのよな富士通製ソフトウェアのバグが原因で横領犯にされていた英国の元郵便局長39名、十数年ぶりに名誉回復 [srad.jp]
戸籍証明書のコンビニ発行は自治体によって対応が違うので、川崎市だけのシステムというのはまあそうかも。戸籍は他の自治体とネットワークで共有することが禁止されてるので、法務省に副本がある以外は自治体ごとに独自管理ということになってる。
なので、戸籍証明書はコンビニ発行が出来る自治体もあれば出来ない自治体もあるし、現住所と本籍地が違うと出来なかったりとか、面倒な話になってる。(まあ戸籍証明書が必要な場面って日常生活ではあんまりないから困る人も少ないのだろうが)
…というのが今年までの話で、来年になると法務省の戸籍副本に本籍地以外の自治体からもアクセスできるようになるので戸籍証明書も戸籍副本からどこからでも発行できるようになる…はず。
>富士通Japan広報によると、横浜市以外で別人の証明書が発行される事象は確認できていないという。>横浜市は同社によるプログラム改修の報告を受け、3月29日午前6時30分にサービスを再開した。
対応の結果がこの様なので、ごまめが総点検せい!とおこなのも無理はない。
これまで富士通Japanは当該自治体のシステムに固有の事象で他の自治体では同社システムでも影響はないと言い訳してたけど2ヶ月で13件も発生してさすがに無理が出てきたんでしょ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
川崎市では問題は解決された (スコア:4, 参考になる)
・マイナカードで誤交付 川崎市「2人同時申請で、システム不具合」発生
市内2カ所のコンビニで2人が1秒以内のほぼ同じタイミングで申請をしたところ、
システムの不具合で先に申請した人の証明書に後の人の内容を上書
・市によると、戸籍システムとコンビニ交付システムのデータを連携する「個別連携システム」が原因
・富士通Japanがプログラムを修正
・市は9日朝から戸籍のコンビニ交付サービスを再開
個別連携システムを使っているのは川崎だけらしいが
他の自治体も似たような話か
Re:川崎市では問題は解決された (スコア:3)
hhmmssでファイル名作ってたとか恥ずかしい問題という話
まぁ恥ずかしいのはともかくこんなシステム作って問題起こしちゃったら胃が痛いだろうな…
Re: (スコア:0)
ファイル名を128bit乱数とかにしとけば、
相当運が悪くない限りバッティングしなさそう
Re:川崎市では問題は解決された (スコア:2)
「念のため」でも付けとけば実際問題にはならんかったよなぁ とか思ってしまう
でもそういうののあったらもし起きたら解析大変なんだよなー
Re: (スコア:0)
これって本来はファイル名は固定でも問題ないはずの処理になってて、「念のため」に日付にしといただけだと思う。
Re:川崎市では問題は解決された (スコア:2)
はっはーんありそうかも
そしてそのせいで検査すり抜けちゃったとか…
Re: (スコア:0)
乱数でも衝突しないわけじゃないので、どうしてデータベースに同じのがないか確認しないの?
1個if文入れることすら納品前にできない人間に作らせてるのは怖い
Re: (スコア:0)
> どうしてデータベースに同じのがないか確認しないの?
法律上の理由。
Re: (スコア:0)
処理用の乱数IDにも法律引っかかるん?
Re: (スコア:0)
むっちゃひっかかる
マイナンバーの代わりに乱数IDを振ったら、それもマイナンバーとみなす、というのが法律の立て付け。
Re: (スコア:0)
詳しくないので教えてほしいのですが、それはマイナンバーと乱数IDが紐付けられる場合であって、
重複チェックの対象であるところの、証明書のテンポラリファイルや発行履歴テーブルにマイナンバーが含まれていないならば関係ないですよね?
逆に言うと、マイナンバーと紐付けなくても重複チェックは出来そうな気がするのですが。
Re: (スコア:0)
マイナンバーと紐づかないのなら、DBテーブル全件とかディレクトリ中ファイル一覧とかから乱数IDで検索して1件とか一致したときに、
それが自分ナンバーのモノか他人ナンバーのモノかわからない気がしてくる…
重複が検知された場合、すべての問合せに対して業務を止めるって仕組みならできそうではある。
当件においてセキュアだけど、もしそれが発生したらたぶんその時も大臣は文句を言うと思う。
Re: (スコア:0)
そもそもマイナンバー単位で印刷ファイル名のID振るなよ
印刷要求単位で振れよ
Re: (スコア:0)
いや、そもそも最初の出力要求と住民票データ引っ張り出すとこまでしかマイナンバーいらんでしょ。
印刷イメージの作成に入った時点でセッション管理なりでUUID送るとかマイナンバーと別の情報で
送付先管理しなさいな。
Re: (スコア:0)
印刷イメージ内にマイナンバー入ってたりしないん?
Re: (スコア:0)
入ってることも入ってないこともあるけどそれがどうした?
Re: (スコア:0)
印刷イメージのファイル名をデータベース管理とかコスト意識なさすぎて逆にこえーよ
UUID使えば済む話だろ
Re: (スコア:0)
実機でテストできるのが、リリース1カ月前だからに決まってるじゃないですか。
それまではF様の下請け先に作らせ、下請けが開発完了したところで、DVDに入れて一次受けに持ってくる。そこで実機投入。
1カ月でバグ全部潰せ、リリース日は変えられない、実にウォーターフォールモデル。
Re: (スコア:0)
被らないファイル名を作成して応答で教えてやればいいだろ
Re: (スコア:0)
それな
絶対に衝突を許してはならないシステムなのに採番の手間くらいケチるなと
Re: (スコア:0)
XTECH(要ログイン)によると [nikkei.com]、
ファイル作成は逐次処理で、本来は先の人の処理が終わるまで後の人のファイル作成は待たされる作りになっていたとのこと。
hhmmssどころかファイル名固定なんじゃないかな。
どうして逐次処理にこだわるか不明だけど(FujitsuとのことなのでListCreatorを使ってそうだけど設定を弄れば100並列できそう [fujitsu.com])、
それならそれで、適当にカウンタ付けて「###通目.pdf」とかにすりゃいいのに…
Re:川崎市では問題は解決された (スコア:1)
// お約束すぎる
Re: (スコア:0)
古いPerl CGIで見かけたような雑な排他制御でもしてたのか
Re: (スコア:0)
ちな雇用調整助成金の受付システム [nikkei.com](2020年)も、他人の情報を閲覧できるバグをやらかし。
今後も、また同じようなバグを作りこむでしょう。
Re:川崎市では問題は解決された (スコア:1)
早々に不具合を認めて改修されたようでよかった。
他人の住民票が発行された(保持している)状態で、富士通Japan様が不具合を認めなければ
あの神奈川県警に逮捕されるところだった。
Re:川崎市では問題は解決された (スコア:1)
まあさすがのヨコハマ県警でもそれはしないとは思うが、だが富士通は現実にイギリスで大規模冤罪事件の原因になっていて場合によっちゃ本気でシャレにならん事態を引き起こすことがあるのよな
富士通製ソフトウェアのバグが原因で横領犯にされていた英国の元郵便局長39名、十数年ぶりに名誉回復 [srad.jp]
Re:川崎市では問題は解決された (スコア:1)
戸籍証明書のコンビニ発行は自治体によって対応が違うので、川崎市だけのシステムというのはまあそうかも。
戸籍は他の自治体とネットワークで共有することが禁止されてるので、
法務省に副本がある以外は自治体ごとに独自管理ということになってる。
なので、戸籍証明書はコンビニ発行が出来る自治体もあれば出来ない自治体もあるし、
現住所と本籍地が違うと出来なかったりとか、面倒な話になってる。
(まあ戸籍証明書が必要な場面って日常生活ではあんまりないから困る人も少ないのだろうが)
…というのが今年までの話で、
来年になると法務省の戸籍副本に本籍地以外の自治体からもアクセスできるようになるので
戸籍証明書も戸籍副本からどこからでも発行できるようになる…はず。
Re: (スコア:0)
>富士通Japan広報によると、横浜市以外で別人の証明書が発行される事象は確認できていないという。
>横浜市は同社によるプログラム改修の報告を受け、3月29日午前6時30分にサービスを再開した。
対応の結果がこの様なので、ごまめが総点検せい!とおこなのも無理はない。
Re: (スコア:0)
これまで富士通Japanは当該自治体のシステムに固有の事象で他の自治体では同社システムでも影響はないと言い訳してたけど2ヶ月で13件も発生してさすがに無理が出てきたんでしょ