中小企業のシステムセキュリティはどこまでやるか｜必ず抑えること、予算次第で見送るもの、死守してほしい最低ライン

セキュリティは、発注する側が妥当性を判断しにくい領域です。過剰に売ることもできますし、黙って手を抜くこともできてしまいます。この記事では、予算の限られた中小企業のシステムでFUNBREWが実際にどこへ線を引いているか——何は予算に関係なく必ずやり、何は予算次第で外れ、最低限どこは死守してほしいのかを書きます。「万全の対策をします」とは書きません。線がどこにあるかを見せることが、この記事の目的です。

予算に関係なく、必ず抑えていること

代表的な脆弱性への対策

まず、OWASPが公開している「よくあるセキュリティの失敗」の一覧は必ず抑えます。OWASPは、Webアプリケーションのセキュリティに関する情報を公開している国際的な非営利団体で、代表的なリスクをまとめた「OWASP Top Ten Web Application Security Risks」を公開しています（最新版は2025年版／OWASP公式サイト）。ここに挙がっているような典型的な失敗を作り込まないことは、金額の大小にかかわらず前提としています。

一から設計しない。実績のある構成を使い回す

コストを抑える方法として実際に効いているのは、こちらです。サーバーの構築や管理の方法は、これまでのシステム開発で培ってきたやり方がセキュリティ的にも固いため、案件ごとに一から設計せず、同じ方法を採用しています。設計をやり直さない分の工数が浮き、しかも実績のある構成なので堅さも保てます。

FUNBREWができる限りLaravelを採用しているのも、同じ理由です。慣れた技術で同じ形を再現できることが、結果的にセキュリティとコストの両方に効きます。フレームワークとしての優劣という話ではなく、使い慣れた構成を繰り返し使うこと自体に価値があるという考え方です。

予算次第で外れるもの

正直に書きます。以下は、予算によっては実施しません。

「提案の俎上に上がらない」とはどういうことか

提案しても断られる、という話ではありません。中小企業のシステム予算では、その項目を含めた見積もりを出すこと自体が現実的でないことが多い、ということです。限られた予算の中で何を優先するかを考えたとき、これらは後回しになります。

ここを曖昧にしたまま「セキュリティ対策も万全です」と説明する方が、発注側にとっては危険です。やっていないことは、やっていないと分かっている方が判断できます。

引き継ぎで「これは危ない」と思う状態

実際に見つかるもの

他社が作ったシステムを調査すると、危険な状態が見つかることがあります。よく遭遇するのは次のようなものです。

• パスワードが暗号化されずに保存されている状態
• SQLインジェクションを許してしまう作り
• 古いままのサーバーやライブラリ
• 推測しやすい脆弱なパスワードの運用

引き継ぎの多くは調査から入るため、こうした状態は調査の過程で見つかります。見つけた場合は必ずお伝えしています。対応するかどうかは予算と相談になりますが、知らないまま使い続ける状態にはしません。放置した場合に何が起きるかはセキュリティ更新を放置するリスクにまとめています。

セキュリティを理由にした依頼は、実は多くない

実態として、「セキュリティがまずいので引き継ぎやバージョンアップをしてほしい」という入り方の依頼は多くありません。おおよそは「動かなくなった」「機能を追加したい」という別の用件から始まります。

これは、放置している会社が悪いという話ではありません。日常業務の中でセキュリティだけを理由に予算を取るのは、現実には難しいものです。だからこそ、別の用件で開発会社に相談するときに、ついでに現状を見てもらうのが最も現実的です。機能追加の相談のついでで構いません。

「セキュリティ対策をしてください」と言われたら、何を聞くか

その言葉が指すものは、会社ごとに違う

セキュリティ対策にもコストパフォーマンスの考え方があるため、まず顧客の事業内容や過去の経験を伺うようにしています。同じ「セキュリティ対策をしてほしい」という言葉でも、実際に想定されているものは大きく異なります。

• バックアップを取り、何かあったときに元に戻せる状態にしておくことを指している場合
• 問い合わせフォームに来るスパムを止めてほしい、という具体的な困りごとの場合
• 漠然と、他社で事故があったと聞いて不安になっている場合

どれが正しいという話ではなく、何に困っているかによって打ち手がまったく変わるため、最初に聞いています。網羅的な診断メニューを提示するより、この確認の方が先です。セキュリティの現状把握についてはセキュリティ監査チェックリストもご参照ください。

最低ラインとして死守してほしいこと

予算が厳しい場合でも、これだけはお伝えしています。サーバーと、PHPなどのプログラムのバージョンアップです。

これは、予算が無い状態でも今日決められる、ほぼ唯一の行動です。新しい対策を買い足すのではなく、今動いているものを古いままにしないという話なので、追加の製品導入も要りません。逆に言えば、ここが止まっているシステムは、他に何を足しても土台が古いままになります。

責任の分かれ目と、保守をどう考えるか

アプリとインフラで、責任の所在が変わる

アプリケーション側の不具合によるものは、開発者が面倒を見るべきものです。一方、インフラ部分——サーバーの保守やメンテナンスについては、顧客の方針が如実に出ます。バージョンアップを含む保守にどこまで予算を割くかは、最終的には発注側の判断になるためです。ここを開発会社任せの空白にしておくと、誰も見ていない状態が生まれます。

「保守は保険の掛け捨て」では納得されにくい

保守について、FUNBREWは「保険の掛け捨てみたいなものです」と説明しています。やっておかないといけないけれど、大半は何も起きずに終わるコストだ、という意味です。

ただ、この説明で顧客に納得していただくのは難しい、というのも正直なところです。そこで、保守の工数が余ったときには機能改修に充てる、というハイブリッド型を提案することがあります。掛け捨てで終わらせない契約の形もある、という選択肢の話です（FUNBREWの保守プラン）。開発現場でAIをどう使い、責任をどこで担保しているかは開発会社はAIをどこまで使っているのかにも書いています。

まとめ

予算の限られた中小企業のシステムでは、セキュリティに線を引かざるを得ません。FUNBREWの線は、必ず抑えるのが代表的な脆弱性への対策と実績のあるサーバー構成の再利用、予算次第で外れるのがWAFと脆弱性診断、保守の内容によって変わるのがログ監視、というところにあります。

そして最低ラインとして死守してほしいのは、サーバーとPHPなどのバージョンアップです。セキュリティを理由に相談される方は多くありませんが、機能追加や不具合の相談のついでに現状を見ることはできます。お問い合わせの際に、気になっている点を一行添えていただければ、調査の中で確認します。