作成日: 2026-06-25
はじめに
「あなたは今、何個のアカウントを持っていますか？」
アカウント管理が進んでいる会社では、MicrosoftやGoogleのアカウントに集約して、さまざまなシステムを1つのIDで使える環境もあると思います。一方で、経理・営業・勤怠・メール……と、システムごとに別々のアカウントが存在しているケースも多いのではないでしょうか。プライベートでは、ブラウザに記憶させているアカウントが100個を超えている、というのも珍しくないと思います。
そしてサイバー攻撃の多くは、「漏洩したアカウント」や「管理されていないアカウント」を起点に発生します。そもそも認証を回避するような高度な脆弱性を突く攻撃もありますが、退職した社員のアカウントがそのまま残っていて悪用された、運用会社に貸し出していたアカウントの利用状況を管理できていなかったなど、出張者のために認証強度を暫定的に下げていたなど、ちょっとしたことが原因でインシデントにつながる事例は少なくありません。
今回からは大分類「攻撃等の防御」に入ります。この大分類は13の要求事項・49の評価基準と、★3全体の中で最もボリュームが多い領域です。それだけ重視されているということでもあります。全4回に分けて進めていきます。
| 回 | 扱う内容 |
|---|---|
| 第10回（今回） | アカウントと認証（4-1-1〜4-1-4） |
| 第11回 | パスワードとアクセス権限（4-1-5〜4-1-7） |
| 第12回 | トレーニングとデータセキュリティ（4-2-2・4-3-4） |
| 第13回 | インフラのレジリエンス（4-5-1） |
まずは、アカウントをどうやって管理するかに向き合います。
「攻撃等の防御①」今回の全体像
今回確認するのは、4つの要求事項・19の評価基準です。
| NO | 要求事項 | 評価基準の数 |
|---|---|---|
| 4-1-1 | ユーザIDの管理手続 | 4つ |
| 4-1-2 | 管理者IDの管理手続 | 8つ |
| 4-1-3 | 認証の強度・実装方法の決定 | 4つ |
| 4-1-4 | アカウントロック制御 | 3つ |
| 合計 | 19つ |
評価基準が多いので、攻撃等の防御は要求事項ごとに確認していきます。
1. 4-1-1 ユーザIDの管理手続（評価基準4つ）
4-1-1では、ユーザーIDの発行・変更・削除の手続きを定め、適切に運用することが求められています。評価基準の骨格は次の3点です。
- 4-1-1-1： IDの付与・変更・削除は申請・承認制にすること
- 4-1-1-2： 共用IDは原則禁止（やむを得ない場合の例外条件あり）
- 4-1-1-3： 不要になったIDは速やかに削除または無効化すること
- 4-1-1-4： 特別なアクセス権限が不要になった場合も、当該権限を速やかに削除または無効化すること
ルールとして読むとシンプルに見えますが、正直に言うと、私は「ルールを守って作られたアカウントだけを管理すればいい」という考え方には少し不安を感じています。ルールが守られずに作成されてしまったアカウント、退職者のアカウントが削除漏れしているケース——そういった「想定外の存在」には、ルール管理だけでは気づけないからです。
そこで有効だと思っているのが、アカウントの棚卸しです。アカウントはシステムに紐づいて存在することが一般的なので、第8・9回で整備した資産管理台帳をベースに、定期的にアカウントの実態を確認する仕組みを作るのが現実的なアプローチではないかと思います。SCS評価制度を取りたいだけであれば実施していなくても問題にならないかもしれませんが、セキュリティリスクを低減したいのであれば棚卸しは効果が高い運用だと考えています。
ただ、こうした棚卸しの運用は決して楽ではありません。第6回のガバナンスの記事で「できれば1人でも専任の担当者がいるとセキュリティ対策は推進されやすい」と書いたのは、実はこういう理由もあります。
2. 4-1-2 管理者IDの管理手続
4-1-2は、ユーザーIDではなく管理者IDを対象にした項目です。評価基準の数がユーザーIDの2倍になっているのは、管理者IDが悪用されたときの被害が格段に大きくなるためです。
ユーザーIDと共通の要求事項（申請承認制・共用禁止・不要になったら削除）に加えて、管理者IDにはさらに以下の要求事項が追加されています。
- 権限は最小限に限定する（4-1-2-3）： 役割に応じた必要最低限の権限のみを付与する
- 管理者IDの把握（4-1-2-5）： 誰がどの管理者IDを持っているかを把握するための仕組みを整備する
- 本番環境での管理者権限操作を禁止（4-1-2-4）： 開発を担当する人員が本番環境で管理者権限操作できないようにする
- 管理者・責任者を定める（4-1-2-1）： すべてのサーバおよびネットワーク機器について、システム管理者と責任者を定める
- 操作権限の限定（4-1-2-8）： 管理者IDの付与・変更・設定変更を行う権限を、業務上必要な人員に限定する
これらを網羅的に管理できているかを評価するのが、実はもっとも難しいのではないかと感じています。大企業でも、海外拠点や子会社まで含めると「すべて管理できている」と自信を持って言える会社はそう多くないのではないでしょうか。
1つでも管理できていないアカウントが見つかったら★3が取れないということにはならないと思いますが、どのレベルで確認すれば評価として認められるかは、2026年10月頃に公開予定のガイドラインで明らかになってくるのではないかと思います。現実的な対応としては、第8回で整理した「重要システム」に絞って優先的に評価するアプローチが良いのではないかと思います。
3. 4-1-3 認証の強度・実装方法の決定
ここからは「認証」の話に入ります。まず、多要素認証（MFA）の説明をしなければなりません。
多要素認証とは何か
認証とは「本当に本人かを確認するプロセス」のことです（「その人がアクセスしてよいか」という認可とは別の概念です）。認証に使う情報は、大きく3つの要素に分類されます。
| 要素 | 内容 | 具体例 |
|---|---|---|
| 知識情報 | 本人が知っていること | パスワード、暗証番号 |
| 所持情報 | 本人が持っているもの | スマートフォン、ICカード、メールに届くワンタイムパスワード |
| 生体情報 | 本人の身体的な特徴 | 指紋、顔認証、虹彩 |
これらのうち異なる2種類以上を組み合わせるのが多要素認証です。
よく誤解されるのですが、「パスワード＋秘密の質問（母親の旧姓は？出身の小学校は？）」は多要素認証ではありません。どちらも「知識情報」を2回確認しているだけだからです。一方、「メールに届くワンタイムパスワード」は「所持情報（メールにアクセスできる端末やアカウントを所持している）」に該当するので、パスワードと組み合わせれば多要素認証になります。
パスワード単体が弱い理由は、情報漏洩リスクにあります。いつどこの企業が情報漏洩を起こすかわからない状況で、同じパスワードを複数のサービスで使い回していると、1か所から漏れたパスワードが芋蔓式に別のサービスへの不正アクセスに使われてしまいます。多要素認証はこれらのリスクに対して非常に有効です。
4-1-3（認証の強度・実装方法の決定）はSCSの「最大の難所」？
4-1-3の評価基準は以下の4つです。
- 4-1-3-1： すべてのユーザーIDについて、アクセス前に一意の認証情報（パスワード等）で認証すること
- 4-1-3-2： 重要な情報を取り扱うと考えられるクラウドサービスでは、常に多要素認証を使用すること
- 4-1-3-3： 多要素認証には、知識・所持・生体のうち異なる2種類以上を使うこと
- 4-1-3-4： 多要素認証の知識情報として用いるパスワードは8文字以上とすること
この中で私がSCS★3全体の中で最大の難所になる可能性があると感じているのが、4-1-3-2です。
「重要な情報を取り扱うと考えられるクラウドサービス」とは何かが明確に定義されていませんので、どのサービスが該当するかは、制度の運用が始まる中で事例が積み上がっていくと思います。ただ、Microsoftのサービスは確実に対象になるでしょう。
実際に対応しようとすると、このような問題が出てくるのではないでしょうか。認証アプリ（Microsoft Authenticator等）によるワンタイムパスワードで実装しようと思うけど、会社支給のスマートフォンがないので、従業員の個人スマートフォンにアプリを入れてもらうかどうか——いわゆるBYOD（Bring Your Own Device）の議論が避けられなくなります。個人のスマホを業務に使わせるのかという問題は、技術的な対応だけでは解決しません。準備手順の周知も含めて、社内調整のコストが意外と大きい項目だと思います。
参考として、古い情報ですが奈良教育大学がMicrosoft 365の多要素認証設定手順を公開しているのを見つけました。以前にある大学の公演を聞いたことがありますが、短い期間で入れ替わる学生にセキュリティルールを浸透させるのはとても大変らしいです。最新の手順はMicrosoft公式や各ベンダーの最新情報を確認することをお勧めしますが、イメージを掴む参考にはなると思います。
→ 奈良教育大学：Microsoft 365 二要素認証設定手順（古い情報のため最新確認を推奨） https://www.nara-edu.ac.jp/IPC/service_list/two_factor.html
4. 4-1-4 アカウントロック制御
最後はアカウントロックです。
- 4-1-4-1： 業務で利用するシステムを構成する端末（PCへのログオン・スマートデバイスのロック解除）に対して、「ログイン失敗のたびに試行時間を延長する」または「10回以上の失敗でアカウントをロックする」のいずれかを適用すること
- 4-1-4-2： 上記のいずれも設定できない場合は、4-1-5で求められるよりも強度の高いパスワードを代替策として使用すること
- 4-1-4-3： ロック解除を行う場合は、最低でも6文字以上のパスワードまたはPINを利用すること
これはブルートフォース攻撃への対策として古くから知られる手法です。ブルートフォース攻撃（別名：辞書攻撃）は、よく使われるパスワードをリスト化しておき、総当たりで試行して認証を突破する攻撃です。試行時間を延ばしたりアカウントをロックすることで、現実的な時間内での突破が難しくなります。
余談になりますが、パスワードスプレー攻撃という手口もあります。これは「1つのアカウントに大量のパスワードを試す」のではなく、「1つのよくあるパスワードを大量のアカウントに試す」攻撃です。アカウントごとの失敗回数が増えないため、アカウントロックでは防げない厄介な攻撃です。
ただ、こうした攻撃に対しても多要素認証は非常に有効です。パスワードが突破されても、もう1つの認証要素がなければアクセスできないからです。アカウントロックは重要な対策ですが、4-1-3の多要素認証はサイバー攻撃の防御としてとても効果的です。
まとめ：今回確認した19の評価基準
アカウントと認証は、防御の中でも特に重要な領域です。IDの管理・認証の強化・ロックの制御——これらによって「なりすまし」による侵入リスクを現実的なレベルに抑えられると思います。
特に多要素認証は、設定すれば終わりというものではなく、どのサービスに適用するか・社員への周知をどうするか・BYODをどう扱うかなど、運用設計が伴う取り組みです。早めに社内調整を始めておく価値がある項目だと感じています。
このブログが目指していること
私はグローバルな製造業グループのCSIRTリーダーとして働いており、セキュリティ製品を売る立場ではありません。自動車部品メーカーに勤めているため、取引先にセキュリティ要件を「求める側」であり、完成車メーカーから要件を「求められる側」でもあります。
その立場から、「このブログを読んだ担当者が、経営者を動かすための言葉と資料を手に入れられる」ことを目指して書いています。
「要求される側の現場目線」を込めようとしています。難しい言葉をわかりやすく言い換えるだけでなく、「現場では実際にどう判断するか」という視点を大事にします。
次回の予告
次回は「攻撃等の防御②」として、**パスワードとアクセス権限（4-1-5・4-1-6・4-1-7）**を確認します。「パスワードは定期変更しなくていい」という話など、最近の考え方のアップデートにも触れる予定です。
相談してみませんか？
「ちょっと聞いてみたい」という段階でも構いません。私の経歴・支援内容の詳細は「このブログについて」をご覧ください。
なお、SCSへの関心が高まる中、制度に便乗した不審な勧誘も出てきています。私のことも含め、見知らぬ相手を安易に信用しすぎないようご注意ください。経産省も注意喚起を出しています。
→ サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）に係る不適切な勧誘に御注意ください https://www.meti.go.jp/policy/netsecurity/20260427_scs.html
CISSP・情報処理安全確保支援士 ｜ けい
コメント