この船のルーツは紅丸
以前、フェリーさんふらわあ の大阪～別府航路を使って以来、
定期的に フェリーさんふらわあ からメールが届いている。
大阪⇔別府航路に待望の新造船就航が決定しました！
船名は「さんふらわあ くれない」「さんふらわあ むらさき」。
一応、この船の名前、仮称らしいのだが、えらく具体的な名前である。
現在、大阪～別府航路に入っているのは「さんふらわあ あいぼり」「さんふらわあ こばると」
それぞれ1997年・1998年デビューということで、もうけっこうな年数が経っている。
この船は客船(カーフェリーではない)「あいぼり丸」「こばると丸」の代替として導入された経緯がある。
2016年に使ったときにもけっこう年期が入ってるなぁとは思ったものである。
やはり雑魚寝ことツーリストの持て余しっぷりは気になるところではあった。
日によるのもあるだろうが、ツーリストに乗れば、ツーリストベッドへの無償アップグレード券を配っていたほど。
じゃあ、新造船はどうなるのかという話だが。
大阪/別府航路 待望の新造船就航決定！ (フェリーさんふらわあ)
「日本初のLNG燃料フェリー」と書かれている。まさかのLNG燃料になるようで。
2020年以降、船用燃料の硫黄分を0.5%以下にする必要があり、従来から使っているC重油のままでは対応できない。
C重油のまま低硫黄化するか、A重油(ほぼ軽油)に移行するか、SOxを除去する装置を付けるか。
既存の船での対策としてはここら辺だが、新造船ではLNGを使うという選択肢もある。
LNGは液化前に硫黄分などが除去されていて、燃料費も 低硫黄C重油 や A重油・軽油 より安いのだという。
一方で、LNGの補給には課題もあるところだが、このフェリーの場合、基本的には大阪港と別府港にしか入らない。
なので、この2つの港でのLNG補給体制が整っていればよく、その点ではハードルは低いとも言える。
そもそも日本はLNG自体はたくさんありますからね。(天然ガスの多くをLNGとして輸入しているから日本各地にタンクがある)
国内航路で実績を積むというのは理にかなった話である。
あと、船自体も大きくなる。
今のさんふらわあ あいぼり/こばると が9245トンに対して、新造船は17300トンとなっている。
定員も710名から763名と増える。全定員の42%が個室となっている。
個室についてはエクストラベッドなども含めた定員なので、実際にはそこまで埋まらないかもしれない。
相部屋は45%だが、7割はプライベートベッド、新型ツーリストベッドみたいなもんですね。
2割はツーリスト、従来型の雑魚寝も団体利用などで需要があるので一定残る。
そして22名、相部屋の6%分は「プライベートベッドシングル」となっている。
大阪～志布志航路では1段のシングルベッドを備え、カーテンで区切れるということで、1人用個室に近いものになるようだ。
残りはドライバールーム、従来70名だったところを89名に増やしているが、
最近ではトラック輸送の引き合いも多いようで、トラックの搭載数も13m換算で92台から136台に増やしている。
観光航路の印象も強い大阪～別府だが、トラックからの人気もあるようだ。
大分県というのはフェリーの便利なところではあって、ドライバの負担軽減からも長距離フェリーを使いたいニーズは高まっているのかもしれない。
新造船の大型化というのは、観光航路としての期待に応えるのもあるけど、物流を支える意図が大きいようだ。
ところで、最初に船の名前について「仮称らしいのだが、えらく具体的」と書いたが、
この名前はかつて大阪～別府航路で運航されていた「くれない丸」「むらさき丸」に由来するのは明らかである。
大阪～別府航路は1912年に大阪商船(→商船三井)が開設した航路に由来する。
日本の長距離カーフェリーで客船時代からの歴史を持つのは大阪～別府が唯一である。
その次に長い歴史を持つのは阪九フェリーで1968年開設、日本初の長距離カーフェリーである。
その大阪～別府航路に最初に投入された船こそ「紅丸」である。続いて「紫丸」が入った。なんと石炭炊きである。
1924年にはディーゼル動力の2代目「紅丸」が就航した。日本で2隻目のディーゼル動力船だったという。
そこから時代が進んで1960年に3代目「くれない丸」と2代目「むらさき丸」が導入され、1980年にフェリーに置き換えられるまで活躍したという。
日本初のLNG燃料フェリーということで、初めてディーゼル動力になった2代目「紅丸」を意識したのかなとは思ったけど。
よっぽどのことなければ、この名前でいくんでしょうね。
これを書くために調べて知ったんだけど、3代目「くれない丸」は今も現役の船なんですね。
レストラン船「ロイヤルウイング」として、横浜港で活躍している。
先月には進水から60年で「還暦」を迎えたが、60年も現役で活躍する船はそんなにないらしい。
操舵室などの見学プランをスタート ロイヤルウイング (カナロコ)
用途は変わったが、瀬戸内航路の黄金時代の生き証人として、映画やドラマの撮影に使われることもあるんだとか。
この船が瀬戸内を去ったおよそ30年前には、大阪～別府も平凡な長距離フェリーになりはじめていたわけだが、
時代が移り変わって、フェリーにもクルーズ要素が求められるようになってきたということで、
本格的な観光船としてデビューした3代目「くれない丸」と2代目「むらさき丸」へのリスペクトもあるんでしょうね。
Author : Hidemaro
Date : 2019/12/04(Wed) 23:56
交通 | Comment | trackback (0)
相鉄直通列車のJRでの扱いはどうなってる
この前の土曜に相鉄新横浜線の西谷～羽沢横浜国大が開通し、相鉄・JRの直通運転が始まった。
JR側は既存の貨物線を使い、車両も埼京線の車両を使うというスタイル。
じゃあ、大崎～羽沢横浜国大は埼京線なのか。ここは微妙な話である。
特殊な運転系統に戸惑いは多いわけだが、やっぱりなんといってもこれでしょう。
「遠い駅」の方が安い？ 相鉄・JR直通線の運賃のナゾ (鉄道コム)
まず、羽沢横浜国大駅の隣がいきなり川崎市の武蔵小杉駅というのがおかしい。
直通列車のJR側は全て「各停」なのにおよそ18分間にわたりノンストップである。
一方で制度上は羽沢横浜国大駅は鶴見駅から8.8km離れた場所にある駅ということになっている。
そのため、武蔵小杉駅までの運賃が310円に対して、鶴見駅までは170円とおかしなことになっている。(いずれも紙のきっぷの運賃)
実際の線路は確かに鶴見駅を通過して、そこから新宿までは横須賀線・湘南新宿ラインのルートを走っているように見える。
鶴見駅については、横須賀線・湘南新宿ラインでも停車しない駅なので、「遠い駅の方が安い」というのはすでに発生している。
新川崎駅の次の停車駅、横浜駅までの運賃が220円に対して、鶴見駅までの運賃が157円など。
ただ、もう1つおかしなことがあって、横須賀線・湘南新宿ラインでは鶴見～武蔵小杉に新川崎駅が存在する。
どうして新川崎駅には停車しないんだろうと疑問に思っていた。
実は相鉄・JRの直通列車は、新川崎駅付近を通過するのだが、新川崎駅自体は通らない。
新川崎駅に隣接した新鶴見信号所という貨物列車用の施設の中を通過するらしい。
新川崎駅は言うまでもなく川崎市(幸区)にあるわけだが、鶴見というのは横浜市の地名、
おかしな気がするけど、鶴見駅から分岐した先にある施設で、完全に貨物専用なのでこの命名は理にかなってたんでしょうね。
相鉄・JRの直通列車が横須賀線・湘南新宿ラインの線路と一緒になるのは、新鶴見信号所/新川崎駅～武蔵小杉駅の間、
鶴見駅から合流点までは同じところを併走しているが、走る線路が違うらしい。
最初に「大崎～羽沢横浜国大は埼京線なのか」と書いたが、
JR東日本のWebサイトを見ると、この区間は「相鉄線直通」という路線名で時刻表が掲載されている。
新宿～大崎については、相鉄方面は「相鉄線直通」で、新宿方面は「埼京線・川越線」に掲載されている。
一部には新宿を越えて大宮方面まで直通するものもあるが、新宿より大宮方面では相鉄方面も「埼京線・川越線」に混ぜて掲載されている。
こんなことからも、新宿～羽沢横浜国大は、埼京線そのものではないという認識のようだ。
もっとも駅の時刻表では相鉄方面は埼京線(メインは大崎から りんかい線)に混ぜて書いてある一方で、
同じ方向の湘南新宿ラインとは別書きなので、相鉄線直通はどちらかといえば埼京線ではあるようだ。
当初から言われていたことではあるけど、JR側の運行形態は特殊ですよね。
本命は2022年ごろから予定の東急新横浜線を介した東急との直通運転でしょう。
JRとの直通運転に比べればはるかに多くの直通列車が設定される見込みである。
現状は羽沢横浜国大駅は直通列車だけの停車なので、本数は少ないし、
なにより東隣の駅はいきなり武蔵小杉駅ということでイマイチである。
相鉄・東急新横浜線の全通 により、本数も増えますし、東隣は新横浜駅になり生活路線としての有用性も増す。
そうはいっても、横浜都心へはバスの方が便利な状況は変わらないだろうとは思われてますがね。
駅名に「横浜国大」とは付いているが、横浜国立大学のどちらかというと裏側なので、
校地内の目的地によっては、従来からの最寄り駅(三ツ沢上町駅など)からの方が近いだろうと。
通勤・通学用途では定期券の経路変更が必要なので、しばらくは様子見というのもあるかもしれない。
じゃあ、レジャー用途かというと、昼間は30分間隔なのでそれも悩ましい。
本数の少なさを乗換なしの利便性でどこまで埋められるかがポイントなんでしょうね。
二俣川～渋谷だと、JR直通は所要時間40分、横浜駅へ東急に乗換だと55分となっている。
さすがに直通列車、所要時間は短いが、30分間隔の次の列車を待つほどかはわからない。
東急と比較しやすいので渋谷駅を例に出したが、JRにとっては埼京線ホームが大きく離れているので、
この区間では直通列車は割に合わないという見方もあるかもしれない。
目的地次第というしかないよね。
Author : Hidemaro
Date : 2019/12/03(Tue) 23:34
交通 | Comment | trackback (0)
NISAの終わりが見えてきたので
NISAが始まったのが2014年、そこから今年の1月で1年目は5年の非課税期間が終わった。
今度の1月で2年目の非課税期間が終わることになる。
2014年からの非課税期間は、投資信託ばっかりで、早い段階で売り払ってたんだけど、
2015年からの非課税期間では、株式を本格的に買い始めたので、その株式をどうするかは問題。
期間中に売却してしまうのが1つ。これなら売却益は非課税で終わり。
そのまま引き継ぐ場合は、翌年のNISA投資枠へのロールオーバー か 課税口座への振替 かを選べる。
とはいえ、僕は2018年からつみたてNISAに移行したので、ロールオーバーという選択肢はない。
なので、12月を越えて残した株式は課税口座へ振替される。
12月末日の時価が課税口座での取得価格になるって話だったはず。
いろいろ整理していたのだが、課税口座への振替は3銘柄になりそうだ。
どちらも株主優待も含めて考慮して、引き続き保有したいと考えている。
残りは2銘柄あったが、これはこれまでに売却したか、これから売却するか。
2015年はあんまりいろいろ買ってなかったんだね。
2016年取得はバラエティ豊かなので、もうちょっと悩むことになるかな。
もうすでに売った銘柄もいくつかあるんですがね。
NISAといえば時々ニュースでも話題になっている。
NISAは時限措置で、特につみたてNISAは20年の非課税期間といいつつ、それより先にNISAが終わってしまう可能性もあった。
ＮＩＳＡ、２０２４年「積み立て型」新設 資産形成促す (朝日新聞デジタル)
僕にとって興味のあるのは つみたてNISA の取扱だが、
5年延長ということで当面は20年の非課税期間が確保されるので、とりあえずは一安心。
一般NISAについては、リスクの比較的低い投資信託への投資に限った積立型を新設すると書かれている。
どういう扱いなのかわからないけど、背景にはこんなことが書かれている。
一般ＮＩＳＡをめぐっては株式にも投資できることから、短期売買に使われているとの指摘も多く、「税優遇を使ったバクチ制度」（財務省幹部）という批判も根強かった。
NISAの投資先について、5年間の非課税期間を生かすには長期保有できる銘柄にこそ投資すべきだと思っていたが、
大当たりしそうな銘柄に投資した方が非課税のメリットが大きいんだと、書いてあるのを見たことがある。
「税優遇を使ったバクチ」というのはそういうことで、それはNISAにはそぐわないという判断である。
もっとも、一般株式を含めて広く投資できる現在のNISAの制度そのものは残るようだ。
でも、段階的に縮小される方向なんでしょうね。
もう1つ、ジュニアNISA は延長せず2023年の投資分で終了になるとのこと。
(この期間中に投資した分は20歳到達か、5年間の投資期間終了まで非課税になる)
使い勝手の面でも課題があったのかな。口座数が伸び悩んでいるそうだ。
対象の子供が18歳になるまで引き出せないというところで、複雑な制度になってるんですよね。
うまく使うと18歳以降の修学資金の確保などに役立つ制度ではあるんだけど、
うまく使いこなせる人はあまりいなかったということなのかなと。
つみたてNISA が一定の条件を満たす投資信託に限られてるってのはわかりやすくていいですけどね。
選択肢が少ないといえばそうだけど、長期投資に適したものが選ばれてると言ってよいでしょうし。
20年と非課税期間が長いのもあるけど、管理は楽だし、投資期間の長さからメリットは大きいでしょうと。
NISA口座の株式は非課税なのはいいことのような気がするけど、売却損を損益通算することができない。
当たり前といえば当たり前なんだけど、そこは悩ましいところではあったわけだし。
Author : Hidemaro
Date : 2019/12/02(Mon) 23:55
お金 | 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)
大嘗宮を見る
今日は午後に休暇を取ってお出かけしていた。
メインの目的地は皇居、大嘗宮の一般公開ですね。
皇居もいろいろ門があるけど、この一般公開では坂下門から入ることになっている。
坂下門ってどこから行くのがよいのかと地図を見たが、うちからだと東京駅だった。
桜田門駅が一番近いのかな。それに次いで二重橋前駅、どちらもうちからは行きにくいのだが。
東京駅で降りると、大嘗宮一般公開へ行く人は丸の内南口を出てと放送が流れていた。
東京駅というと、高速バス乗り場としてやってくることが多く、そうなると八重洲側なのだが、
丸の内側にやってくることもあって、それが晴海通りのバスに乗る時。東京駅ってバス乗り場だったか。
それはさておき、東京駅を出て、行幸通りを進むと、同じ方向へ向かう人がぞろぞろと。
お堀を渡ると、ここからは国民公園「皇居外苑」ということで、環境省の名前で看板が立っていた。
それで突き当たると、順路は左に曲げられる。そして、大量のカラーコーンが並べられた皇居前広場へ。
今日は全体的にはスムーズに人が流れていて、行列をなすことはあまりなかったのだが、
休日などで人が集中したときは、この広場に行列をつくって調整するのだろう。
このカラーコーンには「警視庁」のシールが貼られ、警備にあたっているのは警視庁の警察官。
すなわち、東京都の職員と設備を使って、大量の見学者の整理を行っているということ。それもお役目かね。
入口では手荷物検査と金属探知機による検査がある。
手荷物検査は普段から皇居内の庭園に入る人には課されているものだが、
水筒を見つけたら「一口飲んで」と、やや厳重。
検査が終わったところに待ち合わせポイントがあった。グループでやってきたときに再集結するポイントなのか。
そして、坂下門から皇居の敷地内に入る。
坂下門を過ぎると、さっきまで警察官が多かったのは嘘のように落ち着いた雰囲気。
警察官らしきはいるのだが、皇宮警察本部の職員、敷地外の公共区域は警視庁、皇居内は皇宮警察という役割分担なのか。
皇居というのは、江戸城跡でもある。
今回、大嘗宮が建てられたのは本丸の中、普段は皇居東御苑として一般公開されているエリアである。
江戸城にとっての中心だったが、現在の皇居にとってはあまり重要でもないところなんだよね。
それゆえに一般公開されているわけだし、大嘗宮を建てるにもちょうどよかったということなのかなと。
かつての江戸城を感じながら、見学できるのはいいことだと思いますけどね。
それで大嘗宮である。やはりこのために作っただけあってピカピカ。
今どき木造建築といえば、寺社のように長く使われることを想定した作りのものを見慣れていたが、
大嘗宮は仮設ということで、やや荒削りな印象も受ける。それがいいんでしょうけどね。
それと特徴的なのが随所で使われている皮付きの丸太、黒木造りというスタイル。
あまり建造物では見ない使い方なので戸惑うが、いいアクセントにはなってますね。
けど、皮ごと使うということは、削って形を整えられないということなので、木の選定は難しいよね。
各所に設けられた黒木灯籠、皮付きの木材の組み合わせで作られ、細い木もうまく使っているように見える。
しかし、削らずに所望の太さで、まっすぐで、皮まで美しいという条件を揃えるのは難しそう。
加工度の低さゆえの難しさってのは多そうだなと思った。
大嘗宮の正面では写真撮影する人が折り重なり詰まっていた。
僕は写真を撮るのも惜しいと、あれこれと観察していたんだけどさ。
少し左右にずれると、まだ身動きは取れるのだが、真っ正面ではゆっくり進んでと呼びかけてもなかなか。
ここがこの大嘗宮公開の最大のボトルネックでしょうね。
大嘗宮の敷地を外周から見学するのだが、正面の見学ルートは狭く、さらに真っ正面はひどく詰まる。
逆に裏側は広場からゆっくり観察できる。正面で見学しようと思わない方がいいのかもしれない。
あと、今回取り入れられたプレハブ造の建物、儀式の中核をなす建物ではないが、
儀式をしているところから見えることもあって、他の建物と同じようにむしろ張りになっている。
ということで案外調和しているのだが、そうなると気になるのが白い屋根。
板葺き屋根と調和する色だとなおよし、とは思ったがそういう選択肢はなかったのかもしれない。
もともと儀式の周辺にはテントなどが多く(それは前回もそう)、写真で見るとその白い屋根が目立っちゃうんだよね。
儀式の中核に関わる部分は見せないとはもともと言っていたが、建物だけでもいろいろ学びはあった。
そこから、出口はまったく別の方向で平川門、ここは竹橋駅が近い。
ここから電車に乗ってやってきたのは上野公園である。
半日とはいえ、せっかく休暇を取るんだからと、夜間開館日の博物館にやってきたと。
ミュージアムシアターで正倉院についてのVR作品をやっているので、それを見つつ、博物館も見て回ろうと。
ミュージアムシアターは月・火はお休みで、16時開始が最終回(夜間開館日でも)ということで、
大嘗宮を見学してから行くにはちょうどいいんじゃないかと。
正倉院内部をVRで見せるという作品で、現物を見られないものを見せるという点ではよい題材。
今までミュージアムシアターは無料券で見るばかりだったが、今回は500円払って見た。
その後、さらに中央通りを下って、秋葉原界隈へ。
ソフマップでソフマップカードの返却をして(cf. ラクウルはいかなるものか)、
中古品の売り場を見ていたら掘り出し物を見つけたので買って、それで帰ってきた。
なにかと充実した金曜の午後でしたね。
Author : Hidemaro
Date : 2019/11/29(Fri) 23:54
日常 | Comment | trackback (0)
テレビ会議で操作をサポート
ここのところ、社外の試験場に出張している人がいる。
試験開始時はいろいろなトラブルが相次ぎ、当初の計画は早くも崩れたそうだが、
立て直しを図り、なんとか軌道に乗ったと思ったら、なにやらエラーが出たよう。
それで、社内にいるチームリーダーが、こんなことが起きてるんだけど、と相談に来るので、
話を聞くと、どうもエラーは誤爆っぽい。
エラーメッセージを送ってもらって、明らかに誤爆であることはわかった。
それで少し考えたが、設定を変更するとこのエラーを消すことができることに気づいた。
試験項目によってはエラーメッセージを切ることは許されないのだが、
チームリーダーに確認すると、必要な試験はもう終わったとのこと。じゃあ切ろう。
そのためには、試験対象のシステムの設定変更をしなければならないが、
問題は今日、試験場に出張している人は、この設定変更の経験がないということ。
担当者の1人には操作方法を教えたので、E-mailや電話で指示をしてもなんとかなりそうだったのだが、
あいにく今日は出張していないので、そこに期待することは出来ない。
そこでどうしたかというと、テレビ会議を使った。
業務用ノートPCにはインカメラが付いている。それを試験場に持ち出してますからね。
インカメラで、システムにつながっているコンピュータの画面を映してもらったのだ。
幸いにして、今回の試験室は狭く、おかげでLANケーブルを試験室内に引き延ばせて、
インカメラの画質でわかるかどうか心配だったが、操作画面を判別するには十分だった。
やはり画面を見ながら操作を指示すると、的確に指示ができて、これまで経験がない人でもなんとかなった。
コンピュータの画面をインカメラに映すなんて、まどろっこしいことをするんだな、
と思ったかも知れないが、操作用のコンピュータがインターネット接続を想定した設定になっていないんだよね。
社内ネットワークへは明確に接続できない設定なのだが、社外ならそこのポリシーさえ満たせればなんとでも。
ただ、長きにわたりネットワークから切り離され、セキュリティ対策がろくにされていないのと、
社内ネットワークに明確に接続できない理由の1つでもあるけど、
システム用にネットワーク関係の設定をカスタマイズしてるから、なかなか難しいかなぁと。
テレビ会議も慣れだなとは思った。
これでも、普段からインスタントメッセンジャーとして使っているソフトでテレビ会議ができるだけよくて、
以前はテレビ会議対応の会議室同士をつないでやるしかなく、ハードルが高かったようなことも聞いている。
今回みたいに出張先で急遽テレビ会議を開く方法はなかっただろう。
もちろん、現在でも高品質の会議をしたければ専用の会議室で、備え付けの専用システムを使うべきだが、
設定にかかる手間を考えれば、簡易な方法でも実用上問題ないという考えは普及していた。
こんな簡易なので、ちゃんと指示できるかなぁとは思ってたけど、案外いけますね。
Author : Hidemaro
Date : 2019/11/28(Thu) 23:09
コンピュータ・インターネット | Comment | trackback (0)
ラクウルはいかなるものか
僕はビックカメラの株主なのだが、株主向けの事業報告書にクーポンが付いていた。
クーポンというのは、ポイント割増(キャンペーンで時々配布してるのと同じようなもの)と、
もう1つが「ラクウル」の買取金額割増クーポンである。
この割増というのが定額の割増で、買取金額いくら以上とかいう制限はない。
株主向けとはいえ、大盤振る舞いだなと思った。
ラクウル はソフマップがやっている通信買取サービスである。
ソフマップがビックカメラの傘下に入ったのは2006年のことだそう。
ソフマップへ期待するところはいくつかあったんだろうけど、その筆頭が中古品の取扱なんじゃないか。
ビックカメラ内に中古品や音楽・ゲームソフトの取扱を中心とした店舗を出しているのはそういうことじゃないかと。
ソフマップに長年蓄積された中古品の買取・再商品化・販売のノウハウに期待するところは多いようだ。
ビックカメラグループの新しい通信買取サービス「ラクウル」がソフマップのサービスなのは必然である。
通信買取というと、ある程度の物量がないと送料負担が気になるところだが、ラクウルは送料無料という。
なんか条件とかないのと調べたけど、物量に関する条件は全くなさそう。
条件は160サイズの箱に収まることぐらいに見える。
手元になんか売れそうなものがあったかなとおもったが、映像ソフトが2本あった。
1つは以前、他の中古屋に売りにいったらあまりに安くて、売る気になれなかったもの。
もう1つは、今度中古屋にガサガサと持って行くなら持って行こうと思っていたもの。
同時期にPayPayモールの送料負担キャンペーンに乗じていろいろ売りにだしていたけど、
この2つは手間に対して割に合わないだろうと判断していたので、ラクウルというのはちょうどよかった。
というわけで、集荷依頼を出した。箱も無料で用意してくれるらしい。
申し込んだ翌々日、ヤマト運輸の人がやってきて、物を手づかみで持って行った。
てっきり空箱を持ってきて、玄関先で収納するのかと思ったが、集配車の中で詰めるんですかね。
ともあれ、そこからソフマップの浦安センターに運ばれ(近いのに翌々日着だった)、そこから査定。
査定完了になったのは申込みから1週間後、集荷・配送にかかった時間を考えると、まぁまぁ早いかな。
他の中古屋に売りにいったら安かったという商品は、そのときよりは高い値段が付いた。
もう1つは「買取対象外品」という扱いだった。
値段が付かないほど価値がないのか、そもそも取扱対象ではなかったのか。
真相はわからないが、返却してもらうほどのものではないので、そのまま承認とした。
ちなみに返却の送料も無料らしい。
クーポン割増分を除いても思ったよりは高かったが、買取総額の4割以上はクーポンっですからね。
ラクウルの買取金は、ビック買取マネーにすれば10%増し、現金振込だと手数料負担250円となっている。
ビック買取マネーってのは、かつての プールポイント → ソフマップ買取ポイント のことだよね。
ビックカメラ・ソフマップ・コジマのポイントカードは実店舗では相互に積算・使用ができるが、
買取ポイントはソフマップカード独自機能の状態が続いていた。
このたびビックカメラ・コジマにも展開されたことで、名前が変わったって話ですね。
僕はビックカメラにもソフマップにもポイントカードを持っているが、現在は基本的にビックカメラに積算している。
その考えからすれば、今回の買取金もビックカメラに積めばよさそうだが、後で書く理由によりソフマップに積んだ。
ビック買取マネーを使うにしても、銀行口座の確認が必要になっている。
その方法はなんと1円振込が成立するかどうか。この1円はソフマップからのプレゼントである。
実際に使ってみての感想だが、確かに送ればそれで終わりなのは楽。
ソフマップといえば、PC本体・周辺機器とゲーム・映像ソフト、ここは間違えなく強い。
ただ、ラクウルでは他の古物商とも提携していて、服飾品・ゴルフ用品・楽器・酒(!?)なんていうのも入っている。
家庭の不用品まとめて引き取りますというところで考えているようだ。
やはり、それぞれ実績のあるところと組んでいるのは安心感もあるんじゃないか。
買取金の払い出しがビック買取マネーでほぼ一択なのは気になるけど(ヤフオク・PayPayフリマのPayPayと比べるとね)、
ビックカメラの実店舗はいろいろなもの置いてるから、店に行けばなんとでもなるだろうし、
ソフマップカードのビック買取マネーに払い出せば、ソフマップの通販でも使えますので。
さて、ラクウルといえば、現在こんなキャンペーンをやっている。
ラクウルにソフマップカードを登録した上で、ソフマップカードを店舗に提出すると、
その種類に応じて1000～300ビック買取マネーが付与されるというもの。
ラクウルのウォレット機能は、ポイントカードを店頭で表示する機能を兼ねている。
なのでポイントカード代替というところをきっかけにして、ラクウルに触れてもらおうという意図もあるのではないかと。
僕の持っている青色のソフマップカードは500ビック買取マネーもらえるということで、今度東京に行ったらやろうと。
ソフマップでもビックカメラSuicaカードを呈示するようになって、引き出しの中にしまっていたのだが、
これを機に返却して、バーチャル化してしまおうと思う。
捨てずに引き出しの中にしまっていたのは、ソフマップの通販では依然として紐付いているからというのもある。
実店舗のポイントカードはどれか1つあれば相互に使えるが、通販のポイントは各社独立してるんだよね。
インターネットで申し込めば、即時ポイント交換できるので、通販だけ各社独立してるデメリットは薄れたが。
いずれにせよ、どうしてもポイントカードがいる理由はもはやない。
Author : Hidemaro
Date : 2019/11/27(Wed) 23:54
買い物・消費 | Comment | trackback (0)
メールサーバー間でSMTPS使うの?
メールサーバーに手を入れているときに、GmailではSMTPSで受信したか否かで表示が変わるらしい。
暗号化のアイコンの意味ということで書かれているが、
まず、緑色の鍵マークは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形式のデータにはパスワードがかかっている。
とはいえ、このファイルが流出してパスワードを割られると、何があったかわからないまま認証されてしまう。
証明書発行も手動で手間がかかっていたので、自動化を試みることにした。
そのフローは次の通りである。
- WebサイトにLinuxのユーザー名・パスワードでログインする
- 登録されているE-mailアドレス(例えばGmail)にワンタイムパスワードを送る
- ワンタイムパスワードを確認して、秘密鍵・証明書をサーバーで作成する
- 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)