ITベンダー・SIer・受託開発会社 × SCS評価制度 ― なぜ★4を求められる側なのか
SCS評価制度の全体像については SCS評価制度 対策ガイド もあわせてご覧ください。
SCS評価制度の議論で、★4を求められる側として最初に名前が挙がるのがITベンダー・SIer・MSPです。理由は単純で、顧客システムへのアクセス権限を持っているからです。
サプライチェーン攻撃の典型的な経路は、防御の堅い大企業を直接狙うのではなく、その企業のシステムを保守しているベンダーを踏み台にするというものです。攻撃者から見れば、1社を侵害すれば複数の顧客環境に到達できる、効率のよい標的になります。だからこそ顧客は、ベンダーのセキュリティ水準を確認したがります。
この記事では、受託開発・システム保守・MSP・SESといったIT事業者が、SCS評価制度にどう向き合うべきかを整理します。
自社が「サプライチェーンのどこにいるか」を確認する
まず立ち位置を確認してください。
| 事業形態 | 顧客から見たリスク | 想定される目標 |
|---|---|---|
| システム保守・運用受託（MSP） | 顧客環境への常時アクセス権を保有 | ★4 |
| 受託開発（顧客データを預かる） | 本番データを開発環境で扱う可能性 | ★4 |
| 受託開発（顧客データを扱わない） | ソースコードと成果物の保護 | ★3〜★4 |
| SES・技術者派遣 | 客先環境で作業する要員の管理 | ★3〜★4 |
| パッケージ・SaaS提供 | 自社サービスが顧客の基盤になる | ★4（政府調達ならISMAPも） |
| Web制作・受託（機密性低） | 限定的 | ★3 |
「顧客の本番環境に入れる鍵を持っているか」——これが★4かどうかの実質的な分岐点です。持っているなら、★4を前提に準備するのが合理的です（★4の対策実装ガイド）。
ITベンダー特有の7つの論点
1. 特権アカウントの管理
顧客環境の管理者アカウント、共有の保守用ID、退職者が知っている共通パスワード——ここがITベンダーの最大の弱点です。
★3では管理者アカウントへのMFAとアクセス権限の管理が、★4ではさらに認証サーバのログを月1回以上モニタリングすることが求められます。実務としては次の順で固めます。
- 保守用アカウントの棚卸し（どの顧客の、どのシステムに、どのIDでアクセスできるか）
- 共有IDの廃止、または廃止できない場合の利用記録の義務化
- MFAの適用（顧客環境側の制約で入れられない場合は、踏み台側で担保）
- 退職・異動時の即時失効の手順化と記録
「顧客のシステムだから顧客の責任」は通りません。鍵を預かっている側の管理責任として問われます。
2. リモート保守の経路
VPN、リモートデスクトップ、専用の保守回線、ベンダー用の踏み台サーバ。これらは★3の「自社の資産が接続している他社システムを把握する仕組み」に該当します。
接続先の一覧と、そこに至る経路の図を作ってください。ネットワーク構成図は第三者評価でも高い確率で求められます（ネットワーク構成図の書き方）。
古いSSL-VPN装置が残っている場合は、優先的に更改対象です。サポート切れ機器の利用停止・更改は★4の要求事項でもあります（SSL-VPNからZTNAへの移行）。
3. 開発環境と本番環境、そして「本番データ」
受託開発で最も指摘されやすいのが、本番データを開発・検証環境にコピーして使っているケースです。★4では保管データの暗号化ルール、データ保管先・取引先との情報共有ルールが要求事項になります。
対応の原則は3つです。
- 本番データは原則として開発環境に持ち込まない（マスキング・匿名化したテストデータを使う）
- やむを得ず持ち込む場合は、顧客の合意・期間・保管場所・削除手順を書面化する
- 開発環境も資産台帳とアクセス管理の対象に含める
クラウドの開発環境（検証用テナント、CI/CD、コンテナレジストリ）は台帳から漏れやすいので注意してください。
4. ソースコードと成果物の保護
Gitリポジトリ、ビルド成果物、設計書。これらは顧客の資産であると同時に、自社の情報資産でもあります。
- リポジトリのアクセス権の棚卸し（退職者・協力会社アカウントが残っていないか）
- 認証情報のハードコードが残っていないか（漏えい時の影響が最も大きい）
- ソースコードの持ち出し可否とその手段のルール化
近年はOSSの依存関係を通じた供給網リスクも問われます。★の要求事項に直接の項目はありませんが、顧客からの個別要求としてSBOM（部品表）の提出を求められるケースが増えています。★4の脆弱性管理体制と併せて設計しておくと、二度手間になりません（脆弱性管理体制の作り方）。
5. 協力会社エンジニア＝二次委託の管理
自社で受けた案件を協力会社に再委託する、あるいは協力会社の技術者を自社案件に参画させる。ITベンダーでは日常的な形態ですが、これは**★の「取引先管理」領域の中核**です。
★3では、機密情報を共有する取引先との間で、業務開始前に機密情報の定義・利用制限・保管方法・返還/廃棄を取り決めることが求められます。★4ではさらに、重要な取引先について年1回以上のセキュリティ対策状況の確認と、契約終了時の機密情報とアクセス権の回収・破棄手順が加わります。
実務では次の4点セットを整えます。
- 協力会社の一覧（重要度ランク付き）
- NDA＋セキュリティ要件を含む契約条項
- 参画時のアカウント発行と端末貸与のルール（私物端末での作業可否を明示）
- 契約終了時のアカウント削除・データ返還のチェックリストと記録
型は委託先管理の実装ガイドにまとめています。
6. 客先常駐・SESの要員管理
客先の環境で、客先のPCを使って作業する場合、その端末は自社の資産ではありません。しかし要員に対する教育・訓練の実施と記録は自社の責任です（★3の要求事項：新規受入時および年1回以上）。
常駐先ごとにルールが違う場合、自社の情報セキュリティ規程には「常駐先のルールに従うこと」＋「自社として最低限守ること（持ち出し禁止、SNS投稿禁止、インシデント時の自社への報告義務）」を書き分けておくと運用しやすくなります。
7. 顧客からのチェックシート対応コスト
ITベンダーは、顧客ごとに異なるセキュリティチェックシートへの回答に相当な工数を割いています。★はこの重複作業を圧縮する手段になり得ます。制度が浸透すれば「★4取得済み」の提示で個別回答の一部を代替できる可能性があり、これは営業面での実利です（チェックシート対応の実務、★取得を営業に活かす）。
政府調達を狙う場合
政府情報システムの調達にはISMAP（政府情報システムのためのセキュリティ評価制度）が運用されています。SCS評価制度との関係は併存・相互補完と見込まれ、ISMAP登録事業者は★4取得時に既存の管理策・証跡を流用できる見込みです。要件化の見通しは政府調達への組み込みロードマップを参照してください。
進め方（★4・9か月モデル）
| 時期 | やること |
|---|---|
| 1か月目 | セルフチェックと評価範囲の決定。顧客環境へのアクセス経路と特権IDの棚卸し |
| 2〜3か月目 | 共有IDの廃止、MFAの徹底、退職・異動時の失効手順の整備 |
| 3〜5か月目 | ログの取得・6か月保管の設計（FW・プロキシ・認証）と月次モニタリング開始 |
| 4〜6か月目 | ネットワークセグメンテーション、開発環境の分離とデータ取扱いルール |
| 5〜7か月目 | 脆弱性管理体制の構築、EDRの展開とアラート運用 |
| 6〜8か月目 | 協力会社の一覧化・契約条項の整備・年次確認の実施 |
| 8〜9か月目 | 文書と証跡の総点検、復元テスト、第三者評価の受審準備 |
情シス365による支援
情シス365自身がIT運用を受託する事業者であり、同じ立場としての実務を踏まえた支援を提供しています。
- 特権ID・アクセス経路の棚卸し： 顧客ごとのアクセス権と保守経路を可視化し、統制の設計へ落とす
- ログ基盤の設計： ★4のログ6か月保管とモニタリング運用の構築
- 開発・検証環境の整理： 台帳・権限・データ取扱いルールの整備
- 協力会社管理： 一覧化、契約条項、年次確認の運用設計
まとめ
- ITベンダー・SIer・MSPは**「顧客の鍵を預かっている」ため★4を求められやすい**立場
- 最大の論点は特権アカウントの管理。共有IDの廃止とMFA、失効手順の記録化から着手する
- 本番データの開発環境への持ち込みは最も指摘されやすい。マスキング運用への切り替えを検討する
- 協力会社エンジニアの参画・再委託は取引先管理の中核。一覧・契約・発行/削除記録の4点セットで固める
- 客先常駐でも、教育・訓練の実施と記録は自社の責任
- ★4取得は、顧客ごとのチェックシート対応コストを圧縮する営業上の武器にもなる
参考リンク：