NIST 800-63Bでパスワード規程を見直す — Claudeで条文を1つずつ照合
90日ごとの変更や文字種の強制は、NIST SP 800-63B-4では禁止側に回りました。社内のパスワード規程をClaudeのProjectsで原文と突き合わせ、改定案と周知文まで作る手順です。
「90日ごとに変更」「英大文字・小文字・数字・記号を含む8文字以上」。こうした条文が残る社内規程は、NIST SP 800-63B-4の物差しで見ると、少なくとも2か所が禁止側に入ります。定期変更と文字種の強制です。この記事では、規程の条文を原文と1条ずつ突き合わせる作業を、ClaudeのProjectsで下書きまで進める手順を示します。
規程のどの条文がNISTとずれるか
先に結論を表にします。左は日本の社内規程によくある条文、右はSP 800-63B-4の3.1.1節(パスワード)の該当要件です。
| 規程によくある条文 | 800-63B-4の要件 | 判定 |
|---|---|---|
| 90日ごとに変更する | 800-63B-4の要件定期的な変更を求めてはならない(SHALL NOT)。侵害の証拠があれば変更を強制する(SHALL) | 判定見直し対象 |
| 大小英字・数字・記号を含める | 800-63B-4の要件文字種の組み合わせなど、ほかの構成ルールを課してはならない(SHALL NOT) | 判定見直し対象 |
| 8文字以上 | 800-63B-4の要件単独認証なら15文字以上(SHALL)。多要素の一部なら8文字以上 | 判定認証方式で分岐 |
| 最大文字数を16文字にする | 800-63B-4の要件最大長は64文字以上を許可する(SHOULD) | 判定見直し対象 |
| 貼り付け禁止 | 800-63B-4の要件パスワードマネージャーと自動入力を許可する(SHALL)。貼り付けも許可する(SHOULD) | 判定見直し対象 |
| 秘密の質問、ヒントの登録 | 800-63B-4の要件秘密の質問への誘導は禁止(SHALL NOT)。未認証者に見えるヒントも禁止(SHALL NOT) | 判定見直し対象 |
| 5回失敗でロック | 800-63B-4の要件連続失敗は100回以下に制限する。これは上限で、より低い値は認められる | 判定矛盾しない |
最後の行は見落としやすい点です。NISTは「ロックを緩めよ」と言っているのではなく、100回を上限として示しています。5回や10回でロックする運用は、そのまま残せます。
800-63B-4を社内規程の物差しにする前に
SP 800-63B-4は、政府機関の情報システムで利用者を認証するための技術指針です。位置づけを先に押さえておかないと、「NISTがこう言っているから」という理由だけで条文を直すことになります。
適用範囲は政府システム
SP 800-63シリーズは、職員や契約者を含む利用者が政府の情報システムに接続する場面を対象にしています。民間組織については、ISO/IEC 27001のような同等の基準に従うことを推奨する、という書き方にとどまります。社内規程が法的に拘束されるわけではありません。見直しの理由は「NISTの要件に合わせる」ではなく、「根拠のある最新の知見に照らして条文を直す」と書くほうが、経営層や監査への説明に使えます。
SHALLとSHOULDを分けて読む
文書中の大文字の語は、拘束力の強さを表します。SHALLとSHALL NOTは従わなければ準拠にならない要件、SHOULDは推奨、MAYは許容です。照合の表には、この区別を必ず列として持たせます。たとえば最大長64文字はSHOULDなので、規程で32文字上限にしていても「準拠違反」とは言えず、「推奨から外れる」という重さの指摘になります。
15文字と8文字の取り違え
最も事故が起きやすいのが最小長です。パスワードだけで認証する場合は15文字以上、多要素認証の一部として使う場合は8文字以上が下限になります。Claudeに「最小長は何文字か」とだけ聞くと、どちらか片方を答えて済ませることがあります。プロンプトで「単独認証と多要素の両方の値を、条件つきで引用する」と指定しておきます。
落とし穴
最小長を1つの数字で答えさせると誤る
800-63B-4の最小長は認証の構成で変わります。社内システムごとに多要素認証の有無が異なるなら、システム単位で「単独認証か、多要素の一部か」を規程側の入力に書き添えます。この前提が抜けると、改定案の数字がすべてずれます。
Projectsに置くものと入力の設計
照合の精度は、Claudeに渡す材料の分け方でほぼ決まります。Projectsには規程と原文を別ファイルで置き、役割をproject instructionsで固定します。
Projectsの準備
- 1
規程を条文単位のテキストにする
PDFのまま置くより、条番号を保ったテキストか表にしておくと、Claudeが「第7条第2項」のように参照を返しやすくなります。
- 2
NISTの原文を保存して置く
3.1.1節(パスワード)、3.2.2節(レート制限)、ユーザビリティの節を含むページを、テキストとして保存して追加します。要約ではなく原文を置くのが肝です。
- 3
project instructionsで役割を決める
「規程の条文を、原文の要件と突き合わせる」「原文に無いことは無いと答える」「引用は原文の英文そのままと節番号をつける」を書きます。
- 4
認証方式の前提を別ファイルで渡す
どのシステムが単独認証で、どれが多要素か。SSOの有無。パスワードマネージャーの会社支給の有無。ここが改定案の分かれ目になります。
Projectsはプロジェクトごとに独立した会話履歴と知識ベースを持ち、文書をアップロードして文脈にできます。知識がコンテキストの上限に近づくと、有料プランではRAGモードに切り替わって容量が広がります。取り出した断片をもとに答える仕組みと考えられるため、引用の正確さは後述の方法で必ず確かめます。Team・Enterpriseプランなら、プロジェクトを組織内で共有できます。規程の改定は複数人で見るため、ここは閲覧のみか編集可かを決めて共有します。
条文を1つずつ照合する指示文
照合は、規程の条文を1つずつ渡して同じ型で答えさせます。まとめて「全体を見直して」と頼むと、細かい要件の抜けが増えます。
次の規程条文を、プロジェクト内のNIST SP 800-63B-4と照合してください。
【条文】第7条第2項 パスワードは90日ごとに変更しなければならない。
出力は次の4項目だけにします。
1. 該当する原文の英文(そのまま引用)と節番号
2. 拘束力(SHALL / SHOULD / MAY のどれか)
3. 規程との関係(適合 / 不適合 / 原文に規定なし)
4. 原文に規定がない場合は、その旨だけを書く(推測で補わない)「原文に規定なし」を選択肢として用意するのが、この指示文の要です。選択肢がないと、Claudeは何らかの要件を当てはめようとします。たとえば過去のパスワードの再利用禁止は、3.1.1の要件一覧には直接の規定が見当たりません。ユーザビリティの節に、ブロックリストや使用済みを理由に拒否した場合のフィードバックの例があるだけです。この種の条文は「規定なし」と判定し、組織判断で残すか決める扱いにします。
例えば次のような形の回答が返れば、型どおりです(公式の要件に沿った形の一例です)。
1. "Verifiers and CSPs SHALL NOT require subscribers to change
passwords periodically." (3.1.1.2)
2. SHALL NOT
3. 不適合(定期変更を求めている)回答を採用する前に、次の節で原文との一致を確かめます。
引用が本物かを機械的に確かめる
照合結果の信頼性は、引用文が原文に実在するかで決まります。人の目で追うと数十条で破綻するため、検索で確かめます。NISTのページを保存したテキストに対して、Claudeが引用した英文の一部を検索します。
grep -n "change passwords periodically" sp800-63b.txt
grep -n -c "SHALL NOT impose other composition rules" sp800-63b.txt1件も出なければ、引用は原文にありません。要約や記憶から作られた文である可能性が高く、その行の判定は採用しません。引用が実在する場合も、確かめるのはもう1点あります。引用が属する節と、拘束力の語(SHALLかSHOULDか)が正しいかです。同じ話題の文が、要件の節とユーザビリティの節の両方に出ることがあります。
検証を依頼文に組み込む方法もあります。「引用した文の直前の5語と直後の5語も添える」と指示すると、前後を含めて検索でき、断片的な一致の誤認を減らせます。
改定案と従業員向けの周知文を作る
照合が済んだ条文から、改定案を作ります。ここは判断の割合が増えるので、Claudeには案を複数出させ、採否は規程の管理者が決めます。
改定案は「変える条文」と「残す条文」を分ける
たとえば定期変更の条文は、次のような差し替えが考えられます。
| 項目 | 改定前 | 改定案 |
|---|---|---|
| 変更の契機 | 改定前90日ごとに変更する | 改定案漏えいの疑い、または侵害の証拠があるときに変更する |
| 構成ルール | 改定前大小英字・数字・記号を含む | 改定案構成ルールは課さず、漏えい済み・よくあるパスワードの拒否を設ける |
| 最小長 | 改定前8文字 | 改定案単独認証は15文字、多要素の一部は8文字 |
文字種の強制をやめる代わりに、ブロックリストとの照合を入れる点が対になっています。原文は、侵害コーパス由来の値や辞書語、サービス名やユーザー名の派生語などと照合し、リストにあれば拒否して理由を示すよう定めています。システム側で実装できない場合は、規程の改定とシステム改修の順番を分けて計画します。
残る条文も忘れない
NISTが触れていない運用の条文は、見直しの対象外ではなく「原文に規定なし」として残ります。初期パスワードの配布方法、退職者アカウントの停止、共有アカウントの扱いなどです。ここを無理にNISTへ引き寄せると、根拠のない改定になります。照合表では「規定なし(現行維持)」の列を明示して、見直し漏れと区別します。
周知文の下書き
従業員に向けた周知では、「これまで当然だった習慣が変わる」ことを先に伝えます。依頼文の例です。
上の改定案を、全社員向けの周知文にしてください。
・定期変更が不要になる理由を、1文で書く
・「長いパスワードを推奨する」意図を、1文で書く
・パスワードマネージャーの利用と貼り付けが認められる点を書く
・漏えいの疑いがあるときの連絡先を最後に置く
・規程の条番号は書かない周知文に「NISTが言っているから」と書く必要はありません。社員が知りたいのは、いつ何をすればよいかです。根拠の説明は、規程の改定理由欄に書きます。
照合結果を規程の運用に戻す
照合表と改定案ができたら、同じ型の作業を他の規程にも広げられます。条文と外部の基準を突き合わせ、どの文書のどの節が根拠かを残す型は、ISMSの適用宣言書を社内規程と対応づける作業でも使えます。手順はISMSの適用宣言書をClaudeで下書きするにあります。規程と実績の食い違いを洗う型としては、決裁権限表と稟議実績の照合が近い構成です。
パスワードマネージャーを会社として導入する場合は、Claude 1Password連携の使い方で、パスワードを見せずにログインさせる仕組みを確認できます。Claude自体を社内で使う規程側は、社内AI利用規程にAI事業者ガイドラインは何を求めるかが出発点になります。
まとめ
パスワード規程の見直しは、条文数が少なく、原文の該当節も3.1.1に集まっているため、Claudeによる照合に向いた題材です。ただし、価値が出るのは回答の中身ではなく、引用を検索で確かめる工程を含めた型のほうです。定期変更と文字種の強制は禁止側、最小長は認証方式で分岐、ロック回数は上限100回で現行維持の余地あり。この3点を軸に、条文ごとの判定を表にして、採否を人が決めます。