公務員叩きに物申す!-現職公務員の妄言 システム運用保守に、後期高齢者医療制度に、公務員叩き批判に、行政改革に、福祉行政に、ITに、WEB2.0に、SNS管理に、VBに、Scriptに、情報セキュリティに、IPネットワークに、SEOに、ほんの少し家族サービスなブログ。

TAGWORD

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト:
 炎上覚悟でキャリアブレイン社の記事と京都府保険医協会の主張に苦言。



医療IT化「情報漏れの危険性」(キャリアブレイン)

 今年4月からの段階的な施行を経て、2011年4月以降は医科・歯科すべてのレセプト(診療報酬請求書)のオンライン請求を義務化する厚生労働省の方針について、患者の診療情報漏れをはじめ、情報が診療以外のことにも使用される問題点が指摘されている。患者の診療情報が外部に漏れてしまった場合、さまざまな犯罪にも悪用されかねないだけに、こうした危険性を残したまま急いでオンライン化を進めることに、医療団体や医療事務関係者から疑問の声が上がっている。

(中略)

 このレセプトのオンライン請求に関して、京都府保険医協会などの医療関連団体が3つの大きな問題点を指摘している。
 1つめは、患者の診療情報が漏れる危険性だ。オンライン請求の場合、医療機関から審査支払機関に送られたレセプトのデータは審査を経て、保険者にデータ送信。その後、政府に情報提供される仕組みになっているが、この流れのどこかで診療報酬が漏れる可能性があるという問題だ。

(中略)

 同じ電子情報としては、住基ネット(住民基本台帳システムネットワーク)で06年3月に北海道斜里町でWinny(ウイニー)を介したインターネット上への流出など情報漏えい事件が続発。同協会などは「こうした危険性を残したまま急いでオンライン化を進めることは問題」と警告している。

 2つめは、患者の情報が診療以外のことで使われる問題だ。内閣府の規制改革会議(議長=草刈隆郎・日本郵船会長)が診療情報の民間活用を求めているなど、国は民間による診療情報・健診情報の活用方法を検討している。「あなたにピッタリの薬」、「あなたのためのフィットネス」といったダイレクトメールが届くことも想定され、

(中略)

 3つめは、地域の医者が辞めてしまうかもしれないということだ。同協会が京都府内の60歳以上の開業医にアンケートした結果、オンライン請求が義務化されれば3割を超える医師が「辞めて引退する」と回答。



 2つめの個人情報目的外利用問題と3つめの引退問題(設備投資負担問題)、これは確かに理解できる。
 特に、某省庁が個人情報の目的外利用に非常に鈍感であることは様々なシーンで感じとることができるし、ダイレクトメールの例は極論としても、そうならないように監視の目を光らせることは重要だろう。

 だが1つめの情報漏えいの問題提起はどうにも納得しかねる。

 「この流れのどこかで診療報酬が漏れる可能性がある」というのは具体的にどこの何を指しているのであろうか?
 そして、その情報漏えいポイントはオンライン特有のものであろうか?

 レセプトが医療機関から国保連合会や支払基金といった審査支払機関を経由し、保険者に到達するのは現在も同じである。
 ただそれが紙か電子データか、という違いだけだ。

 実は、現在のレセプト請求の仕組みで言えば、紙の方が情報漏えいポイントは圧倒的に多い。
 その意味ではレセプトオンラインのほうが、はるかに安全だということだ。

 現状、多くの医療機関、審査支払機関、保険者は、レセプトをそれぞれの組織単体でのみデータ化し、他の機関に提出するときには紙に戻すという手法を取っている。

 オンラインであれば、暗号化したうえで送信すれば、目的は達することが出来る。

 だが今の仕組みは、まずある機関が保有データを紙に変換せねばならない。
 システム内ではアクセス権限管理やデータの暗号化がなされ、それなりのセキュリティが保たれていたとしても、このポイントで多量の個人情報がむき出しになるわけである。

 しかも紙はかさばる。
 1都道府県単位の審査支払機関には、毎月数十万枚から数百万枚単位のレセプトが集約されるが、この莫大な量の紙を処理するためには頻繁に委託業者の手を借りなければならない。
 それこそ、1か月単位で輸送し、倉庫に入れ替え、定期的に廃棄せねばならないわけだが、全て別々の業者であろう。

 つまり、何十人、何百人という他人の手に渡り、目に触れることになるということだ。

 もちろん、委託業者には委託主と同等のセキュリティポリシー遵守義務や守秘義務が課せられるが、
 官民問わず、個人情報漏えい事件の大半が、委託先や下請け、アルバイトなどからの漏えいであることを忘れてはならない。
 (これは、委託先や下請け等の末端にまで情報セキュリティの意識や取り扱いを浸透させることが非常に困難であることを示している)

 紙は暗号化されていない。平文で誰でも読むことが出来る。紙への部外者の物理的到達は、即、情報漏えいを意味する。

 紙は情報を到達させるために時間がかかり、輸送の間、常に危険に晒される。
 鍵付きのカバンで車で輸送していたとしても、カバンごと、車ごと盗まれる可能性もある。

 情報の変換にはデータの完全性損失のリスクがある。(あれ、2枚目の続紙はどこにいった?)
 印字ミスや紙つまり等もあり、処分方法に注意を払わなければ、ゴミ袋などから情報が漏洩することもある。

 多量の紙の使用は環境にも優しくないし、何より非効率でコストがかかる。(税金ドロボー!)

 特筆すべきなのは、電子の情報が不正アクセスを受けた場合は痕跡が残るが(もちろん侵入者によって消される場合はある)、紙に残るのはせいぜい指紋ぐらい、そして紙自体に触れなければ周囲に監視カメラでもつけていない限り痕跡は全く残らない。
 つまり、紛失や盗難でもなければ、紙媒体から情報漏えいしたとしても、ほとんどそれが分からないし、騒がれることも報道されることも無い。
 (これが紙が安全だと妄信される所以である)

 一方で媒体でのデータ搬送は、暗号化等が施せる分、紙に比べて若干セキュリティが高くなるが、かさばらない分、紛失のリスクは高くなるし、輸送の間危険に晒されることに変わりはない。

 では、レセプトオンラインの特有の危険性とはどこにあるのであろう?

 端末における不正アクセスが起こるから危険だというのであれば、現在病院や診療所にある医事ネットワーク端末やレセコンも同様に危険である。
 特にローカルのHDDで個人情報を管理している場合は、盗難による情報漏洩の危険もあり、その意味ではスタンドアロンよりネットワーク(セキュリティのしっかりしたサーバルームで集中管理)の方が安全といえる。

 拠点ネットワーク回線への侵入の危険(スニッフィングやサーバ乗っ取りなど)は、病院などには既にLAN(医事ネットワーク)が構築されているから、危険性は同等である。
 もちろん診療所のスタンドアロンのパソコン(レセコン)がネットワーク化することにより増大するリスクはあるが、
 そもそもちっぽけな診療所の中のネットワークに侵入できるんなら、それはカルテや端末、現金にも到達できる状況じゃないか?

 となると、残るはLAN同士を結ぶ閉域網部分のリスクであり、この部分が京都府保険医協会の言う「どこかで」となろうが、ここで悪さを働くためには、まず通信事業者の(この部分自粛)。
 これは、ソーシャルエンジニアリングを用いた各種機関の端末への不正アクセスや、医事ネットワークなどのLANへの侵入に比べてはるかに難易度が高い。

 大体、近年のほとんどの情報漏えい事件は、端末等から保存した媒体あるいは出力帳票などから起きている。ネットワークそのものが原因というのはあまり聞いたことが無い。
 そして前述のとおり、閉域網で暗号化されたデータとして送信する行為は、多量の紙に変換して赤の他人が搬送するよりも、はるかに安全であると思われる。

 要するに、レセプトオンラインが危険と主張するのならば、今の仕組みも同様に(あるいはそれ以上に)危険であるということだ。

 自分が情報セキュリティの現場にいて非常に強く感じることは、
 意識しているかどうかはともかく、「紙は情報媒体ではない」あるいは「紙であればセキュリティはまず大丈夫」と考える人が圧倒的に多いことだ。
 情報システムや電子媒体のセキュリティはしっかりしているのに、出力帳票(もちろん個人情報入り)の扱いはずさん、という組織は少なくない。
 医師に限らず、「紙は安全、オンラインや電子は危険」と盲目的に考えている多くの人たちが個人情報を扱っている現状に強い危惧を覚える。

 思うに、この提言に関わった方々は、レセプトオンラインや住基ネットのアーキテクチャと全く関連の無い事件を引用されているあたり、ITや情報セキュリティに詳しくないのではなかろうか?

 一般人なら「電子やオンラインは何か不安だ!」と訴えるのはまだ良かろう。
 だが医師は大切な個人情報を預かり、利用する側であることを忘れてはならない。
 素人同然の見地でセキュリティを語れば、却って医師の信用や信頼を損ないかねない。

 レセプトオンラインにセキュリティ上の問題があるかないかといえば、確実にある。
 絶対に安全だと言うつもりは毛頭無い。
 だが、的外れなセキュリティ議論をしていても意味が無い。
 そして「紙は安全、オンラインや電子は危険」と妄信することは、却ってセキュリティを低下させる結果につながりかねない。


スポンサーサイト

はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: セキュリティ, 個人情報保護, 医療制度改革, オンライン,
 親父ギャグは聞き飽きたという苦情は無視して、今回はセキュリティの話である。

 目の前にサーバがある。さてセキュリティ対策はどうするか?

 「じゃあセオリーどおり、施錠できるラックに入れて、耐震対策をして、非常電源を用意して、…これでセキュリティ対策はバッチリだ。」

 一見正しいように見えるが、そうではない。
 そのサーバは本当にそこまでコストをかけて守らなければいけないのか?
 こうしたリスク分析と判断のプロセスが抜けているからである。

 「障害が起きたらサーバが止まる、だからクラスタ構成にする」
 これはセキュリティ対策ではない。

 「障害は起きたらサーバが止まる。発生確率はそこそこある。サーバがとまると莫大な被害が出る。だからクラスタ構成にする」
 これが正しいセキュリティ対策である。

 システム障害は、確かに脅威と定義される。しかしその発生確率と情報資産への影響を論ぜずして対策を語るのはナンセンスだ。
 同様に不正アクセスも、そこに被害にあうべき情報資産や「踏み台」にされるリスクが存在しなければ、対策する必要がないのである。

 オンライン処理の要となるサーバで、それが停止すると全業務に支障が出、1分たりとも停止が許されないサーバであれば、クラスタ構成にして免震台も履かせて、ネットワークも二重化三重化、といった対策が必要だろう。
 ところが、このサーバが外部とのデータ授受のみに使用し、それも1日1回業務時間外にしか利用しないものであれば、スペアの代替機が1台あれば十分だ。
 耐震対策はおろかUPSすら必要ないかもしれない。
 システム領域のためのバックアップソフトなどを搭載した日には、下手をするとライセンス代だけでもう一台代替機が買えてしまうわけで、こういうのは意味の無い対策であり、むしろ税金の無駄遣いである。

 要するにセオリーなど無い。
 リスクは千差万別であるから、行うべき対策も必然的に異なってくるわけである。

 その意味では、項目のみあげた「防災グッズカタログ」のようなものがあっても、それ単体では全く役に立たない。
 仮にも「それ単体」で個人情報保護審議会に大いに役立つとしたら、随分お粗末な話ではある。
 残念ながらこうした審議会は「対策項目」のみをチェックし、その前段階のプロセスを度外視しているケースが多いのも事実ではある。

 セキュリティ対策でまず手がけることは、対策項目の検討ではなく、リスクの分析であり、そのためには何よりシステムの詳細仕様が必要である。
 少なくともこのサーバが停止したらどの程度の支障がでる、とか、容認できる停止時間は何時間とか、個人情報を含むデータの有無とか、そういうことがわからない状態で対策項目を検討しても結論はでない。
 例えば、このサーバをシングルにするかクラスタにするかといった選択も、絶対に決まるはずがないのだ。



 例によって今回の話はセキュリティに対する一般論であって他意はない。何か思い当たる節があってもそれは気のせいである。
 くどいようだが邪推は無用である。


はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: セキュリティポリシー, セキュリティ, 個人情報保護, リスク分析,
 最近住基ネット訴訟関連の話で騒がしい。

 1.高裁初の違憲判決が出た。
 2.違憲判決を出した当該裁判官が謎の自殺(?)を遂げた。
 3.箕面市において、市長が住基ネット訴訟における上告を断念した。
 4.判決命令を実行するために必要なシステム改修経費が最大3,500万円と報じられた。

 確かに短期間でこれだけ事件が起これば、話題には事欠かない。
 
 1~3についてはこのblogで取り扱うべきでない要素が含まれているため言及は避けるが、4に対するネット上の反応には正直辟易した。
 blogなどで有象無象の「素人システムアナリスト」が「どう考えても3,500万円は高すぎだろ」といった批評をしているわけだが、「どう考えても」の部分に感覚論以外のどういう合理的判断や根拠があるか小一時間問い詰めてみたいものである。
 中には「1人で3,500万円だから4人なら1億4,000万だ」というトンチンカンな主張まで出てくる始末だ。
 そもそも3,500万円はリスク要素(と利ざや)を含めた概算の最大見積もりであろうから、適正か否かを論ずる以前の話であろう。
 そこまでは高くないとしても、履歴も含めてネットワークと連携した住基システムのデータにつき、整合性を保ちながら単独でネットワーク側のみ削除し、かつ今後も不具合が発生しないようにするのは、確かに一筋縄では行きそうにない。
 一方で市町村住基データと住基ネットデータ、両方同時に削除するのは造作も無いことであるから、「システム改修をしないのなら今後全て手管理になる」というのはそういうことなのだろう。
 (ところで箕面市は住登外を全て手管理しているのか?)

 もちろん、後期高齢者医療制度も対岸の火事では済まされない。

 後期高齢者医療制度も広域単位で個人情報を集約し、オンラインで一元管理するシステムだ。
 しかも中を流れる個人情報の重要度は「たかだか基本4情報」の住基ネットの非ではない。
 そして、たとえLGWANもしくは同等のセキュリティの回線を利用するといえど、住基ネットよりセキュリティ面で劣ることは否めない。

 誰しもこういう不安を感じずにはいられないであろう。
 果たして大丈夫なのであろうか?


はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: LGWAN, 住基ネット, 箕面市, 個人情報保護, セキュリティ,
 このblogの常連読者の方々には、LGWAN自体の何たるかの説明は不要であろう。
 万一説明が必要ということであれば、LASDECのHPを参照されたい。
 (LASDECは厚生労働省と違って面倒くさいリンクポリシーがあるので、今回直リンクはやめた。必要であればインターネットを検索していただくか、過去の記事を参照していただきたい。しかしWeb2.0のこの時代にLASDECともあろうものが時代遅れのリンクポリシーを掲げるのはいかがなものか)
 
 そもそも後期高齢の広域連合電算処理システムにLGWANを利用するという構想の根幹は、今年の1月19日に総務省が策定した「IT新改革戦略」にある。
 この中には壮大なレセプトオンラインの絵が描かれるとともに「各府省や地方公共団体を接続するシステムについては、原則としてLGWANへの統合を進める」と謳われている。
 「地方公共団体を接続するシステム」の第一弾が後期高齢者医療制度というわけだ。
 良くも悪くもモルモットである。
 文句を言うなかれ、我々がモルモットなのはネットワークに限った話ではないのだから。

 さて、当初LGWAN一本で進めていた厚生労働省だが、途中で他の回線もOKだと態度を軟化させたのは周知の事実である。

 LGWANは中々に厄介者だ。
 問題点をざっと挙げていくと…

1.帯域の問題
 まずLGWANやそれに接続するLGWANアクセス回線の帯域の問題がある。
 線が細すぎるというやつだ。
 増強対応をする都道府県は良いが、予算などの事情で来年夏までに対応されない地域にとっては大きな問題である。
 ちなみにアクセス回線の帯域を確保しても、都道府県NOCやLGWAN提供設備の中身が古いままだと、十分なスループットが期待できないかもしれない。

2.手続きの問題
 次に接続申請に時間がかかるということがある。
 地方自治体側は一部の離島を除き、全ての市区町村で接続を終えているが、一部事務組合などは必ずしも接続しているわけではない。
 そして後期高齢者医療広域連合は新規でLGWAN-ASPの申請を行わなければならないわけであり、もしLGWANを利用するならば、早急に要件を満たすための体制づくりと、申請手続の準備を進めなくてはならない。
 また、LGWANに接続する広域連合電算処理システムのサーバ群を、自前で確保するのではなく、業者のIDCに設置する場合、その業者がLGWAN-ASPとしての条件を満たしていなければならない。
 県内にそうした業者がいない場合、LGWANの利用は極めて困難だ。

3.利用プロトコルの問題
 LGWANは非常に限られたプロトコルしか利用できず、とりわけ広域側から市町村へのデータ転送は不可能である。よって、データ授受を行う際は市町村側から広域に取りに行かねばならない。
 もちろん「気になる木」さんのシステムはその前提で構築されるであろうが、市町村の窓口サーバの保守管理の面で難が生ずる。
 例えば窓口サーバにおいて何らかのバージョンアップを行う場合は、媒体渡しとなることが確定であり、そしてその更新漏れ等の把握が困難である。またリモートによる初期障害切り分けやヘルプデスク対応も不可能である。

4.市町村ネットワークの問題
 もともと市町村サイドにおいて、LGWANに個人情報を流すことを想定したネットワーク構築やポリシーがけを行っていないということである。
 個人情報を扱うネットワークとは物理的(論理的ではない)に隔絶して、異なったポリシーがけをしている所が多く、中にはLGWANの先はクライアント1つだけで、ネットワークに引き入れていない市町村も存在するという。
 LGWANにもインターネットにも接続できる端末で個人情報を扱っても良いかという議論もあるだろう。
 現行の市町村のポリシーでは容認されないケースが多く、ポリシー変更には多くの市町村の反発が予想される。

 一筋縄ではいかないことが理解していただけたと思う。
 では専用線や広域イーサネットなどを利用したほうが良いのであろうか?



はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: LGWAN, セキュリティポリシー, LASDEC, 総務省, 厚生労働省, セキュリティ,
 例の「未定稿」がようやく公になった。
 21日の夜間に全国に公開されるや否や、翌日22日に即差替えという混乱ぶりである。
 変更点は住基ネット外字、いわゆる統一文字コードの利用にかかる部分であり、直前まで総務省との調整が難航していた様子が見て取れる(いや、もしかするとまだ調整中かもしれない)

 21日版に統一文字コードの記述が無いことに気づいたときは正直めまいを覚えた。
 失意のうちにその資料を多量コピーしているときに、22日版のメールが転送されて筆者のパソコンに届いたのである。

 ここで、筆者は厚労省の担当者に二言ほど言いたい。

 1.調整お疲れ様。さぞ苦労されたことと推察します。
 2.紙代カエセヨ(・∀・)コラ!! 21日版たくさん印刷しちゃったじゃないか。

 冗談はさておき、ようやくこのblogでも心置きなく言及することができるようになった。
 せっかくなので数回に分けて中身を見ていきたい。



1.本書の位置づけ
 省略

2.前提条件

2.2 システム構成に関する前提条件
 ざっと見た限り、全般的にハイスペックである印象を受けた。平成23年のレセプトオンラインの時期のリプレイスを見込み、それまでの使用に耐えうる内容と見るのが妥当だろう。
 とはいえ、サーバはともかくWebシステムの端末がこれほど高性能である必要はあるのか?やや疑問である。
 (後ほど触れることになるが、端末についてはWebシステムとしながらも専用端末を想定している。Webシステムで端末性能がボトルネックになるというのは考えにくい。文字通りの専用であるならば、さほど高い性能は必要ないのではないか)

 ソフトウェアのベースは、Win2003+Oracle10gである。UNIXでなくて大丈夫なのであろうか?
 他のソフトの細かい仕様は現段階では示されていないが、他ベンダへの牽制としてJP1やコネズミ…じゃなかったコズミネクサスあたりのミドルウェアをねじ込んでくることは容易に想像がつく。「N」や「F」は頭が痛い部分であろう。
 端末のOSはXP。Vistaは見送りである。

 ネットワークについてはLGWAN前提であるが、それ以外の独自回線も可能である。ただし仕様についてはLGWAN前提で記載されているため、見直しが必要になる可能性がある。
 LGWAN+他回線の混在は不可。確かに運用保守面から混在は避けるべきだろう。

 構築、保守、運用については資料に含まれないし、またサーバが占有するスペースについても言及されていない。
 これらは個別に見積や調査等の対応が必要になる。

 なお、概算費用算出表は国保中央会のHPからダウンロードできるが、内容については未定稿と矛盾する部分もある。(市町村窓口サーバのバックアップソフトの有無等)
 まあ、高めに見積もっておけ、ということなのだろうか。

 広域連合サイドのサーバ設置場所であるが、LGWAN利用に大きく影響するので留意されたい。
 広域連合が自前でセキュリティ設備が整ったサーバ室を確保できるのならばともかく、業者のIDCを利用する場合、その業者がLGWAN-ASPサービス提供業者でなければLGWANには接続できない。
 LGWAN-ASPサービス提供業者の一覧については、LASDECのホームページで確認できる。

 そして当たり前であるが、広域連合サイドのセキュリティポリシー策定が必要になる。

 ここで提言したいが、広域連合サイドでの導入にあたってはコンサルをつけることを強く推奨する。
 コンサルにあてる当年度の予算がないのなら、プロポ形式でベンダやインテグレータを選定しても良いだろう。
 ともあれ、事務局職員がシスアド(+情報セキュアド)とテクニカルエンジニアの精鋭集団であるのならばともかく、素人がこの資料だけを元に競争入札の仕様書を起こすのは不可能に近い。

2.3 インターフェース仕様に関する前提条件
 漢字文字については住基ネット統一文字コード、住所については全国住所辞書コード、金融機関情報については全銀協コードである。
 統一文字コードについては、「市町村住基システム→住基ネット」で用いている変換の仕組みをそのまま流用できれば話は早い。とはいえ、個人情報関連の審議会や「偉い人」に、住基ネットとは直接関係無いことを説明するのは骨が折れる作業になるだろう。

 個人番号については、各市町村で一意なのか、広域内で一意なのか不明瞭である。桁数については16桁と十分に見えるが、このうち何桁かが市町村番号的に充てねばならず、実際にはより少ない桁数しか利用できないとなると、各市町村で対応できなくなる可能性がある。

 市町村と広域間のデータ転送については、面倒なポリシー調整がいろいろと必要になるであろう。
 例えば筆者の市のポリシーでは、中から外は比較的甘いが、(特定のプロトコルを除き)外から中は相当厳しい。広域から本市へのデータ転送は全てダメである。
 そのため、中から外へ定期的にデータを取りに行く仕組みを構築する必要がある。(この費用は誰が負担するのか?)
 もちろん、外部からの遠隔監視や遠隔操作も全てダメ。本市に限ってはJP1を導入する意義は全く無い。
(LASDECが定めるLGWANのFWプロトコルも同様の制約があるということを聞いたことがあるが、そこらへんは大丈夫なのであろうか? 筆者の勘違いならば良いのだが…)

 開発を手がける「この木何の木」さんには、そういう自治体もあるということを是非認識しておいていただきたい。

 そうそう、ある都道府県では税業務が電算化されていない自治体もあるとか。
 日時夜間バッチが始まるまでに、その役場の職員がオンラインで税情報をポチポチ入力するのであろうか?
 ここらへんのケアも是非怠らないようにしていただきたいものである。

2.4 カスタマイズ
 カスタマイズ用のDBを用意してやるから、本体はいじくりまわすな、というスタンスである。
 果たして十分な内容と種類のDBが用意されるのか、少々不安である。

(続く)

** 追記 **

12月1日 ミドルウェアの名前が間違っていたので修正しました。(×コズミネクス→○コズミネクサス)

はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: 住基ネット, 外字, LGWAN, 国保中央会, 広域連合, セキュリティ, インターフェース,

ナビゲーション

特集記事

カテゴリー

ブログ内検索

RECENT ENTRYS

RECENT COMMENTS

RECENT TRACKBACKS

プロフィール

現職公務員SE Author:現職公務員SE
 シスアドでセキュアドな後期高齢者医療制度SNS管理人。
 後期高齢者医療制度の資格事務担当だったはずがひょんなことで電算担当に。

HSタグクラウド

Feed Me!

公務員叩きに物申す!-現職公務員の妄言のRSSフィード

後期高齢者医療制度開始カウントダウン





リンク

中の人

FC2カウンター


公務員サイトランキング 現職公務員サイトランキング ビジネスブログランキング 人気ブログランキング - 公務員叩きに物申す!-現職公務員の妄言

スカウター : 公務員叩きに物申す!?現職公務員の妄言 はてなブックマークカウンター
  • seo

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。