日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

<< 過去

電池をとるか、指紋認証をとるか

スマートフォンの買い換えを考えている。

今使っているAndroid One S3は、ストレージ容量不足に対応して購入したものだった。

USB PDで急速充電OKのはず

安かったのはよかったが、当初から性能面では問題だろうと思っていた。

ストレージ容量の問題が解決したことで、ゲームで遊ぶ時間が増えてなおさら問題になってきた。

もともとつなぎとして購入したような面はあって、1年経たずに買い換えること自体は妥当だろうと。


それでY!mobileのWebサイトを見ていると、秋から冬にかけて新発売の端末リストが出ていた。

2019 AUTUMN & WINTER NEW COLLECTION (Y!mobile)

SONY Xperia 8、ZTE Libero S10、Android One S6(京セラ)、Android One S7(SHARP)が並んでいる。

あと、すでに8月から販売されている HUAWEI P30 lite、この5つがY!mobileの商流で買える端末かなと。


搭載されているチップからCPU・GPU性能はだいたい想定できて、

Xperia 8 と Android One S7 は同じSnapdragon 630、Libero S10はSnapdragon 450なのでそれより性能は劣る。

Android One S6はMediaTek Helio P35で、Snapdragon 630と同じぐらいだが少しよいかもしれない。

P30 liteはこれらのチップを積んだ端末よりはるかに性能が高いようである。

とはいえ、現在使っているAndroid One S3と比べると、Libero S10以外は大幅な性能向上であろう。


それ以外の特徴を見てみると、似たり寄ったりだが、少しずつ違う。

まず、NFC/Felica対応はXperia 8、Android One S6、Android One S7 の日本メーカーの3つが対応。

ちなみに今のAndroid One S3はNFC/Felica非対応である。

次、電池容量、ほとんどが3000mAh前後だが、Android One S7は4000mAhという大容量の電池を積んでいる。

「1週間の電池持ち」と書かれているが、さすがに1週間持つのはほぼ待ち受けに近い場合だが、

電池容量の多さと、IGZO液晶を搭載して画面の消費電力を抑えたということで、電池持ちはよさそう。

この辺、SHARPらしいなと思う。Android One 507SHのときも電池はセールスポイントだったし。

指紋認証、いまどきは標準搭載なのかと思って見ていたら、Android One S7 だけ付いていない。

指紋読み取り部は、Xperiaは側面、他は背面のようだ。背面が多数派なのか。

ストレージ容量は Xperia 8 と P30 liteが64GB、他は32GB、いずれもmicroSD対応。

今までの実績だと32GBあれば足りないことはないかな。microSDが併用できるのは前提だけど。


ここまで見てきて思ったのは、やはり電池という面でAndroid One S7はいいなと。

サイズ感もこの中では長手方向の長さではもっとも小さく、その点でも僕の希望とマッチしている。

ただ、唯一気になるのが指紋認証に対応していないこと。

SHARPのWebサイトを調べてみると、Y!mobile向け以外では AQUOS sense3 として発売する製品に相当するようだ。

ただ、スペック面では差があり、AQUOS sense3は外向きのカメラが2種類付いているのに対して、

Android One S7は1つ、この点については楽天モバイル専売というAQUOS sense3 lite と同じ特徴である。

ストレージ容量が64GBに対して32GB、そして指紋認証は他がありでAndroid One S7は なし となっている。

楽天モバイル専売のAQUOS sense3 liteは、ここは64GBで指紋認証ありなので、それとも違うという。


指紋認証いるか? というところは悩み所である。画面ロックだけなら別になくてもとは思う。

ただ、HUAWEI MediaPad M5に指紋認証がついていて、確かに便利ではあるんだよね。

最近、Googleパスワードマネージャーでパスワードの管理をさせるようになったわけだが、

Chrome以外でパスワードを使うときはパスワードのコピペが必要で、

そのためには、Androidでは端末の画面ロック相当の認証が必要になるが、指紋だと煩わしくない。

あと、FIDO というパスワードレスログインがこれから普及しようとしているが、

スマートフォン+生体情報というのがもっとも普及しそうな方式で、そこで指紋が使えるか使えないかは大きな差かなと。

FIDOってだけなら、スマートフォン+PINコード とか セキュリティキー というのもあるんですけどね。


まぁY!mobileの商流にこだわることはなくて、他の方法で買ってもいいんですよね。

Y!mobileから買う方が有利なことはあるが、SIMフリーの端末を購入するのもそんなに不利なわけではない。

AQUOS sense3はAndroid Oneとそう変わらなくて、発売後2年間で最大2回のOSアップデートをすると言っている。

いろいろ調べた限りではAndroid Oneと同じような感じで、少しSHARP独自アプリが入ってる程度なのかなと。

Android Oneで慣れているので、指紋認証付きAndroid One S7だという考えもある。(価格も大きく変わらんだろう)


もう1つ選択肢に入りうると思っているのが HUAWEI P30 lite である。

HUAWEIはMediaPad M5で使ってるから、いろいろわかってきたが、基本的にはいいと思う。

ただ、設定でHUAWEI独自色が強いのが気になったり、すこし性に合わないところもある。

画面上部に設けられたノッチも気になってしまう。これは慣れかもしれない。

あと、FIDOについては、なぜか みずほ銀行 のアプリではHUAWEIダメみたいね。これはようわからん


Y!mobile以外から購入する場合、基本的にはUSIMカードを差し替えれば終わりなのだが、

NFC/Felica対応の端末の場合、今使っているn111というタイプのSIMはNFC用のIDが入っていない。

ご丁寧にもAndroid One S3への買い換えのときに、n101(NFC対応)からn111へ交換されちゃったのね。

HUAWEI P30 liteのように、NFC非対応の端末なら、それはそれで関係ないことである。

とはいえ、NFCを使う時だけの問題で、NFCを使わないならn111のままでもいいし、後で交換してもかまわない。

SIM交換については、Y!mobile店舗で「機種変更」を申し出れば、3000円(本体)の手数料でやってくれるそう。

これは店頭でY!mobile取扱端末を購入する場合と同じ手数料である。(オンラインショップではかからなくなった)

そんなところで総合的に判断するのかなと。今までの実績だとY!mobileでAQUOS sense3の取扱はないでしょうし。


Author : Hidemaro
Date : 2019/12/09(Mon) 23:22
コンピュータ・インターネット | Comment | trackback (0)

暗号化されているかいないか

職場で使っているPCは基本的にはレンタル品だが、一部には自社所有のものもある。

といっても、特殊なスペックのコンピュータか、レンタル品を現品で購入したものかどちらかなんだけど。

Windows 7 PCを買ってWindows 10を入れる

こういうこともやってるんですね。


上司が部署のセキュリティについてのチェックリストを確認していたときに、

レンタル品ではないPCに「部署管理品」というシールが必要なのではないかという指摘をしてきた。

これ、以前も気になって調べたのだが、実はこのシールの対象はノートPCだけなのである。

しかも、レンタル品ではないノートPCの全てにこのシールが必要なわけではないのだという。

実はこのシールにはある目的があったのである。


それがストレージの暗号化である。

どうも会社のルールでは、ノートPCは原則としてHDDなどのストレージを暗号化しなければならない。

これは社外に持ち出すストレージには原則として暗号化が求められていることに対応している。

今ではレンタルPCはストレージの暗号化設定がされた状態で納入されていて、

起動時にパスワードを入力することを除いて、暗号化を意識することはない。

ただ、過渡期には後付けで暗号化を導入する必要があったようで、その識別用のシールがあった。

暗号化設定がされたものは対策済みシールを貼り、暗号化対策しないことを認めたものは「部署管理品」シールを貼っていたようだ。


それも今は昔、レンタル以外でノートPCを調達することはほとんどないだろう。

古い開発環境を保持する目的で暗号化がなされていないノートPCがある可能性はあるけど、

暗号化導入後のレンタルPCを買い取ったとすれば、それもそれで問題はない。

再確認はするべきだけど、そもそも「部署管理品」シールの対象になるPCは少ないだろうな。


ただ、この背景を知ったときに、あれ? と思ったことがあった。

それがデスクトップPCはストレージの暗号化をしていないということ。

ノートPCであれば(実際に持ち出すかはともかく)、社外に持ち出される可能性を想定して原則暗号化と言っている。

暗号化されていないPCには識別用に「部署管理品」のシールを貼りなさいと言っている。

これがデスクトップPCになれば、社外に持ち出されない想定なので、暗号化も原則やらないし、識別シールも貼らない。

でも、実際には製品評価の目的で社外にデスクトップPCを持ち出すこともあるんだよね。


今まで、社外にデスクトップPCを持ち出す案件に関わったことはあるが、暗号化が求められたことはない。

原則暗号化というけど、技術的に暗号化できないとかいうなら、搭載されているデータを精査するなどして持ち出すことが認められることもある。

「部署管理品」シールが貼られていても、必ずしも社外持ち出し禁止ではないということはQ&Aにも記載されていた。

実際、製品評価のために持ち出すPCにセンシティブなデータはほとんど含まれていないと思われる。

ノートPCに比べれば置き忘れのリスクは低い。(輸送手段もチャーターのトラック便が多い)

信頼がおけると考えている試験場に設置して使われるので、他人が触れるリスクは低い。

ここら辺を総合的に考慮すれば、暗号化せずともOKという判断は成り立つが、そこまで熟慮されたかは疑問もある。


それで気になって、先日、レンタルの現品を購入したデスクトップPCのBIOSを確認してみた。

そうしたら、BIOSの設定項目に HDD Password という項目があるんですね。

HDDを抜き取っても、パスワードがわからない限りは読み出せないということで、

ストレージに求められる暗号化の要件を満たせているはずである。

だから、この設定をしておけば、デスクトップPCも大手を振って社外持ち出しができるということである。


一方でストレージの暗号化の実効性ってどんなもんよという話もある。

メーカーはストレージを他の機器に付け替えても使えないので安全だと言っている。

ただ、どういう技術で暗号化をしているかという情報はあまり明らかではなく、

あまり出来の良くないものでは、特殊なアクセスを行えばパスワードが読み出せてしまうなんて話も。

そもそもパスワードを総当たり攻撃されたらどうなんだとか、気になるところは多い。

気休め程度の機能と割切ってればいいんだけど、どうなんでしょうね。


Author : Hidemaro
Date : 2019/12/06(Fri) 23:13
コンピュータ・インターネット | Comment | trackback (0)

マイナーな認証方式ではある

IMAP, SMTPサーバーの認証方式として、SSL/TLS証明書というのはあまり一般的な方法ではない。

それだけに対応しているソフトも限られる。

WindowsではMozilla Thunderbirdはいけるが、他はどうなんだろうか。

Androidでは僕が以前から使っていた K-9 Mail はいけるが、他に使えるのが見あたらない。

しかも K-9 MailはSMTPの証明書認証に対応しているようだが、うちのPostfixの設定だと証明書認証と認識してくれない。

Thunderbirdは証明書認証で動いているので、根本的な問題ではないと思うのだが。

(現状はPostfix専用のパスワードを使った認証を併用している)


Thunderbirdの設定を見てみると、IMAPでは、次の認証方式に対応している。

  • 通常のパスワード認証
  • 暗号化されたパスワード認証
  • Kerberos/GSSAPI
  • NTLM
  • TLS証明書
  • OAuth2

ほとんどは「通常のパスワード認証」でしょうね。

「暗号化されたパスワード認証」はSSL/TLS普及前に使ってたもので、今はもう使う人はほとんどいないだろう。

多くのメールソフトはここで終わり、この先に4つも連なってるのはThunderbirdぐらいしかないかな。

TLS証明書はこれまでも紹介してきた通り。(cf. クライアント証明書で通す, パスワードを没収されたので)


問題は残り3つである。

Kerberos/GSSAPI と NTLM はどちらもシングルサインオンの方式である。

認証情報を持った端末であれば、何のパスワードも聞かれることなく認証が完了するということ。

KerberosはMicrosoftのActive Directoryで標準的に使われている方式で、

勤務先の各種サービス(勤怠簿とか)のシングルサインオンもこれなのかなぁと思ったがどうなんだろ。

MicrosoftのWindows用に使われていることが多そうだが、これ自体はオープンな方式で、Active Directory以外でも使われてるそうだ。

NTLMはMicrosoftが以前使っていた方式で、今は推奨されないらしい。

この辺は、Thunderbirdを企業用のメールクライアントとして使うことを想定したものなのかな。


最後に書かれているOAuth2だが、これは実は対応しているメールクライアントは多そう。

というのもGmailを使うなら、この方式に対応している必要があるから。(アプリパスワードを使う場合は別)

ただ、Gmail専用になっていて、一般的なIMAPの設定に使えないことも多いかも知れない。

別にGoogle専用の方式ではなく、ちゃんと標準化された方式なんですけどね。


OAuthというとTwitter使ってる人にはなじみ深いけど、他のアプリやWebサービスと連携させるとき、

「○○があなたのアカウントを利用することを許可しますか」と、一定の権限を許可するか聞かれるが、

あれがOAuthで、ここで許可すると一定の範囲でアカウントを操作することが出来る。

許可したアプリは設定から随時取り消すことが出来る。一方で取り消さない限りはパスワード変更などしても継続して使える。

OAuthで許可を得たアプリは、パスワード情報を握っておらず、許可した範囲の操作だけできるということ。

それでOAuth2では、これがIMAP・SMTPなどにも適用できるようになったので、Googleは使っているということ。

OAuth2を使うと、初回にGoogleの認証をしてGmailの許可を出せば、以後はその権限を使ってアクセスするのでパスワードは関係ない。


SSL/TLS証明書というのも、マニアックな認証方法の1つだってことですよ。

いずれも共通して言えるのはパスワードレスであるということ。

パスワードレス化というところを考えるとぜひ使いたい方式である。

Kerberos/GSSAPIは組織内で決められたアプリを使うようなやり方になるんだろうと思うけど、

OAuth と SSL/TLS証明書 は広く使われそうな予感がする。

汎用のメールクライアントを使うのが時代遅れだって? まぁそんな気もしなくはないがThunderbird使いやすいし。


Author : Hidemaro
Date : 2019/12/01(Sun) 23:30
コンピュータ・インターネット | Comment | trackback (0)

ワンタイムパスワードとの2要素認証

このサーバーのBlogやメールサーバーへのログインをSSLクライアント証明書による認証に切り替えた話を書いた。

パスワードを没収されたので

証明書は自動発行すれば良い

このとき今後の課題についてこんなことを書いた。

あと類似するところでSSHのログイン用の秘密鍵の管理も課題がある。

ローカルに配置するとその端末でしかログインできない、

かといってオンラインストレージにおくと流出の懸念なしとは言えない。

というわけで、SSHのログイン方法の見直しを行っていた。


オンラインストレージからの流出は本当に恐れるべきことなのかというのはある。

とはいえ、鍵データだけに依存する状況もよくない。

一応、鍵データを紛失したときのワークアラウンドとしては、VPSのコントロールパネルから操作するという方法がある。

これはsudoが効かなくなったときのワークアラウンドでもある。(コンソールではrootへのログインもできるので)

ただ、SSHのログインに使える「物」が、鍵データ以外にあってもよいと思う。


いろいろ調べて、いろいろ考えた結果、

鍵データ または Google認証システムのワンタイムパスワード+Linuxのパスワードというところに落ち着いた。

まず、SSHの鍵認証は単独でも十分に安全性が高いといってよいだろう。利便性も高い。

ただし、鍵データの管理に十分注意が必要なので、本来は鍵データはむやみやたらに持ち出さないだろうと。

鍵データを持っていない場合、あるいは紛失した場合の代替手段としては「物」と「知識」による2要素認証だろうと。

知識はLinux自体のパスワードでよいと思うが、物を何にするかは少し迷った。


住信SBIネット銀行のログインロック機能のように、端末操作を行った後、しばらく認証が通る方法も考えた。

ただ、SSHをどんなときに使うかと考えてみると、他のサービスが正しく動作していないときに使うことも多い。

そうなるとSSH単独で他のサービスに依存せずに動く方式がよいだろうと。

そこでGoogle認証システムである。

Googleとは付いているけど、Googleが開発したってだけで、Googleのサービスに依存して動くものではない。

Google認証システムはワンタイムパスワードを生成するアプリで、このアプリの入った端末はオフラインでもよい。

オープンソースのワンタイムパスワードのシステムとして普及したものである。


そこら辺にいくらでも導入方法は書いてあるが、ここにも書いておく。

SSHでGoogle認証システムを使う場合は、PAM認証のプラグインとして導入する。

yumでインストール出来なかったので、ソースコードでダウンロードしてきてインストールする。

google/google-authenticator-libpam (GitHub)

書いてある通りにビルドすると /usr/local/lib/security/ にインストールされるので、/etc/pam.d/sshdの先頭に次の一行を追加する。

auth       requisite    /usr/local/lib/security/pam_google_authenticator.so

これにより、Google認証システムによるワンタイムパスワード認証が通れば、従来のパスワード認証に進むということになる。

requisite を require にすると、失敗してもそれを隠して次に進む。

どちらがよいかは場合によるだろうが、今回はワンタイムパスワードでだめでしたとすぐわかる方がよいだろうと。


これでsshdのPAM認証がワンタイムパスワード+Linuxのパスワード認証 になったので、これを使う設定をsshd_configにする。

PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes

パスワード認証とチャレンジレスポンス認証の両方を切ると鍵認証強制になるが、

チャレンジレスポンス認証を有効化した上で、PAM認証とすると、先ほど設定したPAMの認証が使えると。


あとは各ユーザーでGoogle認証システムの設定を行う。

$ google-authenticator -t -d -e 0 -r 2 -R 30 -w 2 -Q UTF8 -l "Libserver SSH"

Google認証システムの初期化にはQRコードを使うと便利なので、qrencodeをインストールしておく。

その上でこのコマンドを実行すると、コンソールに巨大なQRコードが表示される。

これをAndroidまたはiOSにインストールしたGoogle認証システムで読み取ると、

端末にワンタイムパスワードが出るので、これを確認に入力すれば、認証情報が~/.google_authenticatorに格納される。

いろいろオプションを付けたが、これを付けないといろんなことを聞かれるので。

"-t -d"は時間ベースのワンタイムパスワードで同一コードの再利用禁止、

"-e 0"は非常用コードなし、これはGoogle認証システムが使えないときのワークアラウンドは鍵認証と考えているから。

"-r 2 -R 30 "は30秒間に2回まで再試行可能、"-w 2"は最近2回(30秒ごと更新なので1分以内)のコードが有効、

"-Q UTF8"はUTF-8環境でのQRコード表示、-l オプションはGoogle認証システムでの表示名。

なお、QRコードが表示できない場合は、secret keyの文字をアプリに入れるか、相当するQRコードを作ればよい。

GoogleのQRコード生成用URLで生成してもよいが「キーがGoogleに漏れるから注意」と書かれている。


これで、あとは実際にSSHで使うだけ。

Using username "hidemaro".
Keyboard-interactive authentication prompts from server:
| Verification code: (ワンタイムパスワードを入力)
| Password: (Linuxのパスワードを入力)
End of keyboard-interactive prompts from server

まぁこんな感じですね。

この認証方式ってSFTPでも使えるのかなと、FileZillaの設定を見てみたら「インタラクティブ」てのがあるんですね。

これを選ぶと、対話的に2つのパスワードを聞いてくれる。

Pageantに鍵データを読み込んでいれば何もきかれずログイン成立となる。

以前はFileZillaで鍵認証するにはPageantで鍵データを読み込んだ状態で、ダミーのパスワードを設定してたものだが。


これが完了したところで、新しい鍵データを作って、改めて公開鍵を登録し直して、秘密鍵はローカル保存にした。

秘密鍵が使えないときは2要素認証で、Google認証システムが使えないときは鍵認証で、これで安心ですね。

一度ログインできれば、新しい鍵を登録することもできるし、


PAMつながりでもう1つ。

パスワード見直しの一環で、Linuxのパスワードも見直したが、けっこう長いパスワードになった。

ログインするときはよいが、sudoするたびにこの長いパスワードを入れるのはいやだ。

パスワードなしでsudoできるようにしてもよいが、ちょっとなぁと。

そこでsudo用のパスワードを別設定して、数字数桁のPINコードで認証するようにした。

pam_userdb.soというモジュールを使って、別に用意したパスワードデータベースで認証出来るようだ。

ただ、これの使用例を調べると、平文でパスワードをデータベースに格納しているので、それはおかしいだろうと。

$ echo "username" > db.in
$ perl -e "print crypt('xxxxxx',sprintf('\$6\$%08x',rand 0xFFFFFFFF)).\"\\n\"" >> db.in
# db_load -T -t hash -f db.in /etc/sudo_pw.db

ユーザー名とパスワードを交互に書いたテキストファイルを作って、/etc/sudo_pw.db のデータベースに格納するのだが、

pam_userdb.soではcryptされたパスワードを受け入れることも出来る。

じゃあ、どうやってcryptするのかって、perlのcrypt関数を使うのがよいだろうと。

引数の2つ目に暗号化方式とSaltを指定するのだが、"$6$xxxxxxxx"とすると、

SHA512方式(最近のLinuxでは標準)で、xxxxxxxxというSaltを付けて、1つ目の引数を暗号化するという意味になる。

Saltは乱数を16進数表記にすることで8文字作るようにした。こんなもんでいいでしょう。


その上で、/etc/pam.d/sudo にsudo時の認証方式を記載する。こちらはまっさらにして次の通り。
auth       required     pam_userdb.so crypt=crypt db=/etc/sudo_pw
account    required     pam_userdb.so crypt=crypt db=/etc/sudo_pw
session    optional     pam_keyinit.so revoke
password   requisite    pam_cracklib.so try_first_pass retry=3 type=

/etc/sudo_pwというデータベース(dbという拡張子がないことに注意)に、パスワードはcrypt形式で暗号化したので認証と。

keyinit.soはオリジナルの設定、pam_cracklib.soはinclude先のsystem-authにあったから書いたけど、意味があるかは知らない。

あと、sudo実行時に表示されるプロンプトに"password"って書いてあると勘違いしそうなので、

/etc/sudoers (visudoコマンドで編集する)でプロンプトを変更した。

Defaults passprompt="PIN for %u:"

これでPINを入力するように読めるからいいんじゃないかなと。


Author : Hidemaro
Date : 2019/11/30(Sat) 23:45
コンピュータ・インターネット | Comment | trackback (0)

テレビ会議で操作をサポート

ここのところ、社外の試験場に出張している人がいる。

試験開始時はいろいろなトラブルが相次ぎ、当初の計画は早くも崩れたそうだが、

立て直しを図り、なんとか軌道に乗ったと思ったら、なにやらエラーが出たよう。


それで、社内にいるチームリーダーが、こんなことが起きてるんだけど、と相談に来るので、

話を聞くと、どうもエラーは誤爆っぽい。

エラーメッセージを送ってもらって、明らかに誤爆であることはわかった。

それで少し考えたが、設定を変更するとこのエラーを消すことができることに気づいた。

試験項目によってはエラーメッセージを切ることは許されないのだが、

チームリーダーに確認すると、必要な試験はもう終わったとのこと。じゃあ切ろう。


そのためには、試験対象のシステムの設定変更をしなければならないが、

問題は今日、試験場に出張している人は、この設定変更の経験がないということ。

担当者の1人には操作方法を教えたので、E-mailや電話で指示をしてもなんとかなりそうだったのだが、

あいにく今日は出張していないので、そこに期待することは出来ない。


そこでどうしたかというと、テレビ会議を使った。

業務用ノートPCにはインカメラが付いている。それを試験場に持ち出してますからね。

インカメラで、システムにつながっているコンピュータの画面を映してもらったのだ。

幸いにして、今回の試験室は狭く、おかげでLANケーブルを試験室内に引き延ばせて、

インカメラの画質でわかるかどうか心配だったが、操作画面を判別するには十分だった。

やはり画面を見ながら操作を指示すると、的確に指示ができて、これまで経験がない人でもなんとかなった。


コンピュータの画面をインカメラに映すなんて、まどろっこしいことをするんだな、

と思ったかも知れないが、操作用のコンピュータがインターネット接続を想定した設定になっていないんだよね。

社内ネットワークへは明確に接続できない設定なのだが、社外ならそこのポリシーさえ満たせればなんとでも。

ただ、長きにわたりネットワークから切り離され、セキュリティ対策がろくにされていないのと、

社内ネットワークに明確に接続できない理由の1つでもあるけど、

システム用にネットワーク関係の設定をカスタマイズしてるから、なかなか難しいかなぁと。


テレビ会議も慣れだなとは思った。

これでも、普段からインスタントメッセンジャーとして使っているソフトでテレビ会議ができるだけよくて、

以前はテレビ会議対応の会議室同士をつないでやるしかなく、ハードルが高かったようなことも聞いている。

今回みたいに出張先で急遽テレビ会議を開く方法はなかっただろう。

もちろん、現在でも高品質の会議をしたければ専用の会議室で、備え付けの専用システムを使うべきだが、

設定にかかる手間を考えれば、簡易な方法でも実用上問題ないという考えは普及していた。

こんな簡易なので、ちゃんと指示できるかなぁとは思ってたけど、案外いけますね。


Author : Hidemaro
Date : 2019/11/28(Thu) 23:09
コンピュータ・インターネット | Comment | trackback (0)

メールサーバー間でSMTPS使うの?

メールサーバーに手を入れているときに、GmailではSMTPSで受信したか否かで表示が変わるらしい。

送受信時のメールの暗号化 (Gmail)

暗号化のアイコンの意味ということで書かれているが、

まず、緑色の鍵マークはS/MIMEで暗号化されているということで、これは明確な暗号化である。

ただ、S/MIMEによる暗号化をするには、送受信双方に電子証明書が必要なので、ほぼ使われていないかと。

赤色で鍵が破れた表示になっているのは、平文のSMTPで受信したメール。伝統的なE-mailですね。

その間に灰色の鍵マークがあるが、これはTLSで受信したということを指している。

鍵がかかった絵で描かれているので、Googleの認識はTLSで受信したメールは暗号化されているということらしい。


最初に「SMTPSで受信したか否かで」と書いたのは、あまり適切な書き方ではなかったね。

SMTPSはSSLによって暗号化されたSMTPプロトコルを表す言い方だった。

SMTP+SSL=SMTPSということで、SSLで暗号化されたHTTPSをHTTPSと書くのと同じ。

現在はSSLはTLSと言い方が変わっているので、TLSによって保護された――というのが正しい。

SMTPSと書いた場合、ポート465を使って、いきなりTLSで通信を開始するものを指すのが通常である。

一方で、SMTPは、途中からTLS通信への切り替えを行う STARTTLS というモードを備えている。

この場合、ポート587(サブミッションポート)あるいは、ポート25 でもTLSを使って通信内容を暗号化できる。


そもそも、SMTPはE-mailを他のサーバーに転送するプロトコルである。

ユーザーがプロバイダーのメールサーバーに転送するのも、そこからあて先のメールサーバーに転送するのも同じ。

これが迷惑メールの温床となっていたので、従来のポート25でのSMTPはメールサーバー間の転送のみに使い、

プロバイダーは一般ユーザーのポート25の使用を禁止して(OP25B)、

ユーザーがプロバイダーに接続するにはサブミッションポートという別ポートを使い、何らかの認証をするようにした。

SMTPでパスワード認証を行う SMTP-AUTH の場合、特に認証情報の暗号化の必要性も高いので、

SSL版サブミッションポートとしてポート465が使われることになったそうである。

もっとも、ポート587で必要によってSTARTTLSでTLSに切り替える方が標準的な方法らしいけどね。

必要によって切り替えるといっても、TLSに切り替えないと認証が通らず結局使えないことが多いと思うが。


というわけで、TLSによる暗号化をSMTPに適用するのは、ユーザーがメールを送信するためのものだと思っていた。

ただ、メールサーバー間の転送に使うポート25にSTARTTLSを適用することもできる。

Gmailのメールサーバーではポート25でもSTARTTLSを受け入れ、送信先のメールサーバーがTLS対応ならSTARTTLSを適用しているようである。

理屈上できるなぁとは気づいてたんだけど、実際にやってるところがあるとは、今まで知らなかった。

ましてやそれを一般ユーザーに向けて表示して、TLSが適用されなかった場合は警告的に表示しているとは。


僕がポート25へのSTARTTLSに懐疑的だったのは、メールサーバー間の暗号化は保証できるかもしれないが、

全てのメールサーバーがSTARTTLSに対応しているならともかく、対応していない方が多く、

TLS非対応のサーバーとはメールがやりとりできないとすると、とても使えたもんではない。

さらに、メールサーバーの前後の暗号化も明らかではなく、ここだけ暗号化しても意味はないんじゃないかと。

とはいえ、大昔のメールサーバーはメールサーバーをバケツリレーのように転送していたというけど、

現在はほとんどのE-mailのSMTPのフローは 送信者 → メールサーバー → メールサーバー の2段階で終わり。

送信者のクライアントがメールサーバーに接続するには、今はほとんどTLSが使われているだろう。

そう考えると、実用上は送信者から受信者のメールボックスまでずっと暗号化されてると見てよいと。

Gmailの表示の意図はそういうことなんじゃないか。


すでに、Let's Encryptでまともなサーバー証明書を持っていて、TLS自体はすでにポート465で使っている。

なので、Postfixに少し設定を加えるだけで対応できる。

まず、master.cf。

smtp      inet  n       -       n       -       -       smtpd
   -o smtpd_tls_security_level=may
smtps     inet  n       -       n       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_tls_ask_ccert=yes
  -o smtpd_sasl_auth_enable=yes

SMTP(ポート25)はTLSの使用を"may"ということで、使いたければ使えるが必須ではないとする。

一方のSMTPS(ポート465)はさっき書いたようにクライアントの認証用なので、

最初からTLSで、クライアント証明書を要求、パスワード認証を有効という設定をしている。

クライアント証明書またはパスワード認証が成立しなければ、他メールサーバーへの転送を許可しない設定は別途している。

(基本はクライアント証明書での認証だが、互換性の問題でパスワード認証も併用、ただしパスワードはPostfix専用のものにした)

裏返せば、ポート25では認証が成立しないということなので、自分のサーバー宛のメールの受信のみできる。


逆に送信側の設定、こちらはmain.cf。

smtp_tls_CAfile = /etc/pki/tls/cert.pem
smtp_tls_security_level = may

smtp_から始まる設定は、SMTPクライアントとしてのPostfixの設定を表している。

そちらでTLSの使用について"may"としているということは、こちらも使える場合だけ使うと言うこと。

これを"encrypt", "verify"にすると、STARTTLS非対応のメールサーバーには送信できなくなる。

あと、CA証明書も必要なので、CentOSにバンドルされてるものを指定したけど、

実はTLSの使用について"may"の設定の場合、証明書の検証結果によらずTLSで接続して送っちゃうんだそうだ。

STARTTLS非対応のサーバーにも平文で送るぐらいだし、接続先は疑わしくともTLSで暗号化できるだけマシということか。


この設定をすると、Gmailに送ったとき、灰色の鍵マークで表示され、逆に受け取ったメールには、

Received: from mail-xxxxxxx.google.com (mail-xxxxxxx.google.com [xx.xx.xx.xx])
	by hdmr.org (Postfix) with ESMTPS id xxxxxxxxxx

というヘッダがつき、ESMTPS ということで暗号化して受信されたことが確認出来る。

Thunderbirdで"hdmr.org (Postfix) with ESMTPS"をReceiveに含んでるとマーキングするという設定をして、

参考に見ているけど、届くメールの半分ぐらいがTLSを使ってるみたい。

(Receiveヘッダの偽造まで考えられた厳密な条件ではないので、参考程度の情報だが)

案外、普及してるもんだなと思ったけど、GmailがTLS対応の動機になってたのかもしれない。


あまり意味は無いかも知れないが、平文よりTLSの方がよいのはそうだろう。

現状、平文よりマシという程度の運用なので、STARTTLS対応にしたがために拒否されたということもあまりないだろう。

HTTPSだと証明書の証明期限切れとか起きてると、禍々しい警告が出てくるけど、

それはHTTPSへの期待度が高まった時代だからこそで、以前はここまでではなかったわけだし。

将来的にはどうかわからないけど、SMTPの古さを考えると、なかなか厳しいことも言えないような気はしますね。


Author : Hidemaro
Date : 2019/11/26(Tue) 23:52
コンピュータ・インターネット | Comment | trackback (0)

証明書は自動発行すれば良い

このサーバーのE-mailの認証にSSLクライアント証明書を使うようにしたという話を書いた。

パスワードを没収されたので

証明書によって認証することで、パスワード認証に伴うリスクは軽減される。

それはよいのだが、秘密鍵の管理というところには少し課題がある。


これまで、証明書の有効期限は100年に設定して、証明書と秘密鍵をセットにしたPKCS#12形式にして、

それをオンラインストレージにおいて、適宜、端末にインポートして使っていた。

オンラインストレージは自分しかアクセス出来ないはずだし、PKCS#12形式のデータにはパスワードがかかっている。

とはいえ、このファイルが流出してパスワードを割られると、何があったかわからないまま認証されてしまう。


証明書発行も手動で手間がかかっていたので、自動化を試みることにした。

そのフローは次の通りである。

  1. WebサイトにLinuxのユーザー名・パスワードでログインする
  2. 登録されているE-mailアドレス(例えばGmail)にワンタイムパスワードを送る
  3. ワンタイムパスワードを確認して、秘密鍵・証明書をサーバーで作成する
  4. PKCS#12形式(ランダムなパスワードをかける)で端末にダウンロードして、証明書ストアに登録する

ユーザー名・パスワードで認証して、E-mailで2段階目の認証をするというのは、Googleの2段階認証に似てるかな。

Gmailのアカウントが乗っ取られなければ、Linuxのユーザー認証を突破されても助かると。

この程度やれば十分なんじゃないかね。

秘密鍵と証明書のセットはサーバー上で作成するが、作成後はまもなくパスワードロックされたPKCS#12形式にする。

パスワードは画面に表示されるので、これをコピーして、ダウンロードしたPKCS#12形式のデータに適用して端末に登録する。

そのPKCS#12形式のデータも10分後には消してしまえば、秘密鍵がサーバーから流出することはないだろう。


証明書に登録する情報だが、ユーザーを識別するCN(一般名)はE-mailアドレス、O(組織名)は氏名に固定している。

OU(部署名)には、その証明書を使用する端末名を書いて、どの証明書をどこに使っているかわかるようにしている。

それでOpenSSLの初期設定では、これらの情報の組み合わせ(DN)が一致する証明書は複数発行できない。

同じDNの証明書を発行するなら、以前使っていた証明書を失効させないといけない。

というわけで失効を管理する仕組みもWeb上に作ることにした。

こちらもLinuxのユーザー名・パスワードでログインして、ワンタイムパスワード認証をすると、

そのユーザーの証明書リストが表示され、証明書を選べば失効させられると。

失効証明書は毎日自動的に更新するようにした。


これを実現するには、認証局を管理するユーザーを作って、そこに認証局の管理をさせたり、

そのユーザーはLinuxのユーザー認証をできるようにしたり。

いろいろやるべきことはあったのだが、出来てしまえば証明書を簡単に作ったり消したりできるようになった。

証明書の有効期限も4ヶ月にした。

長いか短いかはいろいろ考えはあると思うが、時々更新しないと忘れるだろうというのもある。


課題としては、証明書が端末に紐付いていることは保証できないということ。

僕の運用では1つの証明書は1つの端末にしか入れないことにしてるけど、仕組み上は保証されていない。

このへん、ハードウェア(ICカードなど)に証明書を入れる方法は徹底されているわけだけど。

とはいえ、クライアント証明書を発行する方法は、そういう特別なハードウェアが必ずしもいらないのは長所ではあって、

そうじゃなければ個人で導入はとてもとてもと。


あと類似するところでSSHのログイン用の秘密鍵の管理も課題がある。

ローカルに配置するとその端末でしかログインできない、

かといってオンラインストレージにおくと流出の懸念なしとは言えない。

こっちの方がミッションクリティカルなので、さてどうしたもんかと。

まだ考え中ですね。


Author : Hidemaro
Date : 2019/11/25(Mon) 23:58
コンピュータ・インターネット | Comment | trackback (0)

パスワードを没収されたので

以前、Yahoo!ショッピングの支払いでPayPayが使える設定にしたら、Yahoo!のパスワードを取り上げられてしまった。

これ、実際にやったことある人ならわかると思うけど、携帯電話回線にYahoo!アカウントが紐付くことで、

従来使っていたパスワードは無効化され、回線またはSMSから届くワンタイムパスワードで認証が行われるようになるのだ。

4500万人のユーザーに“パスワード”をやめさせたい――ヤフーが進める「もっと安全で簡単な認証」とは (ITmedia)

自宅の回線からYahoo!にログイン操作を行うときはSMSで届くワンタイムパスワードを入力するが、

携帯電話回線に接続しているスマートフォンだと、アカウントを確認するだけで認証が完了する。

これはSoftBankとY!mobileの回線に限ったことだと思うが、確かに便利ではある。


2要素認証の仕組みがセキュリティが重視されるサービスで普及している。

例えば、住信SBIネット銀行のログインだと、スマートフォンのアプリでロックを解除して(物)、IDとパスワードで認証(知識)という2要素を使っている。

パスワード流出のリスクを考えると、パスワードという知識に頼った認証はなかなか厳しい。

そこで2要素認証なのだが、これはこれで手間がかかるし、やっぱりパスワードもそれはそれで使う。

Yahoo!は電話回線につながったスマートフォンを持っていることを、唯一の認証手段とすることを推奨している。


スマートフォンなど物を使った認証は、パスワード流出リスクは低減されるが、紛失のリスクってのはある。

この点については、まずスマートフォンなど物に適切にロックをかけておくこと。

たった4桁のPINコードでも、スマートフォンを失ったときに少し破られなければよい。

そのうえで、紛失したら認証手段から外せばよいわけである。

実は物を使った認証というのは、スマートフォンに限った話でもない。

自分で運用しているサーバーの認証手段として SSHの公開鍵認証 と SSLクライアント証明書 がある。

どちらもファイルだけど、知識というよりは物だよね。デバイスに登録することもできるし。

このファイルにはパスワードがかけられているので、ファイルだけ入手してもそれだけで使えるわけではない。

その上で、紛失などあれば無効化することもできる。


Yahoo!にパスワードを没収されたことをきっかけにして、認証手段の取扱をいろいろ検討したが、

今まで使っていなかったパスワードマネージャーを使用して、パスワードの強化を図ることにした。

Googleパスワードマネージャーは、PC・AndroidのChromeブラウザで統合的にパスワードを管理できる。

これまでPCではFirefoxを使っていたが、Chromeへの移行に問題ないので、

全部Chromeに統一して、サービスごとにパスワードを設定するなら統合管理することにした。

その上で、他の認証手段と紐付けて、パスワードレスにできるのなら、それも活用することにした。


昨日・今日でおよそ120のサービスの認証手段を見直した。すさまじい数だな。

このうち、パスワードを唯一の認証手段とするものは85個ほど。

パスワード+スマートフォンの2要素認証が5個ほど、これもパスワードの管理が必要となる。

これらのパスワードはGoogleに管理してもらい、Chromeでは自動的に呼び出される。

ただし、全てがChromeで入力するパスワードとも限らず、アプリ画面へ入力するものもある。

そういう場合は、Chromeからパスワードマネージャーを呼び出して、コピペすることになる。

端末のロック解除操作(PINコードとか指紋認証)をするとパスワードのコピペが許される。

煩わしいとは思うのだが、厳重に管理されたGoogleアカウントで複雑なパスワードを保存する方がよいという判断。

この85個ほどのパスワードで唯一Googleに管理させていないのは、Google自身のパスワードだけ。

(Android端末やPCのChrome・Thunderbirdには常時紐付いているので、普段は入力することない)


残り30個ほどのサービスでは他のサービスを認証手段に使う。

Yahoo!もこの分類ですかね。Y!mobile回線への接続またはSMSを認証手段としているので。

Yahoo!IDを使った認証はおよそ10個、Twitter・Google・Facebookを使った認証が各5個前後。

変わり種では ねんきんネット の認証手段が マイナポータル、すなわちマイナンバーカードの証明書を使った認証にしたというのがある。

以前からFacebookに紐付いていたLINEのようなのもあるが、多くは今回新しく紐付けを行った。

ただ、紐付けを行うことでパスワードが抹消されるサービスはそう多くなくて、

従来の弱いパスワードを上書きするためにパスワード変更して、Chromeがパスワードを保持しているものも多い。

実際のところ、アプリでは他のサービス経由での認証には対応していないなんてのもあって、

結局、個別のパスワード認証になってしまっているのはある。

あと、既存のアカウントには紐付けできないものもあったり、メールアドレスが同じであるという条件があったり。


それとあわせて対策をしたのが、自分のサーバーで運用しているメールアカウントの認証強化である。

パスワード再設定時の連絡先がここになってたりするわけだから、ここの認証はとても重要である。

こちらはSSL証明書認証への移行構想は昔からあったが、いろいろ苦しみながらやっとこさできた。

Dovecotのバージョンを上げて、充実しているとは言えない資料を漁りながら実現できた。

Dovecot and Postfix client certificate authentication (Mortikia Blog)

僕が使っているメーラーはPCではMozilla Thunderbird、Androidでは K9 Mail だが、

どちらも証明書認証には対応しているので、マニアックな認証方法だが、実用上の問題はない。

これにより、サーバーの各種サービスへのログインはパスワードレス化されたはず。

(一部は互換性のためにパスワードを併用しているものもあるが、Linux自身のパスワードとは切り離した)


まだ、少し見直しが完了していないものもあるが、だいたいこんなもの。

しかし、パスワード再設定もだいぶしたけど、設定可能な桁数がとても短かったり、旧パスワードが平文で見えてたり、

見直しを進める中で桁数や文字種の条件は以前より緩和されているものもありましたね。

EX予約は以前は数字しか設定できなかった覚えがあるが、今はアルファベット含めて8桁まで行けるようになった。

制限が厳しいように見えるが、これは券売機で入力することがありうるから。

インターネット用と券売機用(カードとの2要素認証とも言える)で分けるのが正しいと思うが、以前よりマシにはなった。

サービスによってはパスワードの強度や流出リスクに課題があるなぁと。

そのリスクに対して、今回の対策を行うことで緩和はできたのかなと。


Chromeが自動入力してくれたり、Yahoo!やGoogle経由の認証になったり、

実質的なパスワードレス化がかなり進むことになる。

物の管理には一層の注意を払う必要はあるが、利便性は高まるなと思う。

Yahoo!にパスワードを没収されてから吹っ切れたというのはあるね。それでいいんだって。


Author : Hidemaro
Date : 2019/11/23(Sat) 23:50
コンピュータ・インターネット | Comment | trackback (0)

スタンドアロンPCへのインストール

今日はスタンドアロンのPCにWindows 10をインストールしていた。

Windows 7 PCを買ってWindows 10を入れる


届いたDVDを入れて、既存のパーティションを消してインストール。

インストール完了後には、ドライバーのインストール。

と、ここまでは普通なのだが。


ここで、スタンドアロンでのライセンス認証を行う必要がある。

入手したMAK認証用のキーを入力すると、Webで認証をしようとするが、ネットワークにつながっていないのでエラーになる。

ここで電話認証が提案されるかと思ったのだが、どうもそうなっていない。

[Windows 10] Windows のライセンス認証を電話で行う方法  (Windows 展開技術大全)

電話をかけたら、対象の製品はどれかとか、アップグレードが完了したかとか、エラーが出てるかとか聞かれて、

なんとか乗り越えたら確認IDをプッシュボタンで入力するんだけど、

これが数回に1回しくじって、入力し直しになったりで、けっこう時間がかかった。


最終的にはスタンドアロンにするにしても、ネットワークにつないで認証した方がよっぽど効率がよいと思ったが、

社内ネットワークにつなぐには相応のセキュリティ対策が必要で、それをしていないからね。

もっともWindowsライセンス認証をする段階では、各種のセキュリティ対策をする前だろうから、どっちでも一緒な気がするけど。

特にこれはWindows 7の業務用PCとして、社内ネットワークに接続する権利は持っているわけだし。

(MACアドレスでフィルタリングをしているので、全く未登録のネットワーク機器は接続が拒否される)


もう1つめんどくさかったのが、Windows 10のパッチ適用である。

社内ネットワークに接続して、WSUSの設定をしてアップデートするのが楽である。

ネットワーク負荷も社内のサーバーでキャッシュされているので軽いし、必要なパッチも自動的に選ばれる。

ところが、スタンドアロンの場合は、Microsoft Updateカタログから、適用すべきパッチを探して、

それをダウンロードしてUSBメモリなどで運んでインストールとしないといけない。

Windows 10の場合、1903とかバージョンごとに違う上に、x86とx64でも違う。あとARMとかもあったな。

さらに今回、指定のWindows 10のバージョンが古かったこともあって、更新プログラムが1GB越えという状況。

基本的には「サービススタック更新プログラム」と「累積更新プログラム」を運んで適用すればOK。

初回なので大量の累積更新プログラムも全部役立つが、

今後定期的に更新する場合、本来は差分だけでよいのに、全部ダウンロードして適用なので無駄が多い。

でも、スタンドアロンの場合、それしか選択肢はないと思われる。どこまで真面目にアップデートするかという話はあるが。


それに比べればまだましだったが、ウイルス対策ソフトのインストールもけっこう時間がかかった。

これもスタンドアロンだと定義ファイルは手動でファイルを運んでの更新になる。

これもどこまで真面目にやるかという話だが、USBメモリなどを介したウイルス感染の可能性があるので、

必ずウイルス対策はやれという指示なので、あまりいい加減なことも言ってられない。


スタンドアロンにしたのは、製品評価のために必要なコンピュータの設定の都合、

社内ネットワーク接続との両立は難しいだろうという判断があったからである。

例え、社内ネットワークにつながるようにしても、長期間切り離されることも想定しないといけない使い方である。

長期間、社内ネットワークから切り離されてしまうのなら、結局はあまり変わらないのだ。

厳密に運用されているかは怪しいが、長期間切り離されたPCは、手動でWindows更新・ウイルス定義ファイル更新をすることになっている。

確かに全く社内ネットワークに繋がないならセキュリティ対策を簡素化できるという考えもあったのだが、そこが重要だったわけではない。

とはいえ、この手間を考えると、スタンドアロンにしたのは正しかったのかと思ってしまうよね。


そんな苦しみはあったが、1日かけてセットアップ全体の8割方終わった。

Windowsとか基本的な部分は全て終わっていて、製品評価に使うソフトのインストールに時間がかかっている。

これだけで1日仕事になることもしばしばなので、Windowsインストールも含めてここまで進んだならいいとこかな。

もう1台作る予定はあるが、そのときはもうちょっとスムーズに行くといいな。


Author : Hidemaro
Date : 2019/10/16(Wed) 23:45
コンピュータ・インターネット | Comment | trackback (0)

Windows 7 PCを買ってWindows 10を入れる

最近、製品評価のためのコンピュータの確保に向けて、いろいろ動いていた。

Windows 7の頃は、業務用PCを製品評価専用に用意して、そこにソフトウェアをインストールすれば済んでいた。

コンピュータの設定もいろいろ変えないといけないので、製品評価専用にしないといけないんだけど。

ところがWindows 7のサポートも終わることだし、次のプロジェクトからはWindows 10にしないとねと言っていた。


Windows 10への移行にあたって、他の部署に聞いてくれた人がいて、

その情報によれば、カスタムされたWindows 10のコンピュータへのインストールはできないらしい。

確かに説明書にも、プリインストールのOSを消して、Windowsのインストールからすることを推奨すると書かれている。

これ自体はWindows 7のときもそうだったのかもしれないが、なおさら問題のようだ。

レンタルで業務用PCを確保して、これをクリーンインストールするという方法で対応しているそうだ。


でも、クリーンインストールする時点で、業務用PCである必然性がないような気がした。

業務用PCをレンタルする意義は、社内でサポートを受けられること。故障時も代替機が早期に用意できる。

でも、既存のOSを消してしまうと、社内のサポート対象外になる。そりゃそうだ。

もう1つ問題があって、それが業務用PCの新規レンタルが逼迫していること。

レンタル業者から週ごとに納入される最大台数は決まってるようなんだけど、

Windows 10への移行という特需のため、今申し込んでも、納入がかなり先になってしまう。


この問題を解決する方法が、Windows 7の業務用PCをレンタル業者から購入するという方法だった。

現在、Windows 7が入っているPCは、ハードウェア的にはWindows 10にも対応できる。そんなに古くない。

購入費用はかかるだろうが、レンタル業者にとってみればメーカーサポートの切れたPCはそこまで大きな価値はないだろう。

どれぐらいか知らないけど、それなりに安く買えるんじゃないか。

購入後はサポートは得られないが、月々のレンタル料もかからなくなる。

さらに、この方法ならば、早期に製品評価用のコンピュータが確保できる。

評価計画を立てる人にとってはそっちの方が魅力的に映ったようだ。


それにしても、どうやってWindows 10ってインストールするの?

調べたら、どうも勤務先ではMicrosoftとEnterprise Agreement(EA)という包括契約を結んでいて、

ユーザー数に応じた費用を支払っているので、社内で使う限りにおいては自由にインストール出来るようだ。

ただし、現実的な問題として、Windows 10 Enterpriseのインストールメディアを借りる手続きは必要なのだが。


でも、Windowsってライセンス認証しないといけないよね?

調べたところ、基本的にはKMS認証という方式でライセンス認証をするらしい。

これは社内ネットワークにつないでさえいれば自動的に認証される仕組みだという。

インストール後30日、認証後180日経過すると、認証切れで制限がかかるよう。

なるほど、と思ったが、今回の評価用コンピュータは社内ネットワークから切り離して使う予定であること。

設定の都合、社内ネットワークとの接続を両立するのは難しいだろう(可能ではある)という判断である。


こういう場合どうするのかと調べてみると、MAK認証という方法があるらしい。

一般的にEAライセンスの配布方法には、KMS認証とMAK認証のいずれか、あるいは2つ併用できるそう。

とはいえ、コンピュータの数量が多い場合、ネットワークにつなぐだけで認証されるKMS認証のメリットは大きい。

KMSサーバーを立てる必要があるが、管理上も便利なので、勤務先も基本的にはKMS認証でと言っている。

一方のMAK認証はPC1台ごとにライセンスキーを入力して認証するという方式。

認証後は恒久的にライセンスが有効となる。これは家庭用のライセンスに似ている。

台数が少なければMAK認証しか選択肢はないし、そうでなくてもKMSサーバー不要なのはメリットがある。

この2つの方式は併用できるので、勤務先でもネットワークから切り離して使う場合は、一件審議の上でMAK認証用のキーを発行するとあった。

申請すると、無事にMAK認証用のキーが付与された。やったね。


他にも必要なセキュリティ対策や、関連ソフトウェアのインストール方法など、調査すべきことは多かったが、

まぁなんとかいけるかなぁというところまでやってきた。

うちの部署ではなかなかノウハウがなくて困ったが、今後は避けられなさそうだし。


ところで、部内の他の課では、レンタルPC以外にもけっこうな数のPCを持ってたりする。

現役で使っているものはまだよいのだが、もう長らく通電すらされていないものも数多く並んでいる。

実は、かつてこの部署で開発していた製品で使っていたものらしいのだが、

今はその製品がなくなり、開発者もほぼ残っていない状況で、古い製品とともに残されているようだ。

ふと気になって見てみると「Pentium 4」「Windows XP」なんてシールが貼られている。

もう使えないのでは? と思っているんだけど、捨てる決断をできる人ももういないのだろうか。


実はここはレンタルPCを購入することのリスクでもある。

レンタルだったら、一定期間経過するとレンタル業者が引き取って、適切に処分してくれる。

ところが買い取ってしまうと、最終的にはそれを処分するところまで責任を持たなければならなくなる。

そういうところで陳腐化したので捨てますという決断ができるかということである。

まさに今、Windows 7世代の部署所有の製品評価用のコンピュータが、そういう決断を迫られてるんじゃないかなと。

スタンドアローンで使うなら残せなくもないが、基本的にはサポートの切れたOSは使うものではないでしょう。

果たしてここから部署所有PCの大粛清になるかどうか。

そのために代替機が必要なら、今回の方法に準じて購入するか、あるいはレンタルPCで代替するか。条件次第かな。


Author : Hidemaro
Date : 2019/10/08(Tue) 23:26
コンピュータ・インターネット | Comment | trackback (0)

Tools