当社ではGenbaFlow という中小製造業向けの作業日報電子化SaaSの開発・運用を行っています。GenbaFlowでは製造現場の日報や作業記録、それに紐づく個人情報を扱っています。こういうSaaSを運営していると、「何か問題が起きてから考える」では遅いんですよね。とはいえ、1人で開発も運用もセキュリティ対応も回していると、重たい運用は続きません。
前回投稿したfail2banを使った取り組みだけでは、SaaSにおけるセキュリティ要件を満たせるわけではないと考え、GenbaFlowでは、ISO/IEC 27005をベースにしつつ、リスク管理そのものをできるだけ自動化するやり方を取っています。認証取得のための立派な仕組みというより、限られたリソースでも現実的に回り続ける仕組みを作ることを優先しました。
なぜISO 27005ベースにしたのか
まず前置きしておきますが、ISO 27005の認証取得を目標にしている訳ではありません。ですので、取得の仕方はこの記事では全く触れていないので悪しからず。
ただ、こんな感じで仕組みを作って運用してから認証取得をした方が、定着しやすいのかな？と考えます。ISO関係は「認証取得」を目的として取り組むと大体がその場限りになって監査報告でワタワタするというのが、経験上の感想です。
何をするにも、まず実践！
さて、SaaSに限らず業務系システムを開発・運用していくと、情報セキュリティリスクをどう特定して、どう評価して、どう対応して、どう見直していくかという課題に必ず直面します。そういった課題に対して、ISO 27005の仕組みは、「流れ」を定義しやすいのです。
GenbaFlowみたいなマルチテナントSaaSだと、特に次の3点を曖昧にしたくありませんでした。
- どの情報資産を守るのか
- 何をリスクとして見ているのか
- そのリスクを受け入れるのか、対策するのか
このあたりが文書として残っていないと、将来の見直しもしにくいですし、お客様に説明するときも属人的になります。そこで、まずはコンテキスト、資産目録、評価基準、リスク台帳、コントロール台帳を分けて整理し、判断の前提を明文化しました。
自動化しているポイント
ポイントは、AIが変化を見つけて下準備をし、人間が最終判断だけに集中する形にしたことです。
GenbaFlowのセキュリティアセスメントでは、次のような構成で運用しています。
-
ISO27005_context.mdでスコープ、ステークホルダー、法令要件を定義 -
ISO27005_asset_inventory.mdで保護対象の資産を整理 -
ISO27005_risk_criteria.mdでスコアリングと受容基準を定義 -
ISO27005_risk_register.mdで具体的なリスクを管理 -
ISO27005_plan.mdでA.8系コントロールの実装状況を管理 -
.claude/agents/risk-assessor.mdで自動評価のエージェントを定義
以下に、ワークフローを図示したものについて説明します。
① コード変更・push
開発者がmasterブランチへコードをpushする。これがフロー全体のトリガー。
② GitHub Actions 起動
pushを検知してGitHub Actionsのワークフローが動き出す。各ジョブが順番またはパラレルで実行される。
③ 脆弱性スキャン実行
pip-audit（Pythonパッケージ）とTrivy（コンテナ・依存関係）がスキャンを実行し、検出結果のレポートを生成する。
④ Claude（risk-assessor）による分析
スキャン結果を.claude/agents/risk-assessor.mdで定義したClaudeエージェントに渡す。既存のリスク台帳と照合し、影響するリスクエントリの特定と更新案のドラフトを作成する。
⑤ GitHub Issue 起票（変化があるときのみ）
分析の結果、リスク台帳の見直しが必要と判断した場合だけGitHub Issueを起票する。変化がなければこのステップはスキップされる。
⑥ 人間レビュー → リスク台帳更新
担当者がIssueを確認し、「リスクレベルを変えるか」「受容か低減か」などの最終判断を下す。判断結果をISO27005_risk_register.mdに反映してループが閉じる。次のpushで①に戻る。
ここで大事なのは、変化がないときは何も出さないことです。毎回何か通知が飛ぶ仕組みにすると、すぐに見なくなるからです。ノイズを抑えつつ、本当に見直しが必要なときだけ担当者が確認する運用にしています。
人間が残している判断領域
この運用は「AIに全部任せる」ものではありません。むしろ逆で、AIに任せる範囲をかなり絞っています。
Claudeが担当するのは、脆弱性スキャンやコントロール状況から見て「どこに変化があったか」「どのリスクエントリに影響しそうか」を整理するところまでです。たとえば、既存エントリのbefore/after提案や、新しいリスク候補のドラフトまでは出します。
一方で、次の判断は人間が持ちます。
- リスクレベルを本当に変えるか
- 追加の対策コストに見合うか
- 受容でよいか、低減すべきか
-
acceptedにする理由をどう残すか
1人運営のSaaSでは、全部を完璧に塞ぐのは無理があります。だからこそ、「対応する」「受容する」「外部に移転する」をちゃんと分けて、その理由を残すことを重視しています。
実際に得られた成果
この仕組みを整えた結果、GenbaFlowではセキュリティ対応をかなり具体的な単位で回せるようになりました。
まず、技術コントロールではA.8系34項目のうち18項目、53%を実装済みという状態まで整理できました。単に「いろいろ対策している」ではなく、どこまで実装できていて、何が未着手なのかを見える化できたのは大きいです。
リスク台帳側では、13件のリスクエントリを定義して継続管理しています。内容としては、テナント間の横断アクセス、バックアップ復旧失敗、依存パッケージのCVE、秘密鍵漏えい、管理画面からのPII参照、ログへのPII混入など、GenbaFlowの構成に直結するものを中心に整理しました。
さらに、対応方針もかなり現実的に切り分けられるようになりました。
- 11件は
mitigateとして低減策を継続 - 1件は
transferとして外部サービスに依存 - 1件はコスト対効果を踏まえて
accept
特に象徴的なのは、可用性に関する単一ホスト構成のリスクを「見て見ぬふり」ではなく、受容理由込みで明示できる状態にしたことです。小規模SaaSでは、この整理がないと毎回同じ議論を繰り返しがちです。
運用負荷の面でも効果がありました。pushごとのイベント駆動レビューでは、Issueが上がったときに担当者が確認する時間はおよそ30分に収まる想定です。年次レビューも、AIが全件のスキャンと更新案の下準備をすることで、全体で4〜5時間程度の現実的な作業に落とし込めています。
どんな対策が回るようになったか
自動化の成果は、単なる台帳整備だけではありません。実装済みコントロールとのつながりが見えるので、改善の優先順位もつけやすくなりました。
たとえばこんな対策は、リスクとひも付いた状態で運用できます。
-
tenant_idフィルタによるテナント分離 -
pg_dumpと自動リストアテストによるバックアップ検証 - ログイン試行制限、
fail2ban、MFAによるアカウント保護 -
pip-audit、Trivy、Dependabotによる既知脆弱性の監視 - ログのホワイトリスト制御やマスキングによるPII漏えい対策
こうしておくと、セキュリティ対策が「思いついたら足すもの」ではなく、「どのリスクを下げるための実装か」が分かる状態になります。これは保守のしやすさにも効いてきます。
まとめ
GenbaFlowでやっているのは、華やかな自律セキュリティではありません。むしろ、1人でも継続できるように、リスク管理の定型部分を機械に寄せたという話です。
ISO 27005ベースで前提を文書化し、GitHub ActionsとClaudeを使って差分検出と更新提案を自動化する。そうすることで、担当者は「通知を眺める人」ではなく、「本当に判断が必要なところだけを決める人」になれます。
小規模なSaaSほど、セキュリティ運用は気合いでは続きません。だからこそ、GenbaFlowではこれからも、守るべきところを明確にしながら、自動化できる部分は着実に機械へ寄せていくつもりです。