業務をシステム化するとき、社内データやアクセスの安全性をどう確認すればよいのでしょうか。データの種類、権限、開発環境、再委託、事故対応を整理し、相談先と確認したい順序を初めての方にも分かりやすく解説します。
システム開発会社へ社内データや業務情報を渡すとき、セキュリティの専門用語をすべて理解してから相談しようとすると、準備が止まりやすくなります。最初に確認したいのは、どのデータを、誰が、何の目的で、どの環境で扱うのかです。
個人情報、機密情報、業務上重要なデータでは、許可するアクセスや記録すべき内容が異なります。 安全性は、認証の有無だけで判断できません。自社の業務とデータを前提に、システム開発会社と脅威やリスクを確認し、実装する対策と実装しない対策を合意して記録します。
確認時期を決めずに開発を始めると、後から追加対策が必要になったとき、責任分担が曖昧になります。開発・検証・本番で扱うデータが同じか、アクセスを許可する期間はいつまでか、不要になった権限を誰が削除するかも、相談前に確認したい項目です。分からない事項は未決定として残し、判断者と確認時期を決めます。
たとえば、テスト用に本番データを使う場合は、必要性、代替方法、マスキング、保存期間、削除方法を確認します。システム開発会社だけでなく、データを管理する社内責任者も確認に参加することが重要です。
データ分類、アクセス権限、ログ、バックアップを並べるだけでは、何をいつ決めるかが分かりません。
IPAの「『情報システム・モデル取引・契約書』からの見直しのポイント」が示すセキュリティ仕様の作成プロセスを参考にすると、セキュリティは開発の最後に確認する付属作業ではなく、企画や要件整理の段階から対象システムを踏まえて考えるものです。
発注側が業務とデータの情報を出し、相談先が技術的な対策案を示し、双方でリスクを評価します。 また、再委託先、開発・検証・本番環境の違い、アクセス期間、権限の削除、事故時の連絡と停止判断を一つの流れで確認する必要があります。対策を見送る場合も、理由と判断者を記録すれば、後で確認できます。
記録がないことが、対策の有無そのものより大きな不安になる場合があります。たとえば、バックアップを取ると決めても、対象データ、頻度、保存先、復元を試す担当者が決まっていなければ、事故時に使える対策か判断できません。観点を並べた後は、実施者、期限、確認方法まで落とし込みます。
再委託がある場合は、どの会社の担当者がどのデータへアクセスするか、元のシステム開発会社がどう管理するかも確認します。アクセス権限は付与だけでなく、変更と削除まで管理します。
システム開発の外注では、次の順序でセキュリティ仕様を確認します。
発注側は、扱うデータの種類、利用目的、必要なアクセス、アクセス期間、開発・検証・本番環境の区分、事故時の連絡先を整理します。法令や業界ガイドラインの適用は、事業分野やデータの内容によって変わるため、社内だけで判断できない場合は専門家への確認が必要です。
あわせて、データの保管場所、目的外利用の有無、返却・削除の時期と方法、必要に応じた監査や確認方法を合意します。通信・保存時の暗号化や脆弱性の確認方法も、対象データとリスクに応じて確認します。
セキュリティ確認を後回しにすると、本番データを開発環境へ持ち込む、不要な権限が残る、再委託先へのアクセス範囲が分からないといった問題が起きやすくなります。事故が起きた場合、誰が何を知り、どの対策を実装し、何を見送ったのかを説明できません。
一方で、すべてのリスクをゼロにすることを目指すと、業務の開始時期や実現範囲を決められなくなります。重要なのは、リスクを把握したうえで、実装する対策と見送る対策を判断し、その理由と責任者を残すことです。判断を記録しておけば、業務の重要度や環境が変わったときに再評価できます。
記録がなければ、同じ確認を繰り返し、担当者の記憶に依存します。セキュリティを工程に組み込み、対策の確認を受け入れや保守の条件にもつなげることが必要です。たとえば、対策を見送った場合は、代替策、残るリスク、再評価の条件を記録します。これにより、担当者が変わっても判断の背景を追跡できます。
新しい連携先や利用者が増えた場合は、以前の判断をそのまま使わず、データとアクセス範囲を見直します。定期的に確認する担当者とタイミングも決めておくと、導入後の運用へつながります。
まず、システム開発で扱うデータを、個人情報、機密情報、業務データなどに分類します。次に、誰が、どの環境で、いつまで、何の目的でアクセスするかを書き出します。開発・検証・本番で同じデータを使うのか、匿名化やマスキングが必要か、アクセスをどう記録するかも確認項目です。
保管場所、返却・削除、暗号化、脆弱性確認、監査の要否と、各項目の担当者・確認時期も一覧に加えます。 この一覧をもとに、システム開発会社へセキュリティ仕様の確認時期、対策の実装範囲、再委託、事故時の連絡方法を質問します。
自社で判断が難しい点は未決定事項として残し、要求整理サポートサービスや問い合わせで相談してください。確認表には、データの管理者、アクセスを承認する人、権限を削除する人、事故時に連絡する相手も記載します。
最初から完璧な対策表を作るのではなく、開発前に必ず決める事項と、設計・テストで確認する事項を分けて整理します。最後に、確認した内容を議事録や仕様書へ反映し、実装する対策、見送る対策、再確認の時期が分かる状態にします。
セキュリティ確認は、専門用語や認証の有無を並べることから始めません。データとアクセスの情報を出し合い、脅威とリスクを評価し、実装する対策と見送る対策を合意して記録します。確認時期と責任者を先に決めることが重要です。
利用目的、アクセスする担当者、期間、環境、再委託、記録、事故時の連絡方法を確認します。法令上の対応は個別事情に応じて専門家へ確認してください。
企画や要件整理の段階から確認し、どの時点で仕様として確定するかを合意します。開発終盤だけで確認するのは避けます。
対象のリスク、見送る理由、判断者、再確認時期を議事録や仕様書に残します。
再委託の範囲、アクセスするデータと権限、責任の所在、事故時の連絡経路を確認します。