第11回:SCS★3の要求事項を読む⑥――「攻撃等の防御②」パスワードとアクセス権限の9つの評価基準

作成日: 2026-06-27


はじめに

「8文字以上、大文字・小文字・数字・記号を混ぜて、定期的に変える——それ、今でも正解ですか?」

パスワードについては、いろいろな「べき論」を耳にしてきたのではないでしょうか。以前は定期変更が当たり前とされていましたが、最近は「定期的に変えなくていい」という話も出てきて、結局どうすればいいのかわからなくなっている方も多いのではないかと思います。正直、私も「これが唯一の正解」とは言いにくいテーマだと感じています。

今回はSCS★3の要求事項のうち、パスワードとアクセス権限に関する3つの要求事項・9つの評価基準を確認していきます。規格が何を求めているかを整理しながら、現在のセキュリティのトレンドとも照らし合わせてみたいと思います。


「攻撃等の防御②」今回の全体像

今回確認するのは、3つの要求事項・9つの評価基準です。

NO要求事項評価基準の数
4-1-5パスワード設定ルール5つ
4-1-6パスワード管理ルール3つ
4-1-7アクセス権の管理ルール1つ
合計9つ

前回(第10回)と合わせて、「アイデンティティ管理、認証、アクセス制御」の大項目(4-1)が完結します。


1. 4-1-5 パスワード設定ルール(評価基準5つ)

4-1-5では、パスワードの設定に関するルールを定め、社内に周知することが求められています。

評価基準の内容を整理すると、以下の5点です。

  1. 4-1-5-1: デフォルトパスワードを変更するよう社内ルールを定めること(PC・サーバ・スマートデバイス・クラウドサービスのすべてが対象)
  2. 4-1-5-2: 推測されやすい単語(例:password123456、会社名など)を禁止するルールを定めること
  3. 4-1-5-3: 以下のいずれかの保護対策を講じること
    • 多要素認証を使用するか、10回以上の失敗でアカウントロックするうえで、パスワードを8文字以上にする
    • 上記のどちらも設定できない場合は、英大文字・小文字・数字を含めた10文字以上にする
  4. 4-1-5-4: 情報機器及びサービス間でのパスワードを使い回さないよう社内ルールを定めること
  5. 4-1-5-5: 上記のルールを、役員・従業員・派遣社員・受入出向者に周知すること

1・2・4は「そうですよね」という内容だと思います。聞いたことがあるルールが並んでいますが、意外とデフォルトパスワードのまま使い続けている機器が社内に残っていたりするので、改めて確認する価値はあると思います。ただ、ヒアリングベースだと本当の回答が返ってこないことがあるので、できれば診断ツールなどで炙り出したいところです。

もしかしたらおやっと思う人がいるかもしれないのが、4-1-5-3の「8文字以上」「10文字以上」という基準です。

SCSで求められているのは最低ラインとしては8文字ですが、現在のセキュリティのトレンドは少し変わってきており、セキュリティの標準を作る国際団体NIST(米国国立標準技術研究所)は2024年に、パスワードの長さについて15文字以上を推奨するガイドラインを出しました(最低ラインはSCSと同じく8文字です)。「複雑にするより、長くするほうが安全」という方向に変わってきています。このガイドラインが出た時に対応に迫られたセキュリティ担当者はいるのではないでしょうか。ユーザーID全部を長いパスワードに変更するようにするのは大変なので、管理者IDはとりあえず長くしたというような会社もあるのではないかと思います。

https://gblogs.cisco.com/jp/2024/10/talos-threat-source-newsletter-oct-10-2024

また、簡単にまとめてくれているサイトを案内しましたが、もっと詳しく知りたいという方はこちらが参考になります。

https://www.cybersecurity.metro.tokyo.lg.jp/links/690/index.html

なお、前回の第10回でも触れましたが、多要素認証が設定できる環境であれば、多要素認証を最優先で対応するほうが効果は高いと考えています。


2. 4-1-6 パスワード管理ルール(評価基準3つ)

4-1-6では、設定したパスワードをどう管理するかのルールを定めることが求められています。

  1. 4-1-6-1: パスワードを安全に保管するためのルールを定めること(紙媒体なら施錠管理、パスワード管理アプリの利用等)
  2. 4-1-6-2: パスワードの漏洩が判明した場合、またはその疑いがある場合に速やかに変更するための手順を定めること
  3. 4-1-6-3: 4-1-6-1・4-1-6-2で定めたパスワード管理ルールを、役員・従業員・派遣社員・受入出向者に周知すること

4-1-6-1の「パスワード管理アプリ等」について補足します。Chrome・Edge・Safariなどの主要ブラウザに搭載されているパスワード保存機能は、私はパスワード管理ツールの一部と考えています。かつては「ブラウザにパスワードを覚えさせるのは危険」と言われていた時代もありましたが、現在はセキュリティ機能が大幅に強化されてきているようなので、ブラウザでも十分ではないかと思うのですが、ブラウザ保存と専用ツールのどちらがより安全かという比較については、また別途まとめる予定です(このように追加で調べた内容はNoteの方に投稿しようと考えています)。

https://note.com/kei_scs

4-1-6-2は、漏洩が判明・疑われたときに「すぐに変更できる手順」を作ることを求めています。

ここで少し脱線になりますが、パスワードの「定期変更」についても触れておきます。以前は「定期的にパスワードを変えることで、万が一漏れても被害を最小化できる」という考え方が主流でした。ところが現実には、定期的に変更しても攻撃のリスクはあまり低減できなかったり、「末尾の数字を1増やすだけ」「password1→password2」のような形式的な変更になりやすく、むしろ強度が下がるという問題が指摘されるようになりました。そのため、NISTをはじめとした現在のガイドラインでは「定期変更を強制しない」方向に変わってきています。

SCSの要求事項の案でも2025年12月には「定期的な変更を要求しない」という要求事項がありましたが、2026年3月の更新で評価基準が削除されていました。定期的な更新はしなくて良いというのと、漏洩が判明・疑われた際にはすぐ変更するというのが同時にあると混乱すると考えたのかもしれません。

また、SCSとCSF(NISTのサイバーセキュリティフレームワーク)を読み比べると、考え方の違いが見えてきて面白いのですが、細かくなりすぎるのでこちらも今後のNoteに回します。


3. 4-1-7 アクセス権の管理ルール(評価基準1つ)

4-1-7は、評価基準が1つだけです。★3で求められているのはルールを定めることのみで、内容は以下の4点を含むことが求められています。

  1. アクセス権の発行・変更・削除は申請・承認制にすること
  2. 与えるアクセス権・入室許可の範囲は、必要な範囲に限定すること(最小権限の原則)
  3. 入室権限・アクセス権の棚卸を定期的に行うこと
  4. 与えたアクセス権の申請書または台帳を管理していること

これらは読んでわからないというものはないと思います。物理的な入退室管理(機密上の配慮が必要な場所や部屋)も含まれているのが特徴です。

評価基準は1つで「ルールを作ること」だけが求められているため、実現としては比較的取り組みやすい項目だと思います。ただ、「ルールを作るだけでは意味がない」というのは、第6回のガバナンス回でも触れたとおりです。特にアクセス権の棚卸は、システムが増えるほど管理が難しくなりますし、運用が止まると形骸化しやすい項目でもあります。

アクセス権管理と棚卸については、前回の4-1-1(ユーザーIDの管理)とも評価基準が少し似てますね。


まとめ:今回確認した9の評価基準

今回はパスワードとアクセス権をテーマに扱いました。パスワードの考え方は時代とともにアップデートされており、「以前は正しかったルール」が今は推奨されていないケースもあります。SCSの評価基準を満たすことは出発点として大切ですが、現在のトレンドを踏まえてより実効性の高い対策を検討することも、あわせて意識しておくと良いのではないかと思います。

ルールを作るだけでなく、周知・運用まで一体で取り組むことが大切です。特にパスワードのルールは「知っている」と「実際にやっている」の間に大きな差が生まれやすい領域なので、周知の仕方にも工夫が必要だと感じています。SCSの評価基準にはありませんが、可能であればシステム的にルールに反する設定ができないようにすることも大事です。


このブログが目指していること

私はグローバルな製造業グループのCSIRTリーダーとして働いており、セキュリティ製品を売る立場ではありません。自動車部品メーカーに勤めているため、取引先にセキュリティ要件を「求める側」であり、完成車メーカーから要件を「求められる側」でもあります。

その立場から、「このブログを読んだ担当者が、経営者を動かすための言葉と資料を手に入れられる」ことを目指して書いています。

「要求される側の現場目線」を込めようとしています。難しい言葉をわかりやすく言い換えるだけでなく、「現場では実際にどう判断するか」という視点を大事にします。


次回の予告

次回は「攻撃等の防御③」として、**プラットフォームセキュリティと技術インフラのレジリエンス(4-4・4-5)**を確認します。


相談してみませんか?

「ちょっと聞いてみたい」という段階でも構いません。私の経歴・支援内容の詳細は「このブログについて」をご覧ください。

→ このブログについて → お問い合わせはこちら(メール)

なお、SCSへの関心が高まる中、制度に便乗した不審な勧誘も出てきています。私のことも含め、見知らぬ相手を安易に信用しすぎないようご注意ください。経産省も注意喚起を出しています。

→ サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)に係る不適切な勧誘に御注意ください https://www.meti.go.jp/policy/netsecurity/20260427_scs.html


CISSP・情報処理安全確保支援士 | けい

コメント

タイトルとURLをコピーしました