本文へスキップ
NeoLogic
NeoLogic

「ログインとバックアップあり」で安全?小さな会社のシステム発注で確かめること

扱う情報、外から見える範囲、金銭や業務停止への影響から、必要な対策を決めます。担当外の閲覧、請求の二重操作、復旧の3事象で試し方を確かめ、Excelに発注条件を記入できます。

ログインと保存の機能に加え、見られる情報の範囲とバックアップから元に戻せるかを確かめるイラスト

小さな会社のシステムに必要なセキュリティは、扱う情報と止まったときの影響から選び、認証・権限・更新・秘密情報・通信・ログ・バックアップの七つを、開発会社に試験結果や記録で示してもらって発注します。

たとえば、社内の受注システムを発注し、見積書に「ログイン機能」「バックアップ」と書かれていた。この二つがあれば十分なのか、さらに何を頼めばよいのか。専門用語だけでは判断しにくい場面です。

社員12人の卸売会社で考えます(想定例)。営業は担当顧客の受注だけを扱い、経理2人と承認者1人は仕事に必要な範囲を確認する想定です。顧客向けのログインはありません。それでも、次の三つは確かめる必要があります。

表1 困る事象から、開発会社へ聞くことを決める

起きると困ること 発注者が決める条件 開発会社への質問と、見せてもらう材料
営業が担当外の顧客情報を開ける 誰が、どの顧客の何を見て変更・出力できるか 画面だけでなくCSV・添付も拒否できますか。権限表と、許可・拒否の試験結果を見せてください。
同じ請求が二重に確定する 同じ請求の確定は1回。別の正当な請求は扱う 二度押し・再送・同時操作でも件数や金額が増えませんか。確定件数・金額の記録を見せてください。
保存はあるのに業務を戻せない 停止は4時間まで、失える更新は1時間分まで データと帳票を戻し、業務を再開できますか。戻したデータの時点と復旧時間を示してください。

対策を選ぶ前に、自社ならどの情報や操作で困るかを置き換えてみてください。

対象は一般的な業務システムの発注です。以下の表は発注条件をそろえるための例です。工場制御や重要インフラなどの専門領域の扱いは、末尾で説明しています。

見られたら困る情報、止められない仕事

最初に、入力・保存する情報だけでなく、出力するCSV、添付ファイル、外部サービスへ送る情報も書き出します。情報が未整理だと、誰の閲覧を制限するか、何を復旧対象にするかを決められません。画面の一覧と、現在使っている帳票を開発会社と一緒に見るところから始めます。

情報資産とリスクを把握し、優先順位を付けて対策する考え方は、IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版(PDF)に基づきます。表1の質問を、自社が扱う情報と操作に置き換えて使います。公開ページも持つ場合は、非公開の管理機能とどう分け、管理者の本人確認と権限をどう試すかも聞いてください。

「止められる時間」と「失ってよい更新の期間」は別に決めます。例えば、営業中の停止は4時間まで、戻せるデータの時点は障害発生の1時間前以降、という条件です。締め日だけ条件が厳しくなる場合や、紙で代替できる時間も添えてください。

対策の名前と一緒に、設定と試験結果を見る

認証は「誰か」を確かめ、権限は「その人が何をしてよいか」を決めます。通信の保護、更新、ログ、バックアップは、それぞれ違う役割を持ち、併用するものです。製品名や対策数の多さで順位を付けず、自社の情報と影響に対応しているかを見ます。

認証・権限・更新など、七つの基本対策の質問を見る

表2 基本の対策と、見せてもらう材料(質問例)

対策 用途・条件 質問と材料
認証 他人のなりすましを防ぐ。管理者・社外接続などは強さも検討 個人別のIDですか。追加の本人確認が必要な場面はどこですか。設定と試験結果を見せてもらいます。
必要な権限 業務に必要な情報と操作だけを許す 閲覧・変更・承認・出力を分けた権限表と、許可・拒否の両方の結果を見ます。
更新 既知の弱点やサポート終了に対応する 本体・外部部品・基盤の版一覧、更新担当、判断期限、更新後の試験手順を聞きます。
秘密情報 接続用パスワードやAPIキーを守る 保管先、利用できる人、漏れた際の失効担当を聞きます。値そのものの提出は求めません。
通信 ログイン情報や業務データを通信途中で守る 画面と外部連携のどこを暗号化するか、HTTPS等の設定と証明書の更新担当を決めます。
ログ 操作・異常の経緯を追えるようにする 何を記録し、誰がいつ見るか。閲覧権限、保管期間、改変対策、秘密情報を残さない設定も聞きます。
バックアップ 消失・破損した情報を戻す 対象、頻度、保管先、復元手順と担当、復元試験の記録を見ます。取得成功だけで終えません。

権限・認証、更新、ログ、バックアップの基本はIPAガイドライン第4.0版、pp.29–34(PDF)に対応します。表は発注時に使う質問例としてまとめています。

管理者や重要情報を社外から扱う人については、パスワードに加えて別の要素で本人確認する多要素認証などを検討します。機能の有無だけでなく、対象者への適用、端末を紛失した際の回復方法、退職・委託終了時の停止まで含めて質問します。

外部サービス用のAPIキーなどの秘密情報は、保管・アクセス・失効を一組で扱います。コードや共有文書へ無造作に埋めず、平文のまま通信やログへ出さない考え方は、OWASP「Secrets Management Cheat Sheet」を参照しています。確認資料では値を伏せ、管理の仕組みを確認してください。

なお、ログを何日残すか、何分ごとに保存するかは、この表から一律には決まりません。調査に必要な期間、失える更新の期間、費用、契約条件を利用側が伝え、実現方法と運用負担を開発側とすり合わせます。

画面が動くこと以外に、何を確かめるか

他人の情報を開けないか

ログイン後も、利用者ごとに扱える情報を制限する必要があります。IPAの「安全なウェブサイトの作り方」1.11でも、本人確認に加え、利用者に応じたアクセス制御を扱っています。「ボタンを非表示にしました」だけで終わらせず、許可されない情報を実際に返さないことを開発会社に確認してもらいます。システムの外で起きる、偽の音声や動画を使った送金依頼への備えは、AIの偽音声・偽動画にどう備えるかで扱っています。

試す対象には画面だけでなく、CSVや添付ファイル、画面の裏でデータをやり取りするAPIも含めます。ブラウザー側の表示だけに頼らず、サーバー側で権限を確認する原則は、OWASP「Authorization Cheat Sheet」に基づきます。試験は、許可した環境・範囲と架空データで開発会社に実施してもらいます。

再送や同時操作で、金額が変わらないか

請求の確定では、二度押し、応答がない場合の再送、複数人の同時操作を質問にします。OWASPの「Web Security Testing Guide」WSTG-BUSL-05は、業務上の操作回数の制約を仕様から決めて検証する考え方を示しています。次の表では、同じ請求の確定を1回に制限する架空の仕様へ応用しています。

表3 開発会社へ試してもらう条件と、期待する結果

試す条件 期待結果の例 残してもらう記録
営業担当者が担当外の顧客データを扱う 閲覧・変更・CSV出力・添付取得が拒否される。許可された担当分は使える 役割と対象、期待結果、実際の結果、対象版、証跡
同じ請求確定の二度押し・再送・同時操作 同じ請求は1件だけ確定し、重複する金額加算がない。別の正当な請求は妨げない 請求の識別情報、実行条件、確定件数・金額、処理状態の記録
バックアップから別の検証環境へ復元する 対象の帳票・データを開け、合意した時点まで戻せる。復旧に要した時間を測る 復元対象、データの時点、開始・終了、確認結果、担当

試験結果は、対象の版、利用者の役割、試した条件、実際の結果、残った制約を添えて受け取ります。証跡を提出できない項目は、不明・未確認として残します。障害後の復旧時間は、データを戻す時間だけでなく、状況判断や業務再開の確認も含めて整理します。

記入例:社内の受注・請求システム

冒頭の卸売会社について、発注条件を一枚に記入すると次のようになります。担当者や未確定の事項まで含め、開発会社との打ち合わせで使う見本です。

表4 発注条件の記入済み見本

項目 記入内容
扱う情報 顧客担当者の氏名・連絡先、受注・請求情報。カード番号は保存しない想定。
利用者と公開範囲 社員12人の社内利用。営業は担当分、経理2人と承認者1人は業務に必要な範囲。顧客向けログインなし。委託先の管理アクセスは別に管理。
起きると困る事象 担当外データの流出、同じ請求の二重確定。営業中の停止は4時間まで、失える更新は1時間分までと仮定。
対策と試し方 表2の基本対策を聞き、表3の権限・重複操作・復元の試験を依頼する。4時間・1時間を満たせるかは、設計と復元記録で判断する。
開発側・利用側の担当 開発側:設計・実装・許可範囲の試験と記録。利用側:権限表・停止条件の承認と退職者の通知。保守側:更新・ログの点検・復旧の担当範囲を契約で確定。
記録日・版 記入例作成:2026-09-15/例v0.1。対象システム版は未定。
根拠URL 基本方針:IPA「中小企業の情報セキュリティ対策ガイドライン」(PDF)。権限:IPA「安全なウェブサイトの作り方」、OWASP「Authorization Cheat Sheet」。操作回数:OWASP「Web Security Testing Guide」。数値と役割分担は想定。
未確定・対象外 認証方式、保管先、保守の受付時間、復旧性能は不明。工場制御・重要インフラは対象外。顧客公開や決済連携を加える場合は再評価。

自社の条件を整理するときは、判断表と確認記録のExcelを使えます。記入済み見本と未記入の票を用意しています。

作る人、日々調べる人、異常時に動く人

同じ「バックアップ対応」でも、開発側が取得機能を作るだけなのか、保守側が失敗通知を見て復旧まで担うのかで範囲が違います。対策ごとに、作る人、設定する人、日常確認する人、異常時に判断する人を決めます。外部サービスの提供元が管理する部分と、利用者が設定する部分も分けてください。

協力・体制・変更手続を書き残す際は、IPA「システム開発の健全化に向けて」、pp.44–48(PDF)にあるアジャイル開発のモデルが参考になります。ここでは役割と変更範囲を文書にする参考とし、全案件に同じ契約上の義務を当てはめません。同モデルが本番リリース・運用を対象外としている点にも注意が必要です。

発注時は、対象システムと外部サービス、更新や復旧の担当、連絡先と受付時間、費用に含む範囲、対象外、変更時の合意方法を並べて比べます。開発の納品物として、権限表、設定・構成の説明、試験結果、運用手順をどこまで受け取れるかも決めます。退職者の通知は利用側、通知を受けた停止操作は保守側、と分ける場合は、通知の期限と停止完了の返答まで書きます。

例えば、平日日中の問い合わせ対応だけの契約では、休日の異常通知への対応は担当未定のまま残り得ます。停止許容時間が休日にも適用されるなら、開発会社・保守会社・クラウド提供元に受付範囲と復旧時の分担を確認し、別契約か自社対応かを決めます。連絡が取れる時間と、復旧を約束する時間は区別してください。

情報流出や停止の影響が大きい場合

重要な個人情報や決済を扱う、顧客ごとに情報を分けて社外公開する、管理権限の悪用で大きな損失が出る、短い停止でも業務が成り立たない。こうした場合は、基本表を埋めたうえで、専門家による設計確認や脆弱性診断を追加するか検討します。診断では、定めた時点と範囲の弱点を調べます。

追加確認の選び方は、影響に応じて評価・改善するIPAガイドライン第4.0版、pp.28・37(PDF)の考え方を踏まえています。追加する確認の対象機能、確認できる範囲、確認できない範囲、修正後の再確認を見積り時に聞いてください。例えば、IPA「アクセス制御や認可制御の欠落」が示すように、ログイン後の操作や情報へのアクセスも確認対象に含めます。

反対に、承認済みの公開情報を載せるだけで、利用者別の非公開情報も金銭処理もないページなら、顧客別の権限試験や請求の重複試験は対象外にできます。ただし、管理者の認証、更新、公開内容の復元などは別の確認です。試験から外すのは使わない機能に限り、必要な基本対策は確認してください。

工場制御や重要インフラなどでは、設備の安全、業界の要件、停止の影響を扱える専門家・設備提供元に相談します。法令や取引先の要求が関係する場合も、所管機関の資料や契約相手の正式な要件を取得してください。適合の可否は、その要件に沿って個別に確認します。

次の打合せには、自社の情報と影響を書いた表を持参し、開発会社の回答・材料・担当・期限を追記します。回答できない欄は「不明」のまま担当と問い合わせ先を決め、対策を見送る場合も理由と判断者を残します。公開範囲や扱う情報が変わったら、この表も見直します。

受入時の期待結果や記録の残し方は、システムの受入テスト・検収で確かめることで説明しています。継続運用や小さな改善の担当範囲を相談したい場合は、使っているシステムと困る場面を整理しておくと話を進められます。

安全に使える条件とあわせて、待ち時間が業務を止めている場合は操作ごとに原因を調べます(システムが遅いときに調べる順番と性能目標)。

保守・運用改善の相談窓口へ

試験結果を読むときは、同じ件数でも中身を見る

表1の質問には、画面の写真だけでなく、試した条件と保存された結果を組にして回答してもらいます。例えば、注文の再送教材では、登録後に応答が失われても1件であること、番号を変えると二重になる反例を確認しています。権限・同時実行・本番DBまでの確認ではないため、今回のシステムで試す範囲は別に決めます。

バックアップについても、データは戻るが添付が戻らない教材では、注文1件・4,000円が一致しても、注文書がなければ再開できないことを示します。保守先へは「成功した」という回答に加え、何を戻し、どの操作を、誰の権限で確かめたかを聞いてください。

小さな教材で扱わない認証・実際の権限・並行操作・外部送信については、許可した環境で開発会社が試した記録を確認します。教材の結果と、発注するシステムの結果を混同しないことも、確認する範囲を絞るために必要です。

参考出典

出典確認日:2026年9月15日。OWASPのWeb版は固定版番号や公開・更新日の表示がないため、確認時点の内容を参照しています。

あわせて読む

状況にあわせてご相談ください

いまの状況を選ぶだけで、次に決めることが見えてきます。気になる点があれば、こちらからお返事します。