パスワードは定期変更すべきか？

#パスワードの定期変更

パスワード定期変更を支持する側にも言い分はあるんです。それは、パスワードが漏洩したことが後になって判明した場合、そのパスワードが有効だった期間に基づいて、被害の範囲を局限することができるということです。定期変更していないと、いつからいつまでの間がセキュアでない状態だったのかを後から特定できませんので、非常に広い範囲にわたって「被害が出た可能性がある」と判断せざるを得なくなってしまいます。

一方で、パスワードの定期変更は益よりも害が大きいというのがコンセンサスになりつつあるという議論は、日経BP IT Proの [「パスワードの強制定期変更」は時代遅れ、企業に再考促す](http://itpro.nikkeibp.co.jp/atcl/column/14/346926/031600480/) などに解説が載っていますが、要するに事の本質は、パスワードを記憶するのが人間の脳みそだという点にあります。

で、どうすればいいかというと、今のところ判断は分かれているようで、例えば、ISO/IEC 27002:2013の日本語訳であるJIS Q 27002:2014は、こうなっています。

> 9.4.3 パスワード管理システム 
（中略）
パスワードの管理システムは，次の条件を満たすことが望ましい。
（中略）
e)パスワードは，__定期的__に及び必要に応じて変更させるようにする。
f)以前に用いられたパスワードの記録を維持し，再使用を防止する。

将来は分かりませんが、今のところは定期変更推奨です。

#SSL/TLSサーバの秘密鍵・公開鍵の定期変更

TLSサーバの秘密鍵は人間の脳みそで記憶するわけではなく、サーバに保存するわけですから、定期変更不要論の対象ではありません。定期変更は有効です。

サーバ証明書には有効期限がありますから、普通は定期変更が行われますが、ときどき、前回のサーバ証明書申請の時に作ったCSRを保存しておき、更新申請のときに使い回す人がいます。__これはお勧めできません。__更新の都度、新しい秘密鍵・公開鍵を作って、CSRも新しいものを作って、それで更新申請するのが推奨です。HPKPを使っている場合だと、新しい鍵の作成とbackup PINの登録を事前に行っておく必要があって面倒ですが、そのぐらいの手間はかけましょう。

#その他の秘密情報の定期変更

これも人間の脳みそではなく、サーバや通信機器に保存するデータですから、定期変更は有効です！しっかり定期変更しましょう！と、言いたいところですが、これがいろいろあるんですよね。

- __IPSecのPSK__

- __Wi-FiのWPA2-PSKのPSK__
そもそもエンタープライズでPSKはないでしょう、IEEE802.1Xを使いなさいな、と、言うは易し行うは。。。予算とか。。。

- __RADIUSのshared secret__
偽RADIUSサーバや、偽RADIUSクライアント（Wi-Fi基地局など）を見破るための秘密値です。メーカーの設定例を見るとcisco123とかになっていますが、本番環境ではもちろん、こんな分かりやすい値ではダメです。

- __sshの公開鍵・秘密鍵__
問題は古い鍵の失効です。失効するにはサーバ上の``.ssh/authorized_keys``から該当エントリを消せばいいのですが、サーバの数が多くなってくると、これが不徹底になりがちです。

- __TLSでSession Ticket拡張を使う場合の秘密鍵__
これは、拙稿[TLSセッション再開 (session resumption) のしくみ](https://qiita.com/n-i-e/items/bb0e582011a5b1f9c28d)で説明したものです。

- __TLSのPSK__
これが使わることは少ないですが、Zabbix 3のサーバ・エージェント間通信の暗号化では、これが使われます。

- __Kerberosの共有鍵__
KerberosのKDC（鍵配布センター）と各プリンシパル（サーバなど）は共有鍵を持っており、これを利用してKDCは、プリンシパルに解読可能なチケットを発行するのです。ところで、例えばActive Directoryで、ドメインに参加している各サーバとドメインコントローラは、共有鍵を定期変更しているんでしょうか。知りません。というわけで、恐縮ながらこの件、緩募とさせていただきたく存じます。

- __SNMPv3の認証パスワード、プライバシーパスワード__
snmpwalkを駆使して手動と根性で何とかする！という人は別として、普通はZabbixなりnagiosなり、何らかのツールを使うと思いますので、SNMPv3のパスワードをサーバに記録することになります。

- __RDBMSのパスワード__
MySQLやPostgreSQLなどのユーザID・パスワードは、CMSの設定ファイルに書き込んだりしてサーバに記録することが多いと思いますが、MySQL 5.7.4以降では[パスワードの有効期限を設定できます](https://dev.mysql.com/doc/refman/5.7/en/password-expiration-policy.html)。この有効期限はデフォルトで無期限ですが、MySQL5.7.4～5.7.10はこのデフォルト値が360に指定されており、一年が経過するとパスワード有効期限切れでエラーが出る場合があるという話が[スラド](https://developers.srad.jp/story/15/06/09/0854208/)に載りました。

こんな感じで、言い出すときりがないんですが、正直なところ、こういうのの定期変更って、やってます。。。？

#参考文献

- ISO/IEC 27002:2013
Information technology -- Security techniques -- Code of practice for information security controls
http://www.iso.org/iso/catalogue_detail?csnumber=54533 （有料）

- JIS Q 27002:2014
情報技術－セキュリティ技術－情報セキュリティ管理策の実践のための規範
http://www.jisc.go.jp/ から検索可能

- RFC2865
Remote Authentication Dial In User Service (RADIUS)
https://tools.ietf.org/html/rfc2865 ([Google翻訳](https://rfcs.web.fc2.com/rfc2865.html))

- RFC3414
User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
https://tools.ietf.org/html/rfc3414 ([Google翻訳](https://rfcs.web.fc2.com/rfc3414.html))

- RFC4120
The Kerberos Network Authentication Service (V5)
https://tools.ietf.org/html/rfc4120 ([Google翻訳](https://rfcs.web.fc2.com/rfc4120.html))

- RFC4252
The Secure Shell (SSH) Authentication Protocol
https://tools.ietf.org/html/rfc4252 ([Google翻訳](https://rfcs.web.fc2.com/rfc4252.html))

- RFC4279
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
https://tools.ietf.org/html/rfc4279 ([Google翻訳](https://rfcs.web.fc2.com/rfc4279.html))

- RFC5077
Transport Layer Security (TLS) Session Resumption without Server-Side State
https://tools.ietf.org/html/rfc5077 ([Google翻訳](https://rfcs.web.fc2.com/rfc5077.html))