社内向けアプリは「社員しか使わないから安全」と見なされがちです。しかし実際の事故の多くは内側から始まります。漏れたパスワードひとつ、推測できるURLひとつ、権限確認のない添付ファイルのダウンロードひとつ。以下は、企業向けWebアプリを本番環境へ出す前に確認すべき十項目です。

1. サーバー側で既定は拒否

すべてのエンドポイントに明示的な権限を必須とします。権限属性を付け忘れた新しいエンドポイントは、全員が使えるのではなく、遮断されるのが正しい状態です。権限のないアカウントで全エンドポイントを呼び、すべて拒否されることを確認してください。

2. レコード単位で権限を確認する

画面単位の遮断では不十分です。識別子を伴う要求ごとに、呼び出した人がそのレコードを見てよいかをサーバーが確認します。企業向けアプリで最も多い穴がここです。URLの数字をひとつ変えるだけで、他部署の書類が読めてしまいます。

3. セッションとトークン

• アクセストークンは短命にし、更新の仕組みを設ける。退職時に失効できること。
• ログアウトはブラウザ側を消すだけでなく、サーバー側で無効化する。
• ログイン失敗をアカウント単位と接続元単位で制限し、総当たりを防ぐ。
• 高権限のアカウントには二要素認証を有効にする。

4. 入力データの扱い

検証は必ずサーバー側で行います。ブラウザ側の検証は使い勝手のためのもので、安全性の根拠にはなりません。データベースへの問い合わせは文字列連結ではなくパラメータを使います。画面に再表示される利用者入力は、禁止タグの一覧ではなく、許可タグの一覧に基づいて無害化します。

5. アップロードされるファイル

• 形式は先頭バイトで判定する。拡張子を信用しない。
• 容量と件数を制限する。
• 公開ディレクトリの外に保存し、利用者が付けた名前ではなく生成した識別子で命名する。
• ダウンロード時も他のデータと同様に権限を確認する。パスが推測できてはいけません。

6. 設定値の秘密情報

接続文字列、署名鍵、サービスのパスワードは、ソースコードにもリポジトリへ上げる設定ファイルにも置きません。環境変数か専用の保管庫を使い、定期的に鍵を入れ替えます。公開リポジトリへ鍵を一度でも上げてしまえば、すべて入れ替える事態になります。

7. 記録は適切な粒度で

記録は何が起きたか再構成できる量が必要ですが、それ自体が情報漏えいの経路になってはいけません。

• 記録する：誰が、何を、いつ、どのレコードに対して、成功したか拒否されたか。
• 記録しない：パスワード、トークン、カード番号、機微な本文。
• 特に権限拒否は記録する。拒否が不自然に連続するのは事故の早期兆候です。

8. 情報を漏らさない誤り表示

利用者へ返すエラーメッセージは短く中立に。スタックトレース、テーブル名、問い合わせ文はサーバーの記録にとどめます。フレームワーク既定のエラー画面は本番で無効にしてください。

9. 通信と防御用ヘッダー

• HTTPSを必須にし、全通信をリダイレクトし、HSTSを有効にする。
• コンテンツセキュリティポリシーで外部スクリプトを制限する。
• CORSは具体的なドメイン一覧で設定する。認証のあるアプリでワイルドカードは使わない。
• ログイン、パスワード再発行、公開フォーム送信など、機微な入口には流量制限をかける。

10. バックアップと復旧訓練

一度も復元していないバックアップは、まだバックアップではありません。少なくとも一度、別の機材でバックアップから全体を復元し、所要時間を計ってください。その数字が自社の実際の復旧時間です。

定期的に行うこと

• ライブラリと基盤を更新する。悪用される脆弱性の多くは、すでに修正版が出ているものです。
• アカウント一覧を棚卸しする。特に退職者とサービス用アカウント。
• 管理者グループの構成員を四半期ごとに確認する。
• 事故の想定訓練を一度行う。誰が気づき、誰に伝え、どうやってシステムを封じるか。

セキュリティは一度やれば終わる作業ではなく、小さな習慣を続けることです。上の十項目はどれも高価な道具を必要としません。必要なのは、コードを書くときと運用するときの規律です。