システム開発前に確認したいセキュリティ対策
顧客が資料を送信し、担当者が処理し、管理者が進捗を見てメール通知するポータルを想定します。
発注側が自分でコードを検査する必要はありません。情報の共有範囲、委託先が確認する境界、引継ぎ後の仕事を判断できる説明が必要です。
対策を判断するには、記録の行き先、閲覧者、公開前に委託先が示す根拠を把握する必要があります。以下の問いで、プログラミングの知識がなくても範囲と役割を具体化できます。
1. どのデータを保護する必要があるか
画面のほかに、取得ファイル、メール、出力帳票、検証用データも確認します。一つの記録の行き先と各段階で扱える人を説明してもらいます。画面で隠すだけでは、他の経路を管理できたとはいえません。
使用しなくなる時期、保管・削除の判断者、出力済みのコピーの扱いも確認します。期間は企業が確認した業務上の要件に従います。削除機能があるだけで、開発側に保管方針を推測させないようにします。
そのうえで仕事ごとの権限を決めます。担当者は割当案件のファイル、管理者は進捗集計だけが必要かもしれません。
一律の方針ではなく、業務側で確認する例です。過大な権限と、制限が強すぎて別経路で資料を送る状態の両方を避けるためです。
誰がどの資料を扱うかが分かったら、ファイルの閲覧、情報の編集、一覧の出力など、操作ごとの権限を決めます。業務に合ったアクセス権限の決め方では、業務上の必要性を具体的な権限に整理し、開発側と確認する方法を説明しています。
外部サービスを使う場合、残る責任は何か
外部サービスを使っても役割の確認は必要です。サービス側の対策、構築側の設定・権限管理、顧客側の承認を分けます。不明な点は担当と確認資料を決め、大手基盤ならアプリ全体の対策が済んでいるとは考えないようにします。
2. 委託先はどのように安全性を確認するか
コードレビューは実装、外部部品の確認は既知の問題、設定確認は環境、不正利用の試験は制限の実施を調べます。
スキャンの指摘が少なくても、実施していない確認の代わりにはなりません。
許可された検証用の記録を二人分用意し、自分の記録は処理でき、他人の記録は画面とファイル経路の双方で拒否されることを確認できます。
権限解除後も関連経路を調べます。承認された範囲と環境で行い、実顧客の記録を無断で試すものではありません。
アクセス試験に加え、サービスのパスワードやアクセスキーの管理も確認します。広く共有する資料やソースへ混在させず、管理者、変更、不要時の解除を適切な範囲で決めます。
WebアプリではOWASP ASVSなどを、要件と確認方法の相談に使えます。ただし、すべてを機械的に適用するのではなく、適切な範囲を選びます。結果には環境、対象、指摘、限界を示し、外部の専門的な検査を使う場合は実施条件と役割も別途合意します。
結果から、対象と版、対象外、未解決の指摘、残るリスクの判断者が分かる必要があります。修正後の確認も指摘と結び付けます。確認していない、あるいは公開版が異なるなら、一覧の修正済み表示だけでは不十分です。
3. 問題があれば誰が判断・対応するか
指摘には影響を評価し、修正、再確認、リリース可否の担当を決めます。未解決なら軽減策やリスク受容を明確に判断します。一覧に記載したことや、画面で問題が起きていないことをもって解決扱いにしないようにします。
顧客資料の不正取得と、影響の小さい内部機能の問題では結果が異なります。
技術側は発生条件、情報範囲、対応案を分かる言葉で説明し、責任者が業務リスクを判断します。重要度のラベルや点数だけで文脈全体は決まりません。
維持契約では、報告窓口、含まれる修正、別途見積りとなる作業、更新の実施権限を確認します。
時間や対応条件が未定なら相談し、常時対応や即時修正を思い込まないようにします。受入れ後の責任の空白を防ぐためです。
稼働前に、問題の報告先、影響評価、アクセス制限の判断者、関係者への連絡を机上で確認できます。機微な実データを持ち込む必要はありません。事故が起きてから担当を探すのではなく、連絡と権限が機能することを確かめます。
公開後は、利用する部品の脆弱性情報と更新判断の担当を決めます。運用側と委託先の支援範囲の両方に関わるため、担当、管理アカウント、報告経路が変われば資料も更新します。
脆弱性の確認やシステムの更新は、引継ぎ後も続く作業です。委託先との契約では、支援に含まれる作業と社内で担う作業を分けておく必要があります。ソフトウェア保守には何が含まれる？では、役割分担を決める際に確認したい保守の範囲を整理しています。
4. 開発前に何を合意しておくか
相談後は、保護する情報と利用者、情報の経路、実施する制限を共通の範囲にまとめます。未決事項には確認者と期限を置き、プロジェクトで追える仕事にします。
確認計画には対象、時期、実施者、受け取る根拠を記載します。外部の検査にも許可範囲と指摘の受領者が必要です。未解決事項は別の一覧へ移すだけでなく、軽減策、判断者、見直す条件を残します。
引継ぎ前に、アカウント、警告、確認結果、残件の担当を確認します。受領側が実施できなければ、ソフトを受け入れても、その後の責任は未整理のままです。
引継ぎ先がこうした役割を担うには、手順、アクセス権、必要な確認記録を受け取る必要があります。資料の件数だけでなく、受け取ったものを実際に使えるかも確認しましょう。システム引継ぎ、何を受け取るべきかでは、プロジェクトを終える前に、次の担当者が業務を引き継げるかを確認する方法を説明しています。
想定する使い方と情報の流れをもとにFenixへご相談いただくと、開発範囲へ含める要件と、追加の専門的確認が必要な点を整理できます。
