受託開発会社やSIerは、攻撃者にとって「一度の侵害で複数の顧客環境に到達できる経路」です。このため、一般の資材サプライヤーより厳しい水準を求められることがあります。評価の対象は自社が管理する範囲ですが、顧客環境へアクセスするための端末・アカウント・経路は自社側の責任です。開発環境の統制と再委託先の管理が最大の論点になります。
SCS評価制度の★取得について、現状アセスメントからギャップ分析、技術対策の実装、申請サポートまでをワンストップでご支援しています。
SCS評価制度 対応支援 を見る →SCS評価制度 総合ガイドIT企業は「経路そのもの」になる
サプライチェーン攻撃の文脈でIT企業が注目されるのは、取引の性質上、顧客のシステム内部に正規の権限でアクセスできるからです。部品を納入する企業と異なり、納品後も保守や運用で継続的に接続することが多く、その接続経路が攻撃の入口になります。
この構造から、発注側は次のような点を確認しにきます。
- 顧客環境にアクセスする端末は、どう管理されているか
- アクセスに使うアカウントは、誰が何人持っているか。退職時にどう止めているか
- 作業の記録は残っているか。誰がいつ何をしたか説明できるか
- 再委託先の要員も同じ経路を使っていないか
いずれも★3の要求事項26項目と重なりますが、IT企業の場合は「顧客環境に届く経路」という観点で問われる点が特徴です。
自社環境と顧客環境を分けて考える
相談でよくある混乱が、「顧客のシステムのセキュリティまで自社が問われるのか」というものです。整理すると次のようになります。
| 対象 | 誰の責任か | 自社の評価に含まれるか |
|---|---|---|
| 自社のオフィス環境・業務システム | 自社 | ○ |
| 顧客環境へ接続する端末 | 自社 | ○ |
| 顧客環境へのアクセス権限・認証情報 | 自社（付与は顧客） | ○ |
| 開発環境・ソースコード管理 | 自社 | ○ |
| 顧客の本番環境そのものの設定 | 顧客 | ×（ただし作業記録は自社） |
入口は自社の責任、部屋の中は顧客の責任と考えると整理しやすくなります。自社が守るべきは入口です。
開発環境の統制が最大の論点
一般企業のSCS対応と最も違うのがここです。開発環境には、次の3つのリスクが集中します。
| 論点 | 問われること | よくある不備 |
|---|---|---|
| ソースコード管理 | 誰がどのリポジトリにアクセスできるか | 全社員が全リポジトリを閲覧できる。退職者の権限が残っている |
| 認証情報の取り扱い | 接続情報がコードや設定に直書きされていないか | リポジトリ内にパスワードやAPIキーが残っている |
| 本番データの扱い | テストに本番データを使っていないか | 個人情報を含むデータを開発環境へコピーしている |
とくに2番目は、指摘されて初めて気づくことが多い項目です。過去のコミット履歴に残っている認証情報は、現在のコードから削除しても履歴からは消えません。まず現状を洗い出し、見つかった認証情報は無効化して発行し直すところから着手してください。
3番目については、本番データを持ち込まない運用に切り替えるのが原則です。切り替えが難しい場合は、マスキングした上で持ち込む、期間を限定する、持ち込み記録を残すといった代替の統制が必要になります。
顧客環境へのアクセス管理
顧客から付与されたアカウントは、自社側で棚卸しの対象に含めてください。自社のIDシステムの外にあるため、管理から漏れやすい典型です。
- 一覧を作る：顧客ごとに、誰がどのアカウントを持っているかを台帳化する
- 共有しない：チームで1アカウントを使い回すと、作業者を特定できません
- 退職・異動時に返却する：自社の退職手続きに「顧客アカウントの停止依頼」を組み込む
- 作業記録を残す：いつ、誰が、何のために接続したか。顧客から問われたときに即答できる状態にする
退職時の処理は特に重要です。自社のアカウントは止めても顧客側のアカウントが生きたまま残るケースが実際にあります。手続きに組み込んでおかないと、個人の記憶に依存することになります。
再委託先をどう管理するか
再委託先が顧客のデータや環境に触れるなら、実質的に同じリスクを負います。ここが管理されていないと、自社の対策が意味を失います。
- 契約に盛り込む：守秘義務に加え、セキュリティ要件と再々委託の可否を明記する
- 権限を絞る：必要な範囲・期間だけアクセスを許可し、終了後に速やかに停止する
- 記録を残す：誰が作業したかを特定できる状態にする
- 顧客への開示：再委託の有無と範囲を顧客に伝えているか確認する
注意したいのは、受け取った要求をそのまま再委託先へ流すだけでは管理したことにならない点です。自社が要件の意味を理解し、相手の実施状況を確認できて初めて管理になります。
顧客ごとに要求が違う問題
複数の顧客と取引していると、A社は★3、B社は独自のチェックシート、C社は自工会ガイドライン、と要求がばらつきます。顧客ごとに環境や運用を作り分けると、管理が破綻します。
現実的な解は、最も厳しい顧客の要求を自社の標準とし、それ以外はその標準の範囲内で運用することです。個別対応の積み上げより、標準を1つ持つほうが管理コストは下がり、新規の要求にも短時間で回答できるようになります。
業界固有のガイドラインとの関係は自工会サイバーセキュリティガイドライン、既存認証との関係はISMS・Pマークとの違いを参照してください。
対応の進め方
| 順序 | やること |
|---|---|
| 1 | 顧客ごとのアクセス経路とアカウントを台帳化する |
| 2 | リポジトリの権限と、コード内の認証情報を洗い出す |
| 3 | 本番データの持ち込み状況を確認し、運用を決める |
| 4 | 再委託の範囲と契約条項を確認する |
| 5 | ★3の26要求事項に照らして残りを埋める |
1〜4はIT企業に固有の論点で、一般的なSCS対応の手順書には出てきません。ここを先に片付けておくと、以降は一般企業と同じ進め方で足ります。
なお、個々の評価基準の文言はIPAが公開する★3の評価基準（81基準）に定義されています。本記事はその文言の解説ではなく、要求を満たすために実務でどう設計するかを整理したものです。申請前には必ず公開されている最新の基準を参照してください。
よくある質問
IT企業がSCS評価制度に対応する必要はありますか？
顧客のシステムやデータにアクセスする立場である以上、要求される可能性は高いと考えてください。攻撃者にとって開発会社は、一度の侵害で複数の顧客環境に到達できる経路になります。この性質から、発注側は一般の資材サプライヤーより厳しい水準を求めることがあります。
自社環境と顧客環境のどちらが評価の対象ですか？
評価の対象は自社が管理する範囲です。ただし顧客環境へアクセスするための端末、アカウント、経路は自社側の管理下にあるため対象に含まれます。顧客環境そのものの統制は顧客の責任ですが、そこへ至る自社側の入口は自社の責任です。
開発環境で気をつけるべき点は何ですか？
ソースコード管理の権限、認証情報の取り扱い、本番データの扱いの3点です。とくにソースコードや設定ファイルに認証情報が直接書き込まれていないか、テストのために本番データを開発環境へ持ち込んでいないかは、指摘を受けやすい典型です。
再委託先にも同じ水準を求める必要がありますか？
再委託先が顧客のデータや環境に触れるなら、実質的に同じリスクを負います。契約に守秘義務とセキュリティ要件を盛り込み、アクセス権限を必要最小限に限定し、作業記録が残る仕組みにしてください。要件をそのまま流す前に、自社が説明できる水準に整理しておくことが重要です。
顧客ごとに求められる水準が違う場合はどうすればよいですか？
顧客ごとに環境を作り分けると管理が破綻します。最も厳しい顧客の要求を自社の標準とし、それ以外はその標準の範囲内で運用するほうが、結果的に管理コストは下がります。
まとめ
受託開発会社やSIerのSCS対応で固有の論点になるのは、顧客環境へ届く経路の統制です。評価の対象は自社が管理する範囲ですが、顧客環境へアクセスする端末・アカウント・経路は自社側の責任に含まれます。
まず顧客ごとのアクセス経路とアカウントを台帳化し、リポジトリの権限とコード内の認証情報を洗い出してください。この2つが片付けば、残りは一般企業と同じ進め方で対応できます。顧客ごとに要求がばらつく場合は、最も厳しい要求を自社の標準に据えるほうが管理コストは下がります。
自社の現在地を項目単位で確認したい場合は、SCS★3 セルフチェック（無料・登録不要） ↗で26要求事項・81評価基準への適合率を測れます。