2018/07/18

本人へ確認のない「誕生日」開示について

 「誕生日」を、本人への確認なくカジュアルに開示する認識、なんとかならんものか。
 「面白みのない奴」と思われても、これは常々思う。

 世間一般では、「生年月日」は本人認証の一要素にされている。
 それの是非についても言いたいことはあるのだが、それはそれでそうなってしまっているのだからしようがない。であるのだから、「誕生日」の開示(あまつさえ本人への確認なく)には慎重であるべきだ。

 「生年月日」は個人情報だが、「誕生日」は単なる「月日」で自ずから個人情報ではない…という意見を開陳しているページも見かけるが、それは詭弁だろ。
 なんとなれば、「誕生日」…つまり「月日」が判明すれば「年」の類推はそれほど難しくない。例えば、外見等から「40歳前後」くらいが判れば、数年の幅を持たせば正解にヒットする。数年…つまり、たったの数パターンだ。
 対して「誕生日」のパターンは 365パターンだ。自ずから重要性は明らかだろう。

 念の為、誕生日を知人縁者へ教える(場合によっては SNS で公開する)ことを論難しているのではなく、「本人への確認なくカジュアルに開示する」ことについて述べている。
 会社で社員間の親睦のために開示するというのも良いだろうが(それはそれで大切で意義あることだが)、当然のように行うのではなく、先立って本人への確認はするべきではないか。

2018/06/25

お名前.com の「ドメインプロテクション」機能を調べてズッコケた

 Google Domains へ引越してお名前.com とは手を切ったので、後は野となれ~なんだが、気になってちらっと調べてみた。

 今更ではあるが、レジストラ(ドメイン管理)サービスなんていうのは、基幹中の基幹であるのは言うまでもない。レジストラのアカウントが奪取されたら、whois 書換放題 = ドメインハイジャックし放題な訳で、上のレイヤでセキュリティをいくら固めていても全部ひっくり返されてしまう。
 なので、レジストラのアカウントというのは、最重要アカウントとも言える。

 なのだが、お名前.com のアカウントは、未だ二要素認証に未対応。
 有り得ないなぁ…と思っていたが、お名前.com も流石にどうかと思ったのか「ドメインプロテクション」なる機能を考案していた。

ドメインプロテクション - お名前.com

 ふむふむ、ドメインに対してクリティカルな変更が加えられた場合、登録したメールアドレス宛に承認要求のメールが飛ぶという仕組みか。
 なんとも泥臭い方法だし、そもそもログイン認証がザルだというのは如何なものか。まぁ、とはいえ一歩前進か…と思って読んでいたら…

「1ドメイン980円(税抜)/年」

 はい?
 有料サービスなんかいっ!!

 ほんともうズッコケたよ。
 当然備えていて然るべき機能(しかも不完全な)で金取るのかね。
 しかも、ドメイン維持の本体費用に匹敵するような金額を。

 最近まで(不承不承とはいえ)利用していた身が何をか言わんやだが…お名前.com、今や「情弱向けレジストラ」の様相を呈しておりますな。

2018/05/15

グループポリシーへ「Encryption Oracle Remediation(暗号化オラクルの修復)」の追加方法

2018 年 5 月の更新プログラム適用によるリモート デスクトップ接続への影響 - Microsoft Technet

 2018年 5月の Windows Update で、リモートデスクトップ(RDP)周りのセキュリティ強化があって、接続できないサーバーが続出。
 まぁ、サーバーも Windows Update を適用すれば問題ない話なんだが、現実問題そうそう簡単にできるものではない。

 というわけで、姑息(本来の意味)な解決方法を取ることにした。
 グループポリシーで以下の設定をクライアント側へ施せば(当然セキュリティレベルは「脆弱」になるものの)、取り敢えず接続できるようになる。

----------引用ココから
[コンピューターの構成]
-> [管理用テンプレート]
-> [システム]
-> [資格情報の委任]

ポリシー名 : Encryption Oracle Remediation (暗号化オラクルの修復)
設定 : Vulnerable (脆弱)
----------引用ココまで

 しかし、このポリシー項目、一覧に表示されないのだ。
 ローカルグループポリシーであれば、問題の Update を適用すれば追加される(そりゃ問題の Update が未適用なら不要な項目なんだから)。しかし、ActiveDirectory 側のグループポリシーにはどうやって追加すれば…?

 はい、以下のグループポリシーテンプレートを ActiveDirectory 側へ追加すれば OK だ。

Administrative Templates (.admx) for Windows 10 April 2018 Update (1803) - Microsoft ダウンロードセンター

 グループポリシーテンプレートの利用方法は以下。
 最初に書かれている方法より、後に書かれている「セントラルストア(中央ストア)」を使う方法のほうが楽かな。

Windows 10でグループポリシー設定を利用するには - @IT

 これで ActiveDirectory 側のグループポリシーにも追加されて、そちらで一括適用。
 メデタシ、メデタシ。

 ………本当に「メデタシ」なのは、サーバー側へ最新の Update を適用してからなんだが。

2018/02/26

Microsoft Excel が決定的に劣る点

 Google スプレッドシートと比較して、Microsoft Excel が決定的に劣る点。
 長年のウィークポイントであった同時編集については、Office 365 でほぼ挽回しているようだし、今回ツッコむのはその点ではない。

 ズバリ、Microsoft Excel は「行列の削除ができない」。

 なんのこっちゃ、という人もいらっしゃるやもしれないが、試しに Microsoft Excel で「空白のブック」(新規ワークブック)を開いてもらいたい。
 そして、ワークシートで最大行列のセル(一番右下のセル)を選択する。[Ctrl]+[↓] と [Ctrl]+[→] でキー操作すると早い。行は「1048576」、列は「XFD」になっているはずだ。
 その上で、適当な行や列を「削除」してみる。行や列を選択して、右クリックのプルダウンメニューから [削除] を選択する。しかし、表示されている最大行列のラベルは「1048576」と「XFD」のままだ。
 言うなれば、選択した行列の削除はされているのだが、域外から削除されたのと同数の行列が追加されている。つまり、ワークシートの行列数は増減しない。
 これが「行列の削除ができない」の意味。

 Google スプレッドシートの場合は、削除すれば普通にその分行列は減る。
 実に単純だ。

 一見どうということもない違いではあるが、さに非ず。Microsoft Excel はワークシートの全体像を明示できないのだ。
 見えている範囲の表や数値で全てかと思っていたら、極端な話 XFD1048576 のセルにデータが入っているかもしれない。それは実際に調べてみないと判らない。
 確かに [Ctrl]+[End] で「最後のセル(右端の使用されている列の、最も下の使用されている行のセル)」へ移動できるので、それで確認はできるが、そうやって意図的に調べないと判らない。
 削除できないのなら非表示にするという手もあるが、「見えていないだけで実体としては残っている」というのは混乱の種になるだけだ。

 対して Google スプレッドシートの場合、不要な行列をバッサリ後腐れなく削除しておけば、シートの全体像は一目瞭然になる。
 実に明瞭だ。

 Microsoft Excel はバージョンを重ねても、この辺りの仕様が改善される気配はない。
 おそらく高邁なる設計思想に基いているからなんだろうが、それだけにこれからも「決定的に劣る点」として残り続けるだろう。

2018/02/21

ソフトバンクのキャリアメール、運用ポリシー変更した?

 ソフトバンクのキャリアメール( @softbank.ne.jp )、SMTP Server の運用ポリシー変更したのかな。
 先週金曜日(2018/02/16)から、突然「dsn=5.0.0, stat=Service unavailable」で受取拒否されるようになった。もちろん全部が全部ではいものの、以前はほぼ皆無だったんだが…。

 しっかし、キャリアメールは昔から頭痛の種なんだよな。
 早く絶滅せんものか。

 今さら言うのもバカバカしいが、こういうキャリアメールの "特殊処理" は「eメール」として普通じゃない。諸般の事情があるとは言え、送ったメールが常態的に届かないなんて、実用サービスの体を成してないだろ。
 SMTP Server の運用は各組織のポリシーに委ねられている訳だが、当たり前のようにこんな "特殊処理" を常態化させているサービスは、理の当然として淘汰されるべきだろうな(実際利用者は右肩下がりらしいので喜ばしいこと)。

2018/02/20

e-Tax のインフラは Akamai

 e-Tax って、Akamai(※)のネットワーク使って展開してるんだ。
 今更ながら、「www.e-tax.nta.go.jp」を正引&逆引して気が付いた。

 さらにフロントエンドのみならず、バックエンド側も Akamai のネットワークでかためている模様。

※:
アカマイ・テクノロジーズ - Wikipedia
世界最大手の CDN業者。本社米国。

 何だかなぁ。これは一納税者として納得いかん。
 国家事業なんだから、安全保障上からも国内産業育成からも、国内の業者に任せるべきだろ。
 余分に金を積んででも、IIJ 辺りにやらせて欲しい。

2018/02/19

G Suite グループでは配信不能レポートは配送できない

 G Suite(旧 Google Apps)のグループ(ML、メーリングリスト)では、SMTP Server からの配信不能レポート(エラーメール)は配送できない。

Google グループに関するよくある質問(管理者向け) - G Suite 管理者 ヘルプ
----------引用ココから
グループに送信できないメールの種類はありますか?

「返送メッセージ」とも呼ばれる配信不能レポート(NDR)をグループに送信または転送することはできません。NDR に似ているメッセージも、送信や転送はできません。
----------引用ココまで

 この仕様、つい忘れて毎度「???」となってしまう。
 単に「できません」としか書かれていないが、具体的な動きとしては配信不能レポートを dsn=2.0.0 で受取った上で、何処へ何も残すことなく(グループの管理画面にも痕跡を残さず)暗黙の内に破棄してしまう。

 グループアドレスを代表にして、それを使ってチームで顧客対応をしたりする場合。つまり、各メンバはグループアドレスを From にして顧客へメール送信し、顧客にはグループアドレスへ返信してもらう(自動的にグループメンバでシェア)という運用の場合、問題が出てくる。
 顧客のアドレスを間違って入力した場合(またはアドレスが既に存在しない場合)、普通は User Unknown で配信不能レポートが戻ってくるので直ちに気がつけるのだが、この場合 G Suite のグループは配信不能レポートを飲み込んでしまうので、それに気が付けない。これは困る。

 回避方法としては、グループを使うのではなく G Suite の実アカウントを使って転送設定するか、「デフォルトの転送の設定」を使って転送設定するか…辺りか。
 前者はユーザレベルでもメンテナンス可能(メンバの追加/削除が可能)だが、実アカウントを使う関係上コスト増になる。もちろん個別にアカウントを用意せずとも、個人アカウントで併用するという手もあるが…さらに管理が面倒になる。
 後者はメンテナンスが管理者に限られる上、クリティカルな作業になってしまう(下手するとドメイン全体のメール配送に悪影響が及ぶ)。メンバの追加/削除ごときで、毎度々々そんなところをいじってられない。
 どちらの方法にしても、非常に整備性が悪い。

 G Suite というのは優秀なサービスなんだが、こういう割り切って使わなくてはいけない仕様が所々ある。
 まぁ、何でもトレードオフということなんだろうが…。