Webサービスのセキュリティ対策では、使っているものを把握し、更新し、権限を減らし、異常を調べられる状態を維持することが土台になります。大きな脆弱性が公表された日だけ対応しても、古いライブラリや退職者のアカウントが残れば、別の入口が開いたままです。
wrenでも、自社サービスを運営する事業者として、ライブラリのバージョン管理と技術的な防御を日々の運用に組み込んでいます。本記事では一般的な確認項目と、自社サイトで実施している具体例を紹介します。（確認時点：2026年10月22日）
公開システムと管理者を把握する
最初に、Webアプリ、管理画面、API、ストレージ、検証環境を洗い出します。制作会社が管理するキャンペーンサイトや、以前の実証実験で作った環境も対象です。サービスごとに管理者、利用目的、扱うデータ、公開範囲、更新担当を記録します。
台帳は、クラウドの資産情報やリポジトリ、ID管理の情報と結び付け、変更に追従できる場所で管理します。管理者不明の環境は、止めてよいか判断することすら難しくなります。
優先順位は、インターネットから到達できるか、悪用が確認されているか、顧客データや管理権限に届くかで決めます。CISAのKEVカタログは、実際の悪用が確認された脆弱性を調べる材料です。未掲載だから安全とは判断できません。
ライブラリの更新を本番反映まで管理する
本文で扱う技術の例です。ロゴは各技術の識別に使用し、公式サイトへリンクしています。提供元との提携・認定を示すものではありません。
package.jsonなどの宣言ファイルだけでは、実際に入っている依存関係を把握しきれません。lockfileと実行環境の情報を組み合わせ、間接依存も確認します。OSのパッケージ、PHP・Node.jsなどのランタイム、コンテナのベースイメージ、CIで実行する外部Actionも更新対象です。
GitHubのDependabot security updatesは、既知の脆弱性に対する更新PRの作成を補助します。ただし、通知やPRの有無だけでは管理対象全体の安全性は分かりません。提供元の告知、サポート期限、スキャン対象外の部品も確認します。
影響を確認
使っている環境と修正対象を照合
変更を検証
差分・主要機能・戻し方を確認
本番へ反映
再ビルド・再起動を含めて適用
稼働を確認
実行バージョンとエラーを確認
決済、ログイン、データ出力など、影響の大きい機能を検証します。脆弱な旧版へ戻す可能性がある場合は、ロールバック時の公開制限や代替策も用意します。単純に以前の状態へ戻せばよいとは限りません。
php2shellの対応記事でも、コマンドラインとWebで動くPHPの違いを扱っています。更新後の確認は、パッチの内容と確認ポイントも参照してください。
IAMは人・実行環境・CIを分けて絞る
IAMは、誰がどのリソースに何をできるかを管理する仕組みです。開発者の操作、アプリの実行、CIからのデプロイを同じ管理者権限で動かすと、一つの認証情報が漏れたときの影響が広がります。
AWSのIAMベストプラクティスは、一時的な認証情報、最小権限、未使用のユーザー・ロール・権限の定期的な削除を推奨しています。人にはSSOとMFAを、実行環境にはロールを使うなど、用途に応じて認証方法を選びます。
| 対象 | 見直す内容 | 確認すること |
|---|---|---|
| 人の権限 | 本番と検証、通常操作と緊急操作を分ける | 管理者権限の保有者と使用理由を説明できるか |
| アプリの権限 | 対象のバケット・DB・操作に絞る | 読むだけの処理に削除・権限変更が許されていないか |
| CIの権限 | デプロイ先と実行元を限定する | 長期キーを減らし、信頼するリポジトリやブランチを限定できるか |
| 外部委託先 | 担当範囲と有効期限を決める | 契約終了後に残る権限がないか |
利用履歴は絞り込みの材料ですが、実行頻度の低い復旧処理が記録期間に含まれない場合があります。担当者への確認と検証を挟み、必要な権限まで一括削除しないようにします。
退職・異動・契約終了をアクセス停止につなげる
退職者管理は、人事の連絡と技術側の操作がつながって初めて機能します。退職・異動・委託契約終了の予定から停止タスクを作り、担当者と実施時刻を決めます。記録に残すのは「依頼した」ではなく、各サービスで停止を確認した結果です。
- IdPのログインを停止し、既存セッションを失効させる
- SaaS固有のアカウント、APIキー、SSH鍵、個人のアクセストークンを確認する
- OAuth連携、メール転送、共有リンク、所属グループを見直す
- リポジトリ、ファイル、自動処理の所有者を引き継ぐ
- 必要なデータと監査ログを保全したうえで、保存ルールに沿って削除する
SSOの停止だけで、各SaaSが発行したセッションまで即座に失効するとは限りません。Microsoftのアクセス取り消しの説明も、アプリ側のセッションを別途扱う必要を示しています。Google Workspaceのセキュリティ設定では、ログインCookieやアプリへのアクセスなど、操作対象を確認できます。
使っていないSaaSと連携を整理する
SaaSの整理では、契約金額より先に、何のデータを渡し、どの権限を与えたかを確認します。無料トライアルや個人契約でも、顧客データを取り込んだり、メールやストレージを読めたりする場合があります。
管理台帳には、利用目的、社内の責任者、データの種類、SSO対応、連携権限、ログの取得範囲、契約終了時の手順を持たせます。IdPのアプリ一覧、請求情報、各部門への確認を突き合わせると、どれか一つでは見つからない利用も拾えます。
廃止するときは、必要なデータの移行、連携の停止、トークンの失効、サービス側のデータ削除、契約終了を確認します。解約ボタンを押しても、別サービス側に与えた権限が残ることがあります。
監査ログと復旧手順を用意する
アプリのエラー監視に加え、ログイン、権限変更、データ出力、共有設定の変更を調べられるようにします。ログ自体にもアクセス制御を掛け、パスワードやトークン、不要な個人情報を記録しない設計にします。記録項目の考え方はOWASPのLogging Cheat Sheetが参考になります。
バックアップは取得結果だけでなく、隔離した環境へ復元できるかを確認します。許容できる停止時間とデータ損失を業務側と決め、復旧担当、連絡先、判断者を手順に残します。
図版はNIST CSF 2.0の公式資料から、6機能図の再掲載条件に従って掲載しています。
図は作業を順に一度ずつ終えるチェックリストではありません。防御に加えて、異常に気づき、対応し、復旧できる状態を維持するための整理です。漏洩の疑いが生じた場合は、情報漏洩時の初動と原因の切り分けへ進んでください。
wrenが自社サイトで行っていること
wrenでは、受託開発に加え、ad-cre.aiやKokage.aiといった自社サービスを開発・運営しています。ライブラリのバージョン管理や技術的な防御は、自社の運用でも日々扱う仕事です。その一部として、このコーポレートサイトでは次を実施しています。
| 実施していること | 自社サイトでの具体例 |
|---|---|
| 依存関係を再現できるようにする | pnpm-lock.yamlを管理し、記事のCIでpnpm install --frozen-lockfileを実行。宣言ファイルとlockfileの不一致をインストール時に検出 |
| サーバー側で入力を検証する | 問い合わせAPIで入力形式を検証し、不適切な入力を受け付けない。確認メールへ埋め込む自由入力値はHTMLエスケープ |
| ブラウザの動作を制限する | X-Content-Type-Options: nosniffやX-Frame-Options: SAMEORIGINなどを設定。公開サイトのレスポンスでも反映を確認 |
これらの設定があることと、サービス全体に脆弱性がないことは別です。たとえばlockfileは依存関係を再現するためのもので、脆弱性を自動的に解消するものではありません。バージョンを把握する作業と、更新が必要か判断する作業の両方が要ります。
この表は当社コーポレートサイトで確認した範囲です。各プロダクトの構成や検証結果を、同じものとして一括で扱ってはいません。
担当と完了条件を決めて運用にする
「定期的に確認する」だけでは、対応が止まった理由を追えません。更新、権限、退職者、SaaS、監査ログごとに、担当者と期限、完了条件をタスクとして残します。例外を認める場合も、理由、一時対策、再確認日を決めます。
社内に判断や実行を担う人が足りない場合は、SRE顧問に依頼できることを参考に、任せたい範囲を整理してください。wrenの受託開発・SRE顧問の対応領域では、インフラの構成管理やデプロイ、監視・障害対応の手順づくりを紹介しています。SRE顧問の相談フォームに対象のシステムと現在の課題を記載いただければ、関わり方の案をメールでお返しします。