NW屋的日常徒然日記

ネットワークを専門にする元社内SEの日常とITネタ諸々を綴って行きます。

今月のPVが10,000を突破しました<(_ _)>

 こんばんは。先月に引き続き、今月もめでたく10,000PV突破いたしました。これもひとえに読者の皆様方のおかげです。本当にありがとうございました。<(_ _)>

 はてなでは今月のPVが100、1,000、10,000(100,000や1,000,000もあるんでしょうが、お目にかかれることは普通ないでしょうね。(^^;)を達成すると、こんな風に表示されたりします。

f:id:amagasaki820:20180224212724j:image

 100や1000の場合でもそうですが、達成直後に表示されるわけではなく、半日ぐらいタイムラグがあるみたいですね。先月は31日午後に10,000突破しました。その関係もあって、残念ながら上記のような画像にはお目にかかることが出来ませんでした。

 最近はコンスタントに日々のPVが増えていて、たいへんありがたいことです。直近では東大病院電子カルテネタで検索流入が結構ありました。書いた記事がすぐに反応があるわけではなく、ちょっとしてから読まれるということもあるようです。その前は、福岡大学のNTPサーバに関する記事を書いた際にPVが増加したということがありました。

 基本的には自分の興味・関心のあるネタを追って書いて行きます。以前関わっていたこともありますので、医療情報ネタだと割と差別化出来るのではないかと考えております。

 これからも精進してまいりますので、今後ともお付き合いの程宜しくお願いいたします。

SPFネタが伸びていたので小ネタを少々

 こんばんは。昨日は急にPVが伸びていて驚きました。「SPFの記事を書いたから伸びたのかな?」と思ったのですが、どうもそういうことではなかったようです。後で調べてみたら、東大病院電子カルテ問題が日経xTECHで日経コンピュータの記事として取り上げられていたことが影響していたようです。

 この記事が有料だったので、会員でない方がこのブログ記事を覗いていただいたのかなと推測しています。このブログ記事も少し前の日経xTECHの記事をベースに自分なりの見解を示したので、そのへんも影響しているのでしょうか。

 今回はSPF関連の小ネタを書いてみようかと思います。(と言っても、そんなに大したネタではありませんが。(^^;)

 SPF登録ですが、送信メールサーバの宣言だけなら、DNSサーバのゾーンファイルにTXTレコードで記述しておけばよいです。簡単ですが、これでは自組織にとってはさほどメリットはありません。「受信側とセットで導入してなんぼ」と考えるのが正しいです。受信側はPostfixSPF対応モジュールを組み込みます。その場合、必ずPythonで書かれたモジュールを使って下さい。Perlだと設定ファイルがないので細かいチューニングが出来ません。

 導入して本当に良かったなと思ったのが、以前の職場で全職員向けML(メーリングリスト)アドレスに自組織ドメインのメールサーバではないサーバから送信されたメールが届きました。さらに、送信者アドレスを自組織構成員のメールアドレスにして送信されました。MLソフトだと送信者アドレス(From:フィールド)しか見ず、送信メールサーバまでは確認しません。そのため、受信してしまうのですが、全構成員に迷惑メールが届いてしまいます。

 そこで、送信メールサーバを宣言すべく、DNSサーバにTXTレコードで記述しました。softfailではなく、敢えてfailで記述しました。PostfixPythonで書かれたモジュールを組み込んで判定させるようにしました。その際、fail判定なメールは容赦なく落とすようにしました。それにより、この迷惑ML宛メールを受信拒否することが出来ました。

 これを自力でやったのですが、影の苦労を理解してもらえなかったのでした…。orz

総務省からSPF導入に関する統計資料発表

 こんばんは。先日、総務省から各組織のSPF及びDMARCの導入率について公表されていました。ScanNetSecurityとSECURITY-NEXTの記事からです。

scan.netsecurity.ne.jp

www.security-next.com

 後者の記事では「半数弱」とありますが、前者の記事の表(画像)を見ると、ドメイン全体を分母にするのか、MXレコードを有するドメインを分母にするのかで変わってきます。MXレコードを持たないので、メール送信・受信をしないことを明示的に宣言しているドメインも存在します。そう考えると、前者(ドメイン全体)を分母として考えるのが妥当です。そして、分子は全ドメインにおけるSPF設定数に設定するのが妥当であると考えられます。

 そうすると、SPF設定を行っている組織の割合が41%程度になります。SPFを設定するのは、「うちのドメインではメールを送信しません!」とか、「うちはこのメールサーバからしかメールは送信しません!」と宣言するケースがあります。そして、「うちはDNSサーバでSPF設定をしてますし、受信時もメールサーバでSPF判定しています」という組織も多いかと思います。

 また、少ないかもしれませんが、「うちは宣言はしないけども、SPFを用いてメールサーバでSPF判定はします」というケースもあるかもしれません。

 単に宣言だけであれば、DNSサーバのTXTレコードに記述するだけでいいので、比較的ハードルが低いことも作用しているのかなと考えられます。

 そして、DMARCについても考察してみます。こちらは0.5%程度になりますね。こちらも(全ドメイン中のDMARC設定ドメイン数)/(全ドメイン)*100で計算します。

 こちらはSPFに比べると、まだ浸透してないということなのでしょうか。まずはSPFの普及ということかなという気もします。

 それにしても、goドメインSPF導入率はぶっちぎりですよね。

なぜかセルラータイプのiPadを導入して保護者に費用負担を求める中学校

 こんばんは。今回は学校のICT化に関連する話題です。TL上にセルラータイプのiPadを導入して、高額な負担を保護者に強いるというツイートを見かけました。これに関する反応をまとめた炎上速報の記事です。

enjou-sokuho.com

 今までも小中高校にiPad(を含むタブレット)導入という事例は複数見かけました。しかし、その多くが導入効果に疑問を呈するケースが多かったです。「とにかく導入ありき」で進められたとしか思えない事例も少なくありません。教育委員会が導入を決めて、後は現場に丸投げだとか、導入を請け負ったベンダがあまりにもお粗末なネットワーク構築・設計・運用だったという事例も事欠きません。orz

  「貸与端末」とあるのに、タブレット管理費として年間37,000円弱の費用。7GB/月とありますが、これなら格安SIMを用いれば、もっとコストを抑えることが可能なはずです。この記事内の資料にはSoftBankとあります。他にClassi関係の管理費も年間7,800円徴収されます。

 その上、MDMで端末のアクセスコントロールまで実行するわ、ある程度の情報(どこまでかは不明)がSoftBankに吸い上げられるというあたりもなんだかなぁと思う次第です。

 これだけの負担を強いる学校側というのもどうかと思います。SoftBankとClassiの営業に乗せられたのかな?という気がしてなりません。往々にしてITに明るくないのが小中高校の学校だったりします。ITのプロがいないために、自分たちで判断出来ず、ベンダ側の言いなりになってしまったのではないかと見ています。

 普通に考えれば、校内に無線LANを整備して使わせるところだと思います。なので、Wi-Fi専用機を選択することになるはずです。セルラータイプを選択した(させられた)のは、Wi-FiではSoftBankにとって旨味がないからだろうというのが容易に想像がつきます。いろいろ疑問の残る事例でした。そこまでしてセルラータイプのiPadを導入しなくてはいけないのでしょうか?

 「学校ICT」というキーワードに安易に飛びついて、高い買い物をさせられるのは保護者です。強制することになるのにも関わらず、学校側は「自分の懐が痛まないから」と、高い管理費を保護者に負担させるのはNGではないでしょうか。

iOS11.2.6がリリースされたのでアップデートしてみました

 こんばんは。総務省からSPF導入等に関する統計資料が出ていた件について書こうかと思ったのですが、まだじっくり読めてませんので、一両日中に記事にする予定です。少々お待ち下さい。

 今日はショートバージョンになりますが、iOS11.2.6がリリースされましたので、その点について少しだけ。

 特定の文字列を入力するとクラッシュするとか、特定アプリで外部アクセサリに接続出来ないという問題を解消したアップデートのようです。他にセキュリティフィックスもなされているようです。

 他にmacOSもwatchOSもtvOSもアップデートされていますので、こちらも可能な限り早目にアップデートされることをお勧めします。私は先ほどiPhoneSEとiPad mini 4をiOS11.2.6にアップデートしましたが、今のところ特に問題はありません。

 ということで、今日は短めで失礼いたします。<(_ _)>

東大病院電子カルテ問題のその後(3)

 こんばんは。今日はショートバージョンになる予定ですが、もう少し東大病院電子カルテ問題について考察してみようと思います。

 先日、ITproが取材した記事などを含めて、こちらの記事を書きました。

karasuma-kitaoji.hatenablog.com

 ベンダ側だけでなく、病院側にも問題はあったんだろうということは察しがつきます。独自開発電子カルテ→パッケージ版電子カルテへの移行ということも大きな要因としてあったのだろうと推測されます。そして、リハーサルや変更点に関してのユーザ向け説明会に関する時間があまり取れなかったのだろうという点も想像がつきます。

 それ以外の問題として考えられるのが、「単年度予算の弊害」なのではないかと見ています。

 このへんは官公庁・独法だと、全ての機関が抱えている問題なのではないでしょうか。年度ごとの予算を組んでいます。4月1日から始まって、3月31日で終わるという仕組みで、翌年度に繰り越せません。

 で、こいつが曲者です。検収もありますので、「3月31日時点で全て完了していて納品された状態であること」が大前提になります。4月1日以降に引っ張れないという大きな問題があります。

 つまり、かなり強引な突貫工事が発生することも考えられます。決して全てを否定するわけではありませんが、こういう問題も背景にあったのではないかと考えています。

 しかし、「システム更新は年始だったじゃないか!」というツッコミも聞こえそうです。「混乱を招きやすい新年度にシステム更新を持って来たくない」「時間の確保出来る年末年始に持ってきたい」「実際のシステム導入と検収までのバッファを見ておいて、何かあった場合の微修正を行う時間を確保したい」ということもあったのではないかと推察しています。

 そして、「年度を跨るシステム導入が単年度予算の壁の存在で難易度が高い」ということも考えられそうです。事前調査やヒアリング・システム構築・説明会・リハーサル・勉強会等、様々なイベントを行うための時間を考えると、慎重かつ丁寧に行おうとすれば1年では足りないということも起こりそうです。その場合、名目を変えたりするんでしょうか。(想像の世界ですが)

 年度毎に別項目で入札すると、異なるベンダが落札したりするようなことが起き得そうですが、その点はどうなのかな?とふと思いました。

飲食店での「ドタキャン防止システム」がリリースされるそうですが

 こんばんは。昨年夏に話題になった「飲食店でのドタキャン対策としてのデータベース構築」ですが、先日、「ドタキャン防止システム」として今月19日に運用開始されるそうです。こちらはキャリコネニュースからの記事です。

news.careerconnection.jp

 昨夏の時点で懸念されていた問題点「番号を騙られて伝えた場合」や、「ドタキャンした客が当該番号の契約を解除して、その番号が無関係の第三者に割り当てられた場合」や、「契約者の知らないところで勝手に番号を勝手に伝えられた場合」など、その番号が本当にその人の番号であることを常に確認出来るのか?データベースを最新の状態に保持出来るのか?という懸念に関しては、「お客様の申請を基に確認が取れ次第、削除する」とあります。ここで言う「お客様」とは、一体誰のことを指すのでしょうか?ドタキャンした客が「もうこの番号は使ってないから削除して」と一々連絡してくれるのでしょうか?それとも、新しい番号を割り振られた客が申請するのでしょうか?

 それに、電話番号をデータベース登録して第三者提供した場合、個人情報保護法の観点からはアウトになると思います。

 いずれにしても無理がありそうです。「電話番号だけだから、個人情報に当たらない」も無理筋な印象です。そして、「電話番号だけを頼りに判断するのは拙いのではないか?」とか、上述の「番号を騙られて伝えた場合」のような問題もあります。このあたりについては、togetterのまとめにもありますので、そちらを参照していただいた方がいいと思います。

togetter.com

 と、予約キャンセルデータベースに関しては、昨年7月に書いた記事の方も御参照下さい。

karasuma-kitaoji.hatenablog.com

 飲食店側も予約時に30%ぐらいの予約金を取るとか、キャンセル料を取るとか、ネット予約の場合はクレジットカードでの支払いとするとかいう風な形にした方がいいんじゃないかと個人的には思います。

 と、このシステムを「未来永劫利用料無料にする」と別の記事に書かれていましたが、データベース維持管理コストをどうやって確保するのか?という疑問が残ります。このあたりについて触れられていませんが、金額的にも馬鹿にならないような気がしているのですが、実際のところどうなんでしょうか???