引き継いだシステムで見つかるセキュリティ上の問題は、悪意ある実装ではなく、更新されないまま相対的に古くなったフレームワーク・ライブラリ・サーバーがほとんどです。バージョンアップで塞がるものが多く、実装そのものに問題がある場合は顧客に伝えて対応するかどうかの判断を仰ぎます。少し手を入れれば直る範囲のものは、他の作業に含めて対応し、事後に報告することもあります。
他社が作ったシステムを引き継ぐとき、発注側が気にするのは「何か見つかったら追加費用になるのか」という点です。セキュリティアップデートを放置した場合のリスクは一般論として整理していますが、この記事では実際に引き継いだ現場で何が見つかり、それをどう伝えているかを書きます。
見つかるものの多くは「相対的に古くなったもの」
引き継ぎ時に見つかるセキュリティ上の問題として最も多いのは、フレームワーク・ライブラリ・サーバーが古い状態のまま止まっているものです。作った当時に問題があったわけではなく、更新されなかった結果として相対的に古くなり、既知の脆弱性が残っている状態を指します。
この違いは重要です。作った会社の技術力が低かったから危険なのではなく、保守の中で更新する工程が入っていなかったから危険になっています。何も起きていない月にライブラリの更新をやっているかが、時間が経ったときに差として出てきます。
バージョンアップで塞がるものと、そうでないもの
見つかったものへの対応は、大きく二つに分かれます。
更新すれば自動的に塞がるものが多い
古さが原因のものは、バージョンアップを完了させると自動的に塞がることが多くあります。個別に対策を入れるより、更新をやり切るほうが確実で、後の保守も楽になります。
ただし、更新そのものが簡単とは限りません。長く更新されていないシステムほど、一度に上げなければならない幅が大きくなり、動作確認の量が増えます。直すより作り直したほうが早いという判断になる背景の一つがこれです。
実装そのものに問題がある場合は、伝えて判断を仰ぐ
更新では解決しない、実装のしかたに起因する問題もあります。この場合は顧客に内容を伝えたうえで、対応するかどうかの判断を仰ぎます。勝手に直さないのは、直す範囲によっては挙動が変わり、業務の手順に影響が出ることがあるためです。
費用はどのように扱っているか
費用の扱いは、直すのにかかる手間の大きさで変わります。少し手を入れれば直る範囲のものは、他の作業に含めて対応し、事後に報告する形を取ることがあります。都度見積もりを出して承認を待つより、直してしまったほうが早く、金額としても大きくならないためです。
一方、まとまった作業量になるものは、内容と必要性を伝えたうえで判断してもらいます。引き継ぎの見積もりの段階でどこまで織り込めるかは、事前の調査をどれだけできたかによって変わります。この点は引き継ぎの見積もりが甘くなるのはどんなときかに書いたとおりです。
なお、見つかったものをすぐに公表したり、大ごととして扱ったりはしません。動いているシステムに残っている問題は、多くの場合それまでも残り続けてきたものです。慌てて手を入れるより、影響の大きさと直す手間を並べて、順番を決めるほうが結果的に早く安全な状態になります。
環境側で手間取るのは、危険性より設定の作りの違い
サーバー・ドメイン・SSL証明書・各種アカウントの引き受けについては、致命的に困った経験はありません。ただ、扱いやすさには差があります。
DNSの設定は、AWSやCloudflareのようにエンジニアが扱う前提で作られているサービスであれば、必要な設定に素直に手が届きます。一方、サイト制作を主に手がける会社がよく使うサービスの場合、細かい設定の項目自体が用意されていないことがあり、やりたい設定に届かず手間取ることがたまにあります。
これは危険という話ではなく、引き継いだあとにできることの幅が変わるという話です。将来的にシステムを増やしたり、メールやサブドメインの構成を変えたりする予定があるなら、引き継ぎのタイミングで環境ごと見直す価値があります。
発注側が引き継ぎの前にできること
引き継ぎを検討している段階で、発注側から確認できることがあります。
- フレームワークやサーバーを最後に更新したのがいつか
- 更新作業が保守契約に含まれていたのか、含まれていなかったのか
- ドメイン・SSL・各種アカウントの契約が誰の名義になっているか
- 見つかった問題をどう扱うか(都度見積もりか、一定の範囲は作業に含めるか)を事前に決められるか
四つ目を先に決めておくと、引き継ぎ後に細かい判断で止まらずに済みます。引き継ぎ時に用意する資料についてはこちらの記事にまとめています。ご相談はお問い合わせからお受けしています。
この記事をシェア