パスワードの定期変更は必要か？ 侵害時の対応と監査の確認点
「期限が来たので変更してください」という通知が届く。利用者は覚えやすい似た言葉へ変え、管理者は変更済みの割合を確認する。作業は終わったが、そのパスワードが盗まれていないか、使い回されていないかは分からない。監査の場で問いたいのは、変更した人数より、この運用がどの脅威へ効くのかである。
米国NISTと英国NCSCは、理由のない定期変更を求めず、侵害が分かった・疑われるときには変更する方向を示している。とはいえ、「定期変更をやめる」の一文だけを取り出し、侵害の検知も失効の手段もない状態にするのは不十分だ。本稿では、パスワード運用を変える際に何を置き換え、何を監査で確かめるかを整理する。
この記事の目次
期限を守ることと、盗まれた秘密を止めること
NIST SP 800-63Bの現行版は、検証者が利用者へパスワードの定期変更を要求しないことを規範として示し、認証情報が侵害された証拠がある場合には変更を強制すると定める。対象は米国のデジタルID指針の文脈であり、日本のすべての組織へ同じ法的義務を課す文章ではない。NIST SP 800-63B
英国NCSCも、定期的な失効を強制しないよう勧める。変更を繰り返す負担や、利用者が予測しやすい変更を行う問題を説明しつつ、侵害を知った・疑ったときには変更が必要だとしている。英国NCSC「Password policy: updating your approach」
二つは独立した機関の指針だが、定期変更と侵害時変更を無作為に割り付け、日本の企業の被害件数を比較した研究ではない。現場へ当てはめるには、利用する認証方式と、侵害に気付く経路を確認する必要がある。
また、定期変更をやめれば、同じパスワードを長く使い得る。そこで、作成時に広く知られた・侵害済みの文字列を避ける仕組み、使い回しを減らす支援、複数要素の認証を利用する設計も論点になる。NISTの文書は、パスワードを選ぶときのブロックリストなども扱う。期限の廃止だけで指針全体を実施したことにしない。
監査では「いつ変えたか」より、異常時の流れを見る
監査の問いを、「全員が一定日数以内に変更したか」から、「盗まれた可能性をどう把握し、該当する資格情報を止められるか」へ変える。対象は利用者アカウントだけとは限らない。管理者、外部委託先、共有が残る古い仕組みなど、侵害時の影響が大きい認証情報ほど、責任者と手順が明確かを確認したい。
具体的には、疑わしいログインや侵害通知を誰が受け取るか、該当アカウントを特定できるか、利用者へ安全に知らせるか、古いセッションや連携が残らないかを見る。ここで挙げる順序は編集上の提案で、NISTが全事業者へ同じ分数で処理せよと定めたものではない。
組織の規程に別の要求がある場合は、それを無視して変更することはできない。顧客との合意や適用される制度を確認し、必要なら方針の見直しを正式に進める。国際指針の存在だけで、自社の義務が消えたと解釈しない。
仮にシステムが侵害通知を受けても、担当がいなければ変更は実行されない。指標を入れ替えるだけでは足りない。異常の検知から失効、再登録、影響を受けた業務の確認まで、一つの訓練や想定事例でたどる意味がある。
「変えなくていい」は、使い続けていいとは違う
侵害が疑われるパスワードは、期限まで待たずに止める必要がある。本人から盗難の申告があった、他サービスの漏えいと同じ資格情報を使っていた、正当な利用と説明できないログインがあった、といった場面は、一律のカレンダーより具体的な判断材料になる。
ただし、異常なログインの検知にも誤検知と見逃しがある。知らせが来ないことを安全の証明にはできない。重要なシステムほど、一つの検知方法へ依存しすぎず、利用者の申告、サービス提供者からの通知、利用履歴の確認など複数の入口を持つ。
一方、単に利用者がパスワードを忘れた場合は、再設定が必要でも侵害とは限らない。本人確認と再発行の手順を安全にする仕事と、事故対応の評価を分ける。件数の多い再設定をすべて侵害として報告すると、必要な対応の優先順位が見えなくなる。
平時の方針と、漏えい通知後の対応を分ける
以下は架空の例である。一般従業員の業務システムでは、一律の短い周期で変更を強制しているが、侵害の兆候を受け取る窓口と失効手順を整備できる。この場合は、適用する契約や規程を確認してから、期限による一律変更を見直し、侵害の疑いに応じて変更を求める案を選ぶ。
ところが、特定のシステムでパスワードが漏れた証拠が出た場合には判断が逆になる。定期変更の予定を待たず、影響する資格情報を止めて再設定する。変更後も不正な操作がなかったかを確かめる。カレンダーを廃止することは、事故時の変更をやめることではない。
さらに、古い装置が共通の秘密を使い、個人別の認証やログを持たないとする。NISTの個人向けログイン指針をそのまま適用したかのように扱えない。共通の秘密を減らす計画や、使う範囲を制限する対策を先に検討する。期限だけの議論では管理者も利用者も分からない。
仮想例に、一定日数で被害が何割減るという数値はない。判断が変わるのは、脅威の手掛かりと認証方式が異なるからだ。
パスワードの有効期限と、ログイン状態の期限は別
NISTの同じ文書には、一定の条件でセッションの再認証を求める規定がある。これは「パスワードを定期的に新しいものへ交換する」ことと違う。画面を開いたままにできる時間を制限することと、秘密そのものを変更させることを混同すると、指針同士が矛盾しているように見える。NIST SP 800-63B「Session Management」
監査では、規程にある「期限」が何を対象とするかを確かめたい。ログイン状態か、パスワードか、管理者権限の付与か。別々の管理策なら、対象と理由を別々に説明できる。定期変更を見直しても、使われなくなったアカウントの無効化や退職時の権限削除まで緩める理由にはならない。
侵害の疑いを持った際、本人の端末が使えるかという問題もある。端末自体が危険な状態なら、そこで新しい秘密を入力させるだけでは守れない。安全な連絡と再登録の経路を用意し、必要に応じて他の認証要素やセッションも確認する。この作業は、通常の期限切れ通知より具体的な対応を要する。
もし規程の変更を監査で説明するなら、旧方式が防ごうとしていた脅威と、新方式で受け持つ統制を対応付ける。期限切れの一覧表だけを消し、代わりの確認記録がなければ、改善したか評価できない。侵害の兆候に気付く入口と、実際に止めた事例の検証結果を残す。
侵害発覚後は、次の認証に使うパスワードだけを変えて完了とはできません。既に認証されたセッションや、独立したAPIトークンで保護操作を続けられるなら、その経路も失効させる必要があります。定期変更の方針を見直すことと、侵害時にアクセスを止められる実装を確かめることは、別々に扱います。
方針変更後に見るべき結果
変更後は、期限切れによる再設定の手間だけで成功を語らない。侵害の兆候から失効までの経路が機能するか、古い資格情報で再ログインできないか、利用者が安全に復旧できるかを点検する。異常報告の増加は、必ずしも攻撃増加ではなく、報告しやすくなった可能性もある。
監査の記録には、適用する範囲、例外、何を根拠に侵害と疑うか、誰が変更を指示するかを残す。いきなり全システムの同じ日数規程を変えるより、認証の形ごとに実施できる条件を明らかにする。
読者が選ぶべきなのは、カレンダーの分かりやすさか最新の指針かという人気投票ではない。異常時に秘密を止められる運用を先に用意し、理由のない一律変更を見直す。実際の侵害が分かったら、その時点で変更と影響確認へ切り替える。