GenbaFlowのセキュリティアセスメントをどう自動化しているか

GenbaFlow では、製造現場の日報や作業記録、それに紐づく個人情報を扱っています。こういう SaaS を運営していると、「何か問題が起きてから考える」では遅いんですよね。とはいえ、1人で開発も運用もセキュリティ対応も回していると、重たい運用は続きません。

そこで GenbaFlow では、ISO/IEC 27005 をベースにしつつ、リスク管理そのものをできるだけ自動化するやり方を取っています。認証取得のための立派な仕組みというより、限られたリソースでも現実的に回り続ける仕組みを作ることを優先しました。

なぜ ISO 27005 ベースにしたのか

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 で自動評価のエージェントを定義

image2: GenbaFlowの自動リスクアセスメントフロー

image2. master への push を起点に、GitHub Actions、脆弱性スキャン、Claude の risk-assessor、GitHub Issue、人間レビュー、リスク台帳更新までをつないだ全体フロー。変化があるときだけ Issue を起票し、最終判断は人間が行います。

この土台の上で、master ブランチへの push をきっかけに GitHub Actions を動かし、pip-audit や Trivy の結果を Claude ベースの risk-assessor に渡しています。

AI 側でやっているのは、ざっくり言うと次の3つです。

  1. スキャン結果と既存のリスク台帳を照合する
  2. コントロールの整合性や stale になっている記述を洗い出す
  3. 変更が必要そうなときだけ GitHub Issue のたたき台を出す

ここで大事なのは、変化がないときは何も出さないことです。毎回何か通知が飛ぶ仕組みにすると、すぐに見なくなるからです。ノイズを抑えつつ、本当に見直しが必要なときだけ担当者が確認する運用にしています。

人間が残している判断領域

この運用は「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 ではこれからも、守るべきところを明確にしながら、自動化できる部分は着実に機械へ寄せていくつもりです。

本記事は ISO27005_overview.md の内容をもとに、ブログ投稿向けに再構成したものです。