【SCS評価制度★3徹底解説・第5回】「攻撃等の防御」とは？ID管理・多要素認証・バックアップ・パッチ管理を実務目線で解説

情報セキュリティ

SCS評価制度★3の評価項目を分野ごとに解説する本連載。

これまで、

  • 第1回：SCS評価制度★3の26項目の全体像
  • 第2回：ガバナンスの整備
  • 第3回：取引先管理
  • 第4回：リスクの特定

について解説してきました。

第5回となる今回は、「攻撃等の防御」を取り上げます。

「攻撃を防御する」と聞くと、

「ファイアウォールを導入する」
「ウイルス対策ソフトを入れる」
「EDRを導入する」

といったセキュリティ製品を思い浮かべる方も多いのではないでしょうか。

しかし、SCS評価制度★3で求められている「攻撃等の防御」は、それだけではありません。

ユーザIDや管理者IDの管理、多要素認証、パスワード、アクセス権、インシデント対応教育、バックアップ、ソフトウェアの安全な構成、セキュリティパッチ、マルウェア対策、ネットワーク境界の防御まで、非常に幅広い対策が含まれています。

実際、★3の26要求事項のうち、13項目が「攻撃等の防御」に含まれています。

つまり、SCS評価制度★3への対応を考えるうえで、この分野は実務上の中心ともいえる部分です。

一方で、要求事項を一つずつ見ていくと、必ずしも高価なセキュリティ製品を導入しなければならないわけではありません。

重要なのは、

誰が利用できるのか
どの権限を持っているのか
どのように認証するのか
脆弱性をどのように管理するのか
問題が起きたときに復旧できるのか

といった基本的な管理を、組織として継続できる状態にすることです。

本記事では、SCS評価制度★3における「攻撃等の防御」の13要求事項について、企業のシステム担当者やセキュリティ担当者が実際にどのような対応を考えればよいのか、実務目線で解説します。

前回までの連載記事

公式資料

IPA公式資料

IPAでは、SCS評価制度の要求事項・評価基準がExcel形式で公開されています。

また、IPAのページでは、★3・★4の要求事項・評価基準に関する解説書は2026年10月頃公開予定とされています。

経済産業省公式資料

経済産業省では、SCS評価制度の制度構築方針とあわせて、★3・★4の要求事項及び評価基準が公開されています。

なお、SCS評価制度は今後も解説書、取得ガイド、申請手続きなどの情報が追加・更新される可能性があります。

実際に★3取得を検討する際は、必ずIPAおよび経済産業省の最新情報を確認してください。

SCS評価制度★3における「攻撃等の防御」とは

SCS評価制度は、サプライチェーン全体のセキュリティ対策水準を高めることを目的とした制度です。

IPAによると、★3は一般的なサイバー脅威に対処しうる水準として整理されています。

そのため、「攻撃等の防御」でも、一部の高度な標的型攻撃だけを想定した特殊な対策ではなく、多くの企業が日常的に直面する可能性のある攻撃に対して、基本的な防御を確実に実施することが求められています。

SCS評価制度★3の「攻撃等の防御」には、次の13の要求事項があります。

要求事項 内容
4-1-1 ユーザIDの管理手続
4-1-2 管理者IDの管理手続
4-1-3 認証の強度・実装方法の決定
4-1-4 アカウントロック制御
4-1-5 パスワード設定ルール
4-1-6 パスワード管理ルール
4-1-7 アクセス権の管理ルール
4-2-2 セキュリティインシデント発生時の教育・訓練
4-3-4 適切なバックアップ
4-4-1 情報機器、OS及びソフトウェアの安全な構成
4-4-4 セキュリティパッチ・アップデートの手続
4-4-5 マルウェア感染からの保護
4-5-1 ネットワーク境界防護

公式の要求事項・評価基準は、IPAが公開しているExcelファイルで確認できます。2026年4月21日時点で、★3・★4の要求事項・評価基準が正式に公開されています。

ここから、一つずつ見ていきましょう。

1．ユーザIDの管理手続

要求事項4-1-1　ユーザIDの発行・変更・削除の手続を定めること。

情報システムを利用する際、多くの企業ではユーザIDが使用されています。

しかし、実際の現場では、

「入社時にアカウントは作成するが、退職時の削除が遅れる」
「部署異動後も以前のシステムにアクセスできる」
「複数人で一つのIDを共有している」
「誰がどのIDを使用しているのか分からない」

といった問題が珍しくありません。

SCS評価制度★3では、ユーザIDについて、単に発行するだけではなく、

発行
変更
削除

までを一連の管理プロセスとして整備することが求められています。

特に重要なのが、申請・承認の仕組みです。

例えば、新しい従業員が入社したからといって、システム担当者の判断だけで自由にアカウントを作成するのではなく、

「所属部署から申請する」
「責任者が承認する」
「システム担当者が発行する」

という流れを明確にしておくことが重要です。

また、原則としてユーザIDは個人ごとに付与し、共有を避ける必要があります。

やむを得ず共有IDを使用する場合には、実際に誰がそのIDを利用したのかを後から確認できる状態にする必要があります。

実務上のポイント

まずは、次の項目を一覧化することをおすすめします。

  • 利用者名
  • 所属部署
  • 利用しているシステム
  • ユーザID
  • 権限
  • 発行日
  • 最終確認日
  • 無効化・削除日

大規模なIAM製品を導入しなくても、最初の段階では台帳による管理から始めることができます。

重要なのは、誰が、何を、どの権限で利用できるのかを把握できることです。

2．管理者IDの管理手続

要求事項4-1-2　管理者IDの発行・変更・削除の手続を定めること。

一般ユーザのID以上に重要なのが、管理者IDです。

管理者IDが攻撃者に奪われた場合、

  • セキュリティ設定の変更
  • 新しいアカウントの作成
  • ログの削除
  • マルウェアの展開
  • 他の端末やサーバへの横展開

など、非常に大きな被害につながる可能性があります。

そのため、SCS評価制度★3では、管理者IDについて一般のユーザID以上に厳格な管理を求めています。

具体的には、

  • サーバやネットワーク機器の管理者・責任者を決める
  • 管理者権限を持つ人を限定する
  • 必要最低限の権限だけを付与する
  • 誰が管理者IDを持っているか把握する
  • 不要になったIDは速やかに削除・無効化する
  • 付与・変更・削除を申請・承認制にする

といった管理が必要です。

「全員が管理者」は避ける

中小企業では、

「設定変更が必要になるかもしれないから」
「管理者権限がないと不便だから」

という理由で、多くの従業員に管理者権限を与えていることがあります。

しかし、これは攻撃者の立場から見ると非常に好都合です。

フィッシングメールなどをきっかけに一つのアカウントを侵害しただけで、高い権限を取得できる可能性があるからです。

管理者権限は、必要な人に、必要な範囲で、必要な期間だけ付与することが基本です。

3．認証の強度・実装方法の決定

要求事項4-1-3　システム及び情報の重要度に応じて認証の強度及び実装方法を決定すること。

SCS評価制度★3では、すべてのシステムを同じ認証方法で守ればよいとは考えていません。

取り扱う情報やシステムの重要度に応じて、適切な認証方法を選択することが求められています。

特に重要なのが、多要素認証です。

★3では、重要な機密情報を取り扱うクラウドサービスについて、ユーザや管理者がアクセスする際の多要素認証が求められています。

例えば、

  • Microsoft 365
  • Google Workspace
  • クラウド型ファイル共有
  • クラウド型業務システム
  • その他、重要な機密情報を保存するクラウドサービス

などが対象になり得ます。

多要素認証とは

多要素認証は、異なる種類の認証要素を組み合わせる認証方法です。

代表的なものとして、

  • 知識情報：パスワードなど
  • 所有情報：ワンタイムパスワードや証明書など
  • 生体情報：指紋、顔、虹彩、静脈など

があります。

パスワードだけを盗まれても、それだけではログインできない状態を作ることが目的です。

まず重要なクラウドサービスから導入する

すべてのシステムに一度に多要素認証を導入することが難しい場合でも、

メール
クラウドストレージ
管理者アカウント
外部からアクセスできるシステム

など、攻撃された場合の影響が大きいところから優先的に導入することが重要です。

4．アカウントロック制御

要求事項4-1-4　パソコン及びスマートデバイスにはロック制御を行うこと。

攻撃者がパスワードを何度でも試すことができれば、総当たり攻撃によって認証を突破される可能性が高まります。

そのため、SCS評価制度★3では、パソコンやスマートデバイスに対するロック制御が求められています。

具体的には、

  • 認証に失敗するたびに次の試行までの時間を長くする
  • 一定回数以上失敗するとロックする
  • 技術的に対応できない場合には、より強度の高いパスワードなどの代替策を講じる

といった対応です。

また、端末へのログオンやスマートデバイスのロック解除では、最低限のパスワードやPINの長さも考慮する必要があります。

ただし、重要なのは単純に「何文字以上なら安全」と考えることではありません。

認証回数の制限、多要素認証、端末管理などを組み合わせて考える必要があります。

5．パスワード設定ルール


要求事項4-1-5　パスワード設定に関するルールを定め、周知すること。

パスワードについては、多くの企業が何らかのルールを持っています。

しかし、

「英大文字・小文字・数字・記号を必須にする」
「90日ごとに変更する」

といったルールだけでは、十分とは限りません。

SCS評価制度★3では、

  • デフォルトパスワードを変更する
  • 推測されやすい単語を禁止する
  • 必要な長さを確保する
  • 多要素認証やアカウントロックと組み合わせる
  • サービス間でパスワードを使い回さない
  • ルールを従業員等に周知する

ことが求められています。

特に危険なのは「使い回し」

一つのサービスからパスワードが漏えいした場合、同じパスワードを別のサービスでも使用していると、攻撃者は他のサービスへのログインを試みます。

このような攻撃は、パスワードリスト攻撃などと呼ばれます。

つまり、自社のシステム自体からパスワードが漏れていなくても、他のサービスから漏れた認証情報が侵入に利用される可能性があります。

「強いパスワードを一つ作って、すべてのサービスで使う」のではなく、サービスごとに異なるパスワードを使用することが重要です。

6．パスワード管理ルール

要求事項4-1-6　パスワードの管理に関するルールを定め、周知すること。

パスワードは、設定方法だけでなく、その後の管理も重要です。

SCS評価制度★3では、

  • パスワードを安全に保管する
  • 漏えいした、または漏えいした可能性がある場合の変更手順を定める
  • 管理ルールを従業員等に周知する

ことが求められています。

ここで重要なのは、現実的に運用できるルールを作ることです。

「パスワードは絶対にメモしてはいけない」

というルールを設けた結果、従業員が覚えやすい簡単なパスワードを使い回してしまっては、本末転倒です。

組織として許可したパスワード管理方法を明確にし、必要に応じてパスワード管理ツールを利用するなど、安全性と実務の両方を考えた運用が必要です。

7．アクセス権の管理ルール

要求事項4-1-7　アクセス権の管理ルールを定めること。

情報は、「ログインできるか」だけでなく、ログインした後に何を見ることができるのかも重要です。

例えば、

  • 営業担当者が経理データを閲覧できる
  • 退職予定者が重要な共有フォルダにアクセスできる
  • 一般ユーザがシステム設定を変更できる

といった状態は、情報漏えいや内部不正だけでなく、サイバー攻撃の被害拡大にもつながります。

SCS評価制度★3では、アクセス権について、

  • 発行・変更・削除を申請・承認制にする
  • 必要な範囲だけを許可する
  • 定期的に棚卸しする
  • 申請書や台帳を管理する

といったルールを求めています。

権限は「付ける」より「外す」方が難しい

多くの企業では、新しい業務が始まるたびに権限が追加されます。

しかし、部署異動や担当変更後に不要な権限が削除されず、何年も権限が積み重なっているケースがあります。

そのため、定期的に、

「この人は今もこの権限が必要なのか」

を確認する棚卸しが重要です。

8．セキュリティインシデント発生時の教育・訓練

要求事項4-2-2　　セキュリティインシデント発生時の対応に関する教育・訓練を行うこと。

セキュリティ対策というと「攻撃を防ぐこと」に注目しがちですが、実際にはすべての攻撃を完全に防ぐことは困難です。

そのため重要になるのが、

異常に気付いた人が、正しい行動を取れるか

という点です。

例えば、

  • 不審なメールの添付ファイルを開いた
  • 突然ランサムウェアと思われる画面が表示された
  • パソコンの動作がおかしい
  • 見覚えのないログイン通知が届いた
  • 誤って機密情報を外部に送信した

といった場合に、

「誰に連絡するのか」
「端末をどうするのか」
「何をしてはいけないのか」

を従業員が理解している必要があります。

SCS評価制度★3では、新規受入れ時に加えて、年1回以上の教育・訓練を行い、その実施内容や受講状況を記録することが求められています。

「教育資料を配っただけ」で終わらせない

実際のインシデントでは、知識だけでは行動できないことがあります。

そのため、

「ランサムウェア感染が疑われる場合」
「フィッシングメールの認証情報を入力してしまった場合」

など、具体的な場面を想定した訓練が有効です。

特に重要なのは、現場が迷わず報告できる環境を作ることです。

「怒られるかもしれない」
「自分で何とかしてから報告しよう」

という文化は、初動対応を遅らせ、被害を拡大させる原因になります。

9．適切なバックアップ

要求事項4-3-4　適切なバックアップを行うこと。

ランサムウェア対策を考えるうえで、バックアップは極めて重要です。

ただし、

「バックアップを取っているから大丈夫」

とは限りません。

SCS評価制度★3では、

  • 何をバックアップするのか
  • どの頻度で取得するのか
  • どの期間保管するのか
  • 重要な機密情報をどのように遠隔地へバックアップするのか
  • どのように復元するのか

を考えることが求められています。

特に見落とされやすいのが、リストア手順です。

バックアップデータが存在していても、

「復元方法を誰も知らない」
「担当ベンダーに連絡しなければ復元できない」
「実際に戻せるか確認したことがない」

という状態では、緊急時に利用できない可能性があります。

バックアップは「取得」ではなく「復旧」まで考える

重要なのは、

バックアップがあるか

ではなく、

必要な時間内に事業を復旧できるか

です。

取得対象、取得頻度、保管場所、復元手順、担当者まで含めて管理する必要があります。

10．情報機器、OS及びソフトウェアの安全な構成

要求事項4-4-1　情報機器、OS及びソフトウェアの安全な構成を確立し、維持すること。

パソコンやサーバには、多くのソフトウェアや機能が存在します。

しかし、利用していないソフトウェアや不要な機能を残しておくと、それ自体が攻撃経路になる可能性があります。

SCS評価制度★3では、

  • 許可していないソフトウェアを削除・無効化する
  • 許可されていないソフトウェアを自由にインストールできないようにする
  • 外部記録媒体の自動実行・自動再生を無効化する
  • サーバやネットワーク機器の設定変更を申請・承認制にする

ことなどが求められています。

「何が入っているか分からない」は危険

第4回の「リスクの特定」で解説した資産管理は、ここにつながります。

そもそも、

  • どの端末があるのか
  • どのOSを使っているのか
  • どのソフトウェアが入っているのか

が分からなければ、安全な状態を維持することはできません。

つまり、資産を把握し、その資産を安全な状態に保つという流れが重要です。

11．セキュリティパッチ・アップデートの手続

要求事項4-4-4　情報機器、OS及びソフトウェアへのセキュリティパッチ及びアップデートの適用に係る手続を定めること。

脆弱性を悪用した攻撃は、現在のサイバー攻撃における代表的な侵入経路の一つです。

SCS評価制度★3では、単に「アップデートする」というだけでなく、

  • サポートされている製品を利用する
  • サポートが終了した製品への対応を行う
  • 可能であれば自動アップデートを有効にする
  • 重大な脆弱性に対して一定期間内に対応する
  • すぐにアップデートできない場合は代替策を講じる

といった管理が求められています。

特に注目したいのが、重要度の高い脆弱性への対応期限です。

★3の評価基準では、ベンダーが「重大」「高リスク」と評価する脆弱性や、CVSS基本値7.0以上などの条件に該当する場合、原則としてリリースから14日以内のアップデートが求められています。

業務システムによっては、すぐにアップデートできない場合もあります。

その場合には、

  • 脆弱な機能を無効化する
  • ベンダーの回避策を適用する
  • 対象機器をネットワークから分離する
  • 通信を監視・遮断する

など、リスクを下げるための代替策が必要です。

「アップデートできないから放置」が最も危険

重要な業務システムほど、

「止められない」
「動作検証が必要」
「ベンダーの対応待ち」

といった理由で、パッチ適用が遅れることがあります。

その事情自体は現実的なものです。

しかし、

アップデートできないこと
と
何もしないこと

は別です。

適用できないのであれば、その間にどのような代替策を取るのかを考える必要があります。

12．マルウェア感染からの保護

要求事項4-4-5　システムをマルウェア感染から保護すること。

SCS評価制度★3では、ネットワークに接続するパソコンやサーバへのマルウェア対策ソフトウェアの導入が求められています。

また、

  • スキャン範囲を決める
  • スキャン頻度を決める
  • 実際にスキャンを実行する
  • パターンファイル等を更新する

といった継続的な運用も必要です。

導入しているだけでは対策にならない

実際の現場では、

「ウイルス対策ソフトは入っているが、正常に動作しているか確認していない」
「更新に失敗している端末がある」
「サーバだけ対象外になっている」

といったケースがあります。

セキュリティ製品は、導入した瞬間に対策が完了するものではありません。

導入後に正常に動作しているか・最新の状態が保たれているかを確認し続けることが重要です。

13．ネットワーク境界防護

要求事項4-5-1　ネットワークを適切に分離し、境界部分を防護すること。

最後がネットワーク境界の防御です。

SCS評価制度★3では、ファイアウォールやルータなどについて、

  • デフォルトの管理パスワードを変更する
  • 強固で一意のパスワードを使用する
  • 不要なリモートアクセスを無効化する
  • 不要なインバウンド通信を遮断する
  • ファイアウォールルールを管理する
  • 不要になったルールを削除・無効化する
  • インターネット経由の設定変更を適切に保護する

ことなどが求められています。

ファイアウォールは「置けば終わり」ではない

企業のネットワークでは、

「以前必要だった通信許可設定が何年も残っている」
「誰が設定したルールなのか分からない」
「管理画面がインターネットからアクセスできる」
「初期パスワードに近いパスワードを使用している」

といった問題が起きることがあります。

ファイアウォールやUTMは、導入するだけで組織を守ってくれるものではありません。

重要なのは、

どの通信を許可しているのか
その通信は今も必要なのか
誰が設定を変更できるのか

を管理することです。

「攻撃等の防御」で重要なのは製品ではなく運用

ここまで13の要求事項を見てきました。

非常に多くの項目があるため、

「SCS評価制度★3を取得するには、大規模なセキュリティ投資が必要なのではないか」

と感じるかもしれません。

しかし、実際の要求事項を見ると、その多くは、

  • IDを管理する
  • 権限を管理する
  • 多要素認証を利用する
  • パスワードのルールを決める
  • バックアップを取る
  • パッチを適用する
  • マルウェア対策を維持する
  • ファイアウォールの設定を管理する
  • 従業員を教育する

といった、セキュリティの基本的な対策です。

問題は、これらを「やっているつもり」になっている企業が少なくないことです。

例えば、

「退職者のアカウントは削除していると思う」
「バックアップはベンダーが取っているはず」
「パッチは自動的に適用されていると思う」
「ファイアウォールは導入時から触っていない」

という状態では、組織として管理できているとはいえません。

SCS評価制度★3で求められているのは、

対策製品を購入した証拠ではなく、必要な対策が継続的に実施される状態を作ること

だと考えると分かりやすいでしょう。

攻撃者の目線から考えると「基本対策の積み重ね」が効く

攻撃者は、必ずしも最も価値の高い企業だけを狙うわけではありません。

実際の攻撃では、

  • 推測しやすいパスワード
  • 多要素認証がないアカウント
  • 削除されていない古いID
  • 長期間放置された脆弱性
  • インターネットからアクセスできる機器
  • 過剰な管理者権限

など、侵入しやすいポイントが狙われます。

攻撃者にとって重要なのは、

「この企業をどうしても攻撃したい」
ということより、
「どこなら少ない労力で侵入できるか」

という場合もあります。

その意味でも、SCS評価制度★3で求められている基本対策を一つずつ実施することは、攻撃者にとっての「攻撃コスト」を高めることにつながります。

完璧な防御を目指すのではなく、

簡単には侵入できない
侵入しても簡単には権限を取れない
被害が発生しても復旧できる

という状態を作ることが重要です。

SCS評価制度★3への対応は、13項目を一度に始めない

「攻撃等の防御」には13の要求事項があります。

そのため、すべてを一度に対応しようとすると、担当者の負担が大きくなります。

実務では、次のような順番で整理すると進めやすくなります。

第1段階：現状を把握する

まず確認するのは、

  • どのシステムがあるのか
  • どのIDがあるのか
  • 誰が管理者権限を持っているのか
  • どこで多要素認証を使用しているのか
  • どの機器がサポート切れなのか
  • バックアップはどこにあるのか

といった現状です。

第4回で解説した「リスクの特定」と密接につながっています。

第2段階：危険度の高い部分から改善する

例えば、

  • 退職者アカウントが残っている
  • 管理者IDを複数人で共有している
  • 重要なクラウドサービスに多要素認証がない
  • サポート終了製品がインターネットに接続されている
  • バックアップから復元できるか分からない

といった状態は、優先的に改善する必要があります。

第3段階：ルールと手順を整備する

技術的な対策だけでなく、

  • ID発行・削除手順
  • 管理者権限申請
  • パスワードルール
  • アクセス権棚卸し
  • パッチ適用手順
  • バックアップ・復元手順

などを整備します。

第4段階：定期的に確認する

セキュリティ対策は、一度実施して終わりではありません。

人は退職し、システムは増え、脆弱性は新たに発見されます。

そのため、定期的な点検と見直しが必要です。

まとめ｜「攻撃等の防御」はSCS評価制度★3の実務の中心

今回は、SCS評価制度★3の「攻撃等の防御」について解説しました。

この分野には、★3の26要求事項のうち13項目が含まれています。

内容も、

  • ユーザID
  • 管理者ID
  • 多要素認証
  • パスワード
  • アクセス権
  • 教育・訓練
  • バックアップ
  • 安全なシステム構成
  • セキュリティパッチ
  • マルウェア対策
  • ネットワーク境界防護

と非常に幅広くなっています。

しかし、その本質は決して複雑ではありません。

重要なのは、

自社が何を持っているのかを把握し、必要な人だけが必要な権限で利用できるようにし、脆弱性を放置せず、万が一の場合にも復旧できる状態を作ること

です。

SCS評価制度★3への対応では、高価な製品を次々と導入することが目的ではありません。

現在の環境を把握し、自社のリスクに応じて、基本的な対策を確実に運用できる状態を作ることが重要です。

SCS評価制度★3への対応でお困りではありませんか？

SCS評価制度★3の要求事項を確認すると、

「自社ではどこまで対応できているのか分からない」
「ルールはあるが、実際の運用と合っていない」
「IDやアクセス権をどのように整理すればよいか分からない」
「多要素認証、バックアップ、パッチ管理のどこから手を付ければよいか分からない」

といった課題が見えてくることがあります。

株式会社クロイツでは、単にチェックリストを埋めることを目的とするのではなく、現在のシステム環境や組織体制を確認したうえで、

  • SCS評価制度★3の要求事項に対する現状確認
  • 不足している対策の整理
  • 優先順位の設定
  • 社内ルールや手順の整備
  • ID・権限管理の見直し
  • バックアップ・パッチ管理などの運用改善
  • セキュリティ教育・訓練
  • 継続的なセキュリティ運用

をご支援しています。

SCS評価制度への対応は、「認証を取得すること」だけを目的にするのではなく、実際のサイバー攻撃に耐えられる組織づくりにつなげることが重要です。

自社だけでの対応が難しい場合や、現在の対策状況を第三者の視点から確認したい場合は、お気軽にご相談ください。
お問い合わせの際は、相談内容に
「SCS評価制度★3について相談したい」
とご記載ください。

お問い合わせ

次回予告

次回の連載第6回では、SCS評価制度★3の**「攻撃等の検知」**について解説します。

サイバー攻撃は、侵入を完全に防ぐことだけでは対応できません。

「異常な通信や不審な挙動をどのように把握するのか」
「ログやネットワーク監視をどこまで行えばよいのか」

といった、攻撃を早期に発見するための考え方を実務目線で解説します。