新しい業務システムの発注書に入れたいセキュリティ確認項目

新しい業務システムを導入する際、発注書にセキュリティ要件を明記しないと、後から認証やログ管理、障害復旧、委託先の管理で問題が発生しやすくなります。まずは、IPAが示す中小企業向けガイドラインを参考に、社内の情報資産とリスクを洗い出し、必要な項目をリスト化しましょう。以下では、発注書に入れるべき具体的な確認項目を4つの領域に分けて解説します。

発注時に確認すべき認証要件

ユーザー認証方式は何か

システムが提供する認証方式を明示します。パスワードだけでなく、LDAPやActive Directory連携、シングルサインオン（SSO）など、既存インフラと統合できるかを確認しましょう。ベンダーに対して、認証方式の技術仕様書や設定例を提出させ、社内の認証基盤と整合性が取れるかをチェックします。

実務では、担当者が「このシステムはどの認証方式を採用していますか？」と質問し、ベンダーが具体的な設定手順や必要なライセンス情報を提示できるかを確認します。認証方式が社内ポリシーに合致しない場合は、代替案やカスタマイズの有無を交渉材料にします。

多要素認証の適用範囲は

重要データにアクセスできるユーザーや管理者アカウントには、多要素認証（MFA）を必須とする条件を入れます。具体的には、OTP（ワンタイムパスワード）やハードウェアトークン、スマートフォンアプリなど、どの手段を採用するかを明示し、導入コストや運用負荷も併せて見積もります。

発注書に「管理者権限を持つユーザーはMFAを必ず使用すること」と記載し、ベンダーに実装例や運用マニュアルの提供を求めます。導入後は、社内のIT担当者が設定チェックリストを使って適用状況を定期的に確認できるようにします。

認証情報の保管・廃棄方法は

利用者のパスワード、システム間の接続に使う鍵、証明書では、適切な保管方法が異なります。発注担当者が暗号方式の名前だけを指定するより、提供側に「どの認証情報を、誰が、どこで管理し、漏えいの疑いがあるときにどう無効化するか」を説明してもらいましょう。秘密値そのものを提案書やメールに載せてもらう必要はありません。

発注書には、対象情報、管理責任者、変更や失効を依頼する手順、利用終了後の扱いを確認する条件を記載します。自社で保有すべき管理用IDが提供会社の個人IDだけになっていないかも確かめてください。技術方式の妥当性は、システムの構成や用途を踏まえて専門担当者が確認します。保存時に暗号化されているという説明だけで、漏えいや不正利用が起きないとは判断できません。

操作履歴と監査証跡の取り決め

ログ取得項目と保存期間は

操作履歴は、事故や誤操作が起きたときに何を調べたいかから必要な項目を決めます。例えば顧客台帳なら、誰が、いつ、どの記録を閲覧・変更・出力したかを確認できるかが検討対象です。提供される履歴の種類、見られる担当者、追加契約が必要な項目、取り出せる形式を見積もり前に揃えて聞いてください。

保存期間にはすべての会社に共通する日数を置かず、自社の調査・契約・法令上の必要性、保存費用、個人情報の扱いを整理して決めます。提供側に、標準の保存期間と延長条件、古い記録を取り出す方法を示してもらいましょう。導入後の検収では、試験用のアカウントで行った操作が必要な項目として残り、許可された担当者が抽出できるかを確認します。

ログの改ざん防止策は

ログが残るだけでなく、その履歴を誰が変更・削除できるかを確認します。業務システムの管理者とログの管理者が同じ場合や、通常業務の画面から履歴を消せる場合は、調査時に記録が失われるおそれがあります。別の保存先を使う、削除権限を分けるなど、システムで実現できる方法を提供側へ説明してもらってください。

特定の暗号方式や外部送信を一律に指定する必要はありません。発注条件は、必要な期間の履歴を保護できること、権限変更も記録されること、必要時に社内の担当者が調査へ渡せることなど、確認したい結果として書きます。外部の保管サービスを使う提案なら、送る情報、契約先、追加費用、停止時の扱いも確認します。

検収時には、想定した権限で記録を消せないかを許可された試験範囲で確かめます。

監査権限と提供手順は

監査担当者がログを閲覧・抽出できる権限と手順を明確にします。権限は最小化し、閲覧は読み取り専用、抽出は監査期間限定の一時的権限とし、利用後は自動で権限を解除する仕組みを要求します。

発注書に「監査時のみ限定的にログ閲覧権限を付与し、利用後は即座に権限を取り消す」旨を記載し、ベンダーに権限管理のプロセス図と監査ログの取得手順書を提供させます。社内では、権限付与・解除の記録を別途保存し、定期的に権限設定の妥当性をレビューします。

障害復旧とデータ返却の条件

バックアップ頻度と保管場所は

バックアップは、どの仕事を、どの時点の状態まで戻したいかから頻度と対象を検討します。受注が頻繁に入る台帳と、月に一度更新する資料では、失ってよい更新量が異なります。提供側に対象データ、取得時点、保存先、保管世代、失敗の通知先を一覧にしてもらい、自社の業務条件と照らしてください。

別の場所に保存する案でも、同じ管理用IDで元データと複製の両方を削除できるかなど、障害や認証情報の侵害に対して残る弱点を確認します。保存頻度だけで判断せず、戻すための作業、費用、回線の制約も見積もりへ含めましょう。取得結果と復元テストの記録を誰が確認し、データやシステムを変更したときに何を再検証するかも、運用の担当と合わせて決めます。

復旧手順の検証方法は

復旧は提供会社がシステムを起動できるだけでなく、自社の担当者が必要な業務を再開できる状態を確認します。検収に使う試験では、対象データ、復元先、照合する帳票、完了の判断者を事前に合意しましょう。例えば受注台帳なら、注文数や明細が確認用データと一致し、後続の出荷処理へ進めるかまでを確認項目にできます。

試験は本番のデータや業務に影響しない範囲で計画します。実施頻度は契約や変更の頻度、業務の重要度に応じて相談し、全社一律の回数を前提にしないでください。目標とする再開までの時間、戻した後に失われる更新分、再入力の担当を整理すると、提供側の復旧作業と自社の業務再開に必要な作業を分けて見積もれます。

データ返却時の消去基準は

サービス終了時は、先に自社へ必要なデータが返され、別の環境で読めることを確認してから、提供側に残る情報の扱いを決めます。返却対象は帳票だけでなく、添付ファイル、履歴、マスタ、設定も含めて確認してください。返却の形式、期限、追加費用と、バックアップに残る情報がいつどのように処理されるかを分けて聞きます。

消去方法は媒体やサービス構成によって異なるため、複数回の上書きなど一つの方法を全環境へ当てはめません。提供側の処理手順、残る情報、法令や契約に基づく保持の有無、完了を確認する記録を合意します。証明書が出る場合も、それがどの範囲の処理を証明するのかが重要です。保存義務や紛争対応などが関係する情報は、自社の責任者や専門家と確認してから削除を依頼してください。

委託先管理とセキュリティ評価

委託先のセキュリティ評価基準は

委託先の確認は、預ける情報と接続権限、その業務が止まった場合の影響を基に行います。自社が必要とする認証、アクセス管理、障害連絡、再委託の扱いについて、提供側がどこまで実施し、どの資料で説明できるかを一覧にしてください。取得している認証や評価がある場合も、その対象範囲や有効性を確認します。

SCS評価制度などを参照する場合は、公式の名称・段階・適用範囲を確認し、存在しないランクを発注条件にしないでください。自社の調達ルールや取引先の要求とどう関係するかを整理した上で、必要な条件を合意します。制度の取得がないから直ちに契約できない、別の診断書があれば自動的に代替できる、とも決めつけません。

未対応事項がある場合は、その影響と改善計画を確認して責任者へ判断を戻します。

契約での責任分担はどう設定するか

システム障害や情報漏洩が起きた際の責任範囲を契約で明確にします。ベンダーの責任範囲（例：ソフトウェアの脆弱性修正義務）と自社の責任範囲（例：利用者のパスワード管理）を区分し、損害賠償額や違約金の上限は、双方のリスク評価に基づき個別に協議の上設定する旨を契約に明記します。

発注書に「セキュリティインシデントが発生した場合の責任分担と賠償額上限」を具体的に記載し、法務部門と協議のうえ条項を確定します。契約締結前に、担当者が「この条項で自社のリスクは適切にカバーされていますか？」と確認し、必要に応じて専門家の助言を受けます。

委託終了後の資産回収手順は

システムの利用が終了した際に、ハードウェアやライセンス、暗号鍵などの資産を確実に回収・廃棄する手順を定めます。回収リストを作成し、回収時の検査項目（シリアル番号、状態確認）と、回収後の処分方法（再利用、廃棄）を契約に盛り込みます。

発注書に「委託終了時は全資産を回収し、廃棄対象は規格に従い処理する」旨を記載し、ベンダーに回収報告書と処分証明書の提出を求めます。社内では、回収完了チェックリストを用いて資産が全て回収されたことを確認し、未回収があれば速やかに追跡・回収を実施します。