社内の業務システムに必要なセキュリティ対策は？どこまでやるべきかを整理

社内の業務システムを作るとき、機能要件はかなり真面目に考えるのに、セキュリティは 社内向けだから後でいいか となりやすいです。
でも実務では、社内向けシステムでも事故は普通に起きます。VPN 経由で入られた、退職者アカウントが残っていた、権限が広すぎた、ログがなくて追えなかった、というのはかなりよくあるパターンです。

そもそも社内側のネットワークや接続方式を整理したい場合は、社内ネットワークとは？構成例・作り方・必要性をわかりやすく解説 や VPNとは？仕組み・種類・脆弱性・実務での対策を解説 も先に読んでおくと流れがつかみやすいです。

この記事では、社内の業務システムを構築するときに、最低限どこまでセキュリティ対策を入れるべきかを、実務で判断しやすい形で整理します。
2026年4月4日時点で、CISA の Secure by Design、CISA Cross-Sector Cybersecurity Performance Goals、NIST SP 800-218、OWASP ASVS 5.0.0 の公開情報を確認して構成しています。

まず結論、最低限ここまでは必要

社内向けでも、少なくとも次は外しにくいです。

なぜ「社内向けだから大丈夫」ではないのか

社内向けの業務システムは、外部公開のWebサービスほど露出していないこともあります。
ただ、実際の事故は「インターネットから直接叩かれた」だけで起きるわけではありません。

たとえば、次のような経路は普通にあります。

• VPN やリモートアクセス経由で社内に入られる
• 端末が侵害され、その端末から社内システムへ触られる
• 権限が広すぎて、一般利用者でも見えてはいけない情報に届く
• 退職者や使っていないアカウントが残り続ける
• 管理画面のURLは知っている人しか知らない前提で放置する

要するに、社内だけ はセキュリティ対策の根拠になりません。
むしろ、業務システムは経理、人事、顧客情報、在庫、原価、契約情報のような、止まると困るものや見られると困るものを抱えやすいです。

実際どこまでやるかは、4つの軸で決める

対策の濃さは、次の4つで考えると判断しやすいです。

この4つのうち2つ以上が重いなら、小規模だから簡易でよい はかなり危ないです。
逆に、閉じた小さなチームの簡易申請ツールで、個人情報もなく、止まっても紙で一時回避できるなら、最初から大規模SaaS並みの対策までは要らないこともあります。

まず実装したい対策

認証は「社内アカウントだから大丈夫」で済ませない

最低限でも、パスワード単独、共有アカウント、使い回し、退職者の放置は避けたいです。
可能なら SSO とアカウントライフサイクルを寄せて、管理者や重要機能には MFA を前提にした方がかなり事故が減ります。

特に、管理画面、権限変更画面、承認権限を持つ人のログインは一般利用者と同じ扱いにしない方が安全です。
CISA の Secure by Design でも、MFA、ログ、SSO を追加料金なしで使える状態にすべきだという考え方が示されています。社内システムでも、この発想はかなり相性がいいです。

認可は RBAC を前提にする

ログインできることと、何ができるかは別です。
ここが曖昧なまま進むと、あとで 営業なのに原価も見える、一般利用者なのにCSV一括出力できる、承認者でなくてもステータスを書き換えられる という事故が起きやすいです。

そのため、最低でも RBAC に近い形で、役割ごとに見えるもの・更新できるものを分けた方がよいです。
実務では、閲覧だけ / 登録更新 / 承認 / 設定変更 / 権限管理 くらいに分けるだけでもかなり違います。

ネットワーク的な分離も必要

アプリ側の認証だけで完結するとは限りません。
社内の業務システムなら、少なくとも次の分離は見たいです。

• 利用者向け画面と管理画面を分ける
• 業務端末と管理端末をできれば分ける
• サーバー、DB、バックアップ保管先の経路を必要最小限にする
• VLAN、ACL、ファイアウォール で通信を絞る

ネットワーク側の前提から整理したいなら、社内ネットワークの記事 の方が土台として分かりやすいです。
在宅勤務や外部委託先が触るなら、VPNの記事 の運用面も一緒に見ておいた方が安全です。

アプリ実装でも最低限の守りを入れる

社内向けだからといって、入力値検証、認可チェック、セッション管理、パスワードハッシュ化、シークレット管理を後回しにすると、結局あとで苦しくなります。
実務では、次のあたりは最初から入れておく方が結果的に安いです。

NIST SP 800-218 も、脆弱性を減らすには運用だけでなく開発ライフサイクルへ安全策を組み込む必要がある、という考え方です。
つまり、本番公開前にファイアウォールで囲えばOK ではなく、作る段階からセキュリティを入れた方が結局事故が減ります。

ログ、監視、バックアップは「あとで」だとほぼ遅れる

業務システムで本当に困るのは、事故が起きたあとに追えないことです。
最低限でも、次は見られるようにしておきたいです。

• 誰がいつログインしたか
• 権限変更、承認、削除、一括更新の実行者
• 失敗ログインや権限不足エラー
• 管理画面アクセス
• データ修正の履歴

さらに、バックアップは 取っている だけでは足りません。
復元できるか、どこまで戻るか、止まったときに誰が判断するかまで含めて運用しないと、実務ではかなり危ないです。

管理者端末も前提にする

社内システムは、システム自体より管理者の端末や資格情報から崩れることがあります。
そのため、重要システムを触る管理者端末には、少なくともOS更新、ディスク暗号化、端末管理、必要に応じて EDR を前提にした方が安全です。

ここを軽く見ると、アプリ側で頑張っても運用端末から突破されます。
社内向けシステムほど「利用者の画面」より「管理者の運用経路」の方が影響が大きいことはかなり多いです。

小規模チームなら、現実的にはどこまでやるべきか

小規模チームでも、次の順で整えると現実的です。

1. ログイン画面と管理画面を分ける
2. 管理者には MFA を入れる
3. 権限を役割ごとに分ける。まずは RBAC の簡易版でもよい
4. 重要操作の監査ログを残す
5. バックアップと復元手順を用意する
6. パッチ適用とライブラリ更新の担当を決める
7. 余裕があれば SSO、管理経路分離、端末管理まで進める

逆に、小規模だからという理由で パスワード単独 / 共通アカウント / 権限全部入り / ログなし で始めると、あとで直すコストがかなり高くなります。
最初から完璧は不要ですが、後から直しにくいところだけは先に決めた方が楽です。

よくある失敗

ほかにも、次のような失敗はかなり多いです。

• 共有アカウントで運用して、誰が操作したか追えない
• 一般利用者と管理者が同じ入口でログインする
• 権限が 管理者 / 一般 の2段階しかなく、結局ほぼ全員が強い権限を持つ
• バックアップはあるが、復元手順が誰も分からない
• 社内向け を理由にライブラリ更新や脆弱性対応が止まる
• VPN や Zero Trust の入口を整えても、接続後のシステム権限が雑なまま

まとめ

社内の業務システムを構築するときに大事なのは、大企業並みの全部入り対策を最初からやること ではありません。
本当に大事なのは、最低限外せないところを後回しにしないこと です。

少なくとも、認証、権限制御、ログ、パッチ対応、バックアップ、管理経路の分離は、社内向けでもかなり重要です。
そのうえで、公開範囲、扱うデータ、停止影響、権限の強さに応じて、SSO、MFA、RBAC、ネットワーク分離、端末管理まで広げていくのが現実的です。

もし迷ったら、止まると困るか と 見られると困るか で考えると判断しやすいです。
この2つが重いなら、社内向けでも「最低限でいい」とは言いにくいです。

参考情報

• CISA: Secure by Design
• CISA: Secure-by-Design: Shifting the Balance of Cybersecurity Risk
• CISA: Cross-Sector Cybersecurity Performance Goals
• NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
• OWASP: Application Security Verification Standard (ASVS)