SCS評価制度「★4（第三者評価）」の壁をどう突破する？審査官がチェックするID証跡と技術検証対策

★3と★4の差は、単なる「セキュリティ項目の多さ」ではありません。最大の違いは「審査の厳格さと証跡の求められ方」にあります。

• ★3（専門家確認付き自己評価）
  自社のチェック結果に対し、SCSセキュリティ専門家によるヒアリングや社内規程（セキュリティポリシー）の確認を中心に行います。「適切なルールが策定され、運用されているか」という説明責任を果たすことが主眼です。
• ★4（評価機関による第三者評価・技術検証）
  認定を受けた民間の独立した評価機関が客観的な審査を実施します。ここでは「規程があるか」だけでなく、「システム上で実際にその設定が有効に機能しているか」「未認可のアクセスが本当に遮断されているか」を実機で確かめる『技術検証』が行われます。

つまり、書類やマニュアルをどれだけ完璧に整えても、実機のシステム設定や運用ログに矛盾があれば、★4の審査は容赦なく不適合（落第）となります。

★4の審査ガイドライン（SCS-420 第三者評価ガイド／SCS-440 技術検証ガイド等）を読み解くと、特にID・認証領域において審査官が重点的にチェックするポイントは大きく2つあります。

「社外からの私物端末アクセスを禁止している」という規程があっても、審査官は言葉だけでは納得しません。技術検証では以下のような実環境での挙動確認が求められます。

• 未認可端末の遮断テスト
  会社支給端末（許可端末）以外から業務システムへアクセスを試み、システム的に確実にブロックされるか。
• 多要素認証（MFA）の回避不能性
  特定の通信経路や例外アカウントによって、ID・パスワード単体でログインできてしまう「抜け道」が存在しないか。
• IP制限・ネットワーク分離の実効性
  許可されていない拠点・ネットワークからの接続試行が即座に拒絶され、その拒否ログが正しく記録されているか。

★4の重要基準である「No.4-1-7-1」をはじめとする管理統制では、アカウントのライフサイクルに関する客観的証跡が厳しく問われます。

審査官は、適当に抽出した複数名の従業員（中途入社者、異動者、退職者など）をサンプリングし、以下の突合（突き合わせ）を要求します。

1. 申請・承認日時
   ワークフロー等でアカウント発行や権限変更が承認された日時
2. システム反映日時
   ID基盤上で実際にアカウントが有効化・権限付与されたログの日時
3. 退職時の即時剥奪
   退職日（または休職日）当日に、連携する全SaaSへのアクセス権が完全に無効化されているか

ここで「申請書はあるが、ID基盤側の操作ログが残っていない」「退職後も数日間アカウントが有効なままだった」といった事実が判明すると、運用の実効性がないと判断されてしまいます。

既存のクラウド環境（Microsoft 365やGoogle Workspace、各種SaaS）をそのまま運用している企業が★4の審査に挑むと、ほぼ確実に以下の「証跡の壁」に突き当たります。

• ログの保管期間が足りない（標準機能の限界）
  多くのSaaSやID基盤の標準プランでは、監査ログの保持期間が「30日〜90日」程度に設定されています。審査官から「半年前の特定アカウントの作成ログを提示してください」と求められても、ログが既に消えていて提示できない事態に陥ります。
• SaaSごとにログが散在し、整形に膨大な工数がかかる
  ID連携先が増えるほど、それぞれのサービス管理画面から個別にCSVをダウンロードし、申請履歴と突き合わせる作業が必要になります。審査対応だけで情シス担当者の業務が何週間もストップしてしまいます。
• ログ自体の改ざん耐性が証明できない
  手動でダウンロードして社内ファイルサーバーに保管したログは、「後から改ざんできる状態」とみなされ、客観的証拠としての信頼性を疑われるリスクがあります。

クラウド型IDaaS「Gluegent Gate（グルージェントゲート）」は、既存のMicrosoft 365やGoogle Workspaceと共存しながら、★4の厳しい審査基準をクリアするための「技術検証対応」と「監査証跡」をワンストップで提供します。

• 端末証明書（Secioss証明書）による厳格な個体認証
  許可された会社支給PC・スマートフォンにのみ電子証明書を配布。未認可端末からのアクセスは、認証画面に到達する前にシステムが自動遮断します。審査官の前で「私物PCからのアクセス拒絶」を確実に実演可能です。
• 位置情報・IPアドレス・MFAの複合ポリシー
  「社外からは証明書＋FIDO2/パスキー（生体認証）必須」「特定IP以外はアクセス不可」など、SCS基準が求める条件付きアクセスを柔軟かつ確実に強制できます。

• 最長数年間のログ保管に対応
  ユーザーのログイン履歴（成功・失敗・拒否理由）、管理者によるIDの作成・変更・削除・グループ所属変更など、あらゆる操作ログをクラウド上に自動保管。標準機能のように短期間でログが消失する心配がありません。
• 高機能な検索・エクスポート機能
  審査官から「〇月〇日の〇〇氏のアカウント権限変更ログ」を指定されても、管理画面からユーザー名や期間で絞り込み、瞬時に該当の監査証跡を出力できます。

• グループウェアや各種ワークフロー（Gluegent Flowなど）と連携することで、「申請の承認」をトリガーにしてGluegent Gate側のアカウントを自動プロビジョニング。
• 申請データとID基盤の反映タイムスタンプの乖離を最小限に抑え、監査で最も重視される「プロセスの完全性」を客観的に証明できます。

★4の取得を目指す企業が最も注意しなければならないのが、「ログの蓄積期間」というタイムリミットです。

第三者評価では、「審査を受ける当日に設定が正しければ合格」というわけではありません。審査官は「過去数ヶ月〜1年間にわたり、ルール通りに運用されていた実績（ログ）」を確認します。

つまり、2027年3月の制度受付開始と同時に★4の審査を申請・受審するためには、遅くとも2026年冬〜年明け早々にはSCS適合レベルのID管理運用を開始し、日々のログを蓄積していなければ間に合わない計算になります。

直前になって「来月から審査だから慌ててツールを入れる」のでは、提出できる過去ログが存在せず、取得時期が大幅に遅れてしまう（＝サプライチェーンからの要請に間に合わない）ことになります。

SCS評価制度の最上位基準である「★4」の取得は、サプライチェーンにおける自社のセキュリティ信頼性を最高レベルで証明し、競合他社に対する決定的な差別化要因となります。

しかし、そのハードルは「技術検証」と「厳格なログ突合」という実務の壁です。

既存のID基盤を活かしつつ、Gluegent Gateのようなセキュアゲートウェイを組み合わせることで、高額なシステム改修や運用の破綻を避けながら、最短ルートで★4適合の証跡体制を整えることが可能です。

2027年の制度スタートを見据え、まずは「今、審査官が来たら客観的なログを提示できるか？」という視点で、自社のID管理体制を総点検してみてはいかがでしょうか。