スイスチーズモデルで考えるワークフローシステムの防御構造
認証からインフラまで、穴が空いても“次で守る”
セキュリティにおいて「この対策をすれば絶対安全」というものは存在しません。だからこそ、「いくつかの対策を重ねることで、たとえ1つが突破されても被害を最小限に抑える」──これがスイスチーズモデルの基本的な考え方です。
ここでは、ワークフローシステムにおける7つの防御レイヤーのうち、前半の4つについて順に見ていきましょう。
レイヤー①：認証・認可（ログインや操作の“入り口”）
何が狙われる？
ログイン情報（ID・パスワード）を盗み取られて、なりすましで社内の承認フローに侵入されるケースです。
たとえば、退職者のアカウントが有効なままだったり、弱いパスワードが使われていたりすると、外部から不正ログインされる可能性があります。
どんな対策が必要？
- 2段階認証（MFA）：ログイン時にパスワードだけでなく、スマホ認証やワンタイムコードを要求
- SSO（シングルサインオン）連携：会社全体のID管理と統合し、無効化や権限管理を集中制御
- ロールごとの操作制限：一般社員／部長／管理者でできる操作を分ける
- アカウントの定期棚卸し：使われていないIDを無効化するルールを設ける
レイヤー②：エンドポイント（パソコン・スマホなど使用端末）
何が狙われる？
出張先や外出中に使用したノートPCやスマートフォンが盗難・紛失した場合、そこから社内システムへの不正アクセスが発生するリスクがあります。
どんな対策が必要？
- 社外端末でのアクセス制限（BYOD対策）：私物端末からのアクセスを制限、またはMAM（モバイルアプリ管理）で制御
- スマホアプリにロック・パスコードを設定：ログイン後も再認証を求める仕組み
- 端末認証の導入：事前に登録されたPC／スマホ以外からのアクセスはブロック
レイヤー③：ネットワーク（通信経路の安全性）
何が狙われる？
公共のWi-Fiを使った通信の盗聴や、URLを偽装して情報を盗む中間者攻撃など、「データが移動している最中」が狙われるポイントです。
どんな対策が必要？
- TLS／SSLによる通信の暗号化：すべての画面遷移・申請内容が暗号化されているか？
- IPアドレス制限：指定した拠点・ネットワークからしかアクセスできないよう制御
- GeoIPブロック：海外IPからのアクセスを原則拒否する設定
レイヤー④：インフラ（サーバー・クラウド基盤の安全性）
何が狙われる？
クラウド上で動いているワークフローシステムそのものに対して、次のようなリスクが存在します。
- アプリケーションの脆弱性を突いた攻撃（XSSやSQLインジェクションなど）
- 設定ミスにより誰でもアクセスできてしまう状況（クラウド誤設定）
どんな対策が必要？
- WAF（Web Application Firewall）を導入しているか？
- 脆弱性スキャンや定期的なペネトレーションテストが行われているか？
- サーバーログを24時間体制で監視しているか？
- 障害時の切り替え（冗長化）やバックアップ体制が整っているか？
レイヤー⑤：アプリケーション（ワークフローシステムそのもの）
何が狙われる？
システムの設計ミスや更新遅れにより、悪意ある第三者に操作されてしまうこと。たとえば、
- 承認済みの書類が後から編集可能になっている
- ファイルのアップロード／ダウンロードが自由で、改ざんされる
- 過去の稟議が誰でも見られる設定になっている
このような“内部構造の甘さ”が、重大な情報漏えい・意思決定の破壊につながります。
どんな対策が必要？
- 承認後の文書はロック（編集不可）にする
- 改ざんされた場合は履歴から変更前の状態に戻せる
- ファイルのアップロード制限／閲覧権限を役職単位で管理
- 利用しているシステムが定期的にセキュリティアップデートされているか確認
「使いやすい」だけでなく、「勝手に使えない」ことも、ワークフローには必要です。
レイヤー⑥：データベース（情報の保管場所）
何が狙われる？
仮にシステム内部まで侵入された場合、最終的に狙われるのは顧客情報・社内申請データ・過去の稟議・添付された証憑ファイルなどが保管されているデータベースです。
どんな対策が必要？
- データの暗号化：保存時も移動時も情報が読めないようにする
- 顧客ごとの論理分離：他社に影響が及ばないように区切る
- アクセス権の分離：開発者でも直接データベースを見られない
- 定期的なバックアップと異常検知：壊れてもすぐ復元、異常があれば即通知
万が一攻撃が成功しても、「影響を最小限に抑える」設計が、制度の信頼性を守ります。
レイヤー⑦：運用管理（人の操作ミス・設定ミス・放置）
何が狙われる？
最も抜けやすいのが「人」のレイヤーです。たとえば
- 退職者のIDが残ったまま
- 管理者が広すぎる権限を持っており、誤操作で書類を削除
- 管理設定を誰でも変更できてしまう
攻撃者が「外」ではなく「中」にいると仮定したとき、人的な管理・設定の甘さが最大の脆弱性になります。
どんな対策が必要？
- 設定変更は管理者と監査者で分離
- すべての操作にログを残し、定期的に見直す
- 削除・変更は「申請→承認→実行」のプロセス制御
- 定期的な棚卸し・権限レビューのルール化
セキュリティの最後の壁は「運用そのもの」。“仕組みで守る”体制を制度として整えることがカギです。
スイスチーズは「穴だらけ」で構わない──重なっていれば。
セキュリティ対策は「1つで完璧に防ぐ」のではなく、いくつもの防御を重ねて、“どれかが突破されても次で止める”という考え方が重要です。
スイスチーズモデルでは、次のように表現できます。
| レイヤー（防御の壁） | 例えるなら… |
| 認証・認可 | 正面玄関のカギ＋顔認証 |
| エンドポイント | ドアの近くの警報センサー |
| ネットワーク | 建物の外壁・フェンス |
| インフラ | サーバー室の金庫扉 |
| アプリケーション | 書類が保管されたキャビネットのロック |
| データベース | 書類そのものにかけられた暗号 |
| 運用管理 | 鍵を管理する人の行動記録と指差し確認 |
万が一“突破された”ときに備える3つの視点
～完璧はない。だから「被害を小さく抑える」「早く気づく」仕組みが必要～
これまで見てきたように、ワークフローシステムには多層的なセキュリティ対策が求められますが、それでも「100%の防御」は存在しません。近年のサイバー攻撃では、世界的に有名なIT企業や官公庁ですら侵入を許してしまっています。
だからこそ今、「攻撃が成功してしまうかもしれない」という前提に立った対策が必要です。
このセクションでは、「侵入されてしまったときに、どれだけ被害を抑えられるか」「どれだけ早く異常に気づけるか」「どう説明できるか」という3つの視点を解説します。
視点①：被害を局所化できるか？
～「1社や1部署の情報」で食い止められる設計か～
仮にワークフローシステムに不正アクセスが発生した場合、次のような被害が想定されます。
- 稟議書・契約書などのダウンロード
- 登録されている社員情報の閲覧
- 他の顧客・部署の情報への“横展開”
しかし、適切な「分離設計」がなされていれば、被害を最小限に抑えることが可能です。
確認すべきポイント
- 顧客ごとにデータベースが「物理的または論理的に分離」されているか？
- テナント（会社）間の情報が混在しない構造になっているか？
- 社員Aが起票した文書を、社員Bが勝手に検索できないようになっているか？
セキュリティは「広げない」ことが最善のダメージコントロールです。
視点②：異常にすばやく気づけるか？
～「静かに盗まれていた」は最も怖いシナリオ～
多くのセキュリティ事故では、「攻撃自体は数週間〜数か月前に始まっていた」「ずっと内部に潜伏していた」という事例が目立ちます。つまり、気づけなかったこと自体が“最大の被害”なのです。
確認すべきポイント
- 不審なログインや大量のアクセスがあった場合、自動的にアラートが出るか？
- アクセスログや操作ログは常時取得され、分析・通知に使われているか？
- 管理者が異常に気づく手段（ダッシュボードや週次レポート）はあるか？
「気づけない仕組み」は、守れていないのと同じです。
どんなに鍵を厳重に管理しても、「セコム」「ALSOK」のような侵入者検知の仕組みが必要です。
視点③：何が起きたかを“後から説明できるか”
～原因の特定・影響範囲の判断・再発防止の出発点～
セキュリティ事故が発生した際、社内外に対して「説明責任」を果たす必要があります。
そのときに重要になるのが、証跡（ログ）と記録の正確性です。
確認すべきポイント
- 「誰が、いつ、何をしたか」のログが残っているか？
- 記録は保管され、後から検索・出力できるか？
- 書類の変更履歴・削除履歴なども把握できるか？
「何が起きたか分からない」は、リスクをコントロールできていないということです。
小さな仕組みの積み重ねが、大きな被害を防ぐ
これら3つの視点（局所化・早期発見・説明可能性）は、セキュリティ上の“最後の守り”です。
完璧な防御ではなく、「抜かれても、すぐ気づいて、すぐ止められる」
そんな柔軟性のある制度こそが、今の時代に求められるセキュリティ設計です。
「この製品は安全です」と言われたときに、確認すべきポイント
ワークフローシステムを選ぶ際、ベンダーや営業担当者からこう言われることは珍しくありません。
「うちはクラウドだから安全です」
「通信は暗号化されているので大丈夫です」
「ISO認証も取ってますよ」
たしかにこれらは、最低限のセキュリティ対策として重要な要素です。しかし、それだけで“安全”かどうかを判断するのは危険です。
このセクションでは、ITに詳しくなくても理解できるように、「本当に安全なワークフロー製品かどうか」を見極めるための“具体的な質問ポイント”を整理していきます。
1. 暗号化されているのは、どこまでか？
聞くべき質問
- 通信だけでなく、保存されているデータ（申請内容・添付ファイル）も暗号化されていますか？
解説： 通信中だけでなく、データベース内で保存されている情報が暗号化されていなければ、侵入されたときに中身が丸見えになってしまいます。
2. 顧客ごとにデータは分離されているか？
聞くべき質問
- 他社とデータベースが共有されていませんか？
- 顧客ごとの情報が完全に区切られていますか？
解説： マルチテナント型（複数社が同じシステムで動く形式）の場合、顧客ごとに論理的にしっかりとデータが分けられていなければ、他社の攻撃が自社に飛び火する危険があります。
3. 承認後の書類は編集できないようになっているか？
聞くべき質問
- 承認された稟議書や契約書は、その後に変更・削除できない仕様ですか？
解説： 過去の記録が後からこっそり書き換えられるシステムでは、ガバナンスや監査に耐えられません。ロック機能や改ざん防止設計があるかどうかは非常に重要です。
4. 操作ログはどこまで残るか？誰がいつ何をしたか追えるか？
聞くべき質問
- 承認・変更・閲覧・削除など、すべての操作がログに残りますか？
- 管理者の操作も監視・記録できますか？
解説： ログが不十分なシステムでは、万が一の際に「誰が何をしたのか分からない」状態になってしまいます。「誰の操作まで記録対象か」まで含めて確認しましょう。
5. アカウント管理の仕組みは整っているか？
聞くべき質問
- 退職者や異動者のアカウントは自動で停止・制限されますか？
- 部門異動時に承認権限が見直される仕組みはありますか？
解説： 「アクセスしてはいけない人が、知らないうちにアクセスできていた」というのは最も典型的で危険なパターンです。アカウントの管理が“制度化”されているかが重要です。
6. サイバー攻撃を早期に検知する仕組みはあるか？
聞くべき質問
- 異常なアクセスや連続ログイン失敗などにアラートは出ますか？
- 管理者に通知が届く仕組みはありますか？
解説： 攻撃を「防げなかった」としても、「気づけなかった」ことは大きな問題です。早期検知と可視化があるかどうかは、必ず聞くべき項目です。
7. セキュリティ機能は“オプション”でなく“標準”か？
聞くべき質問
- MFA、ログ取得、IP制限などの機能はすべて標準搭載ですか？
- 追加料金や有料プランを選ばないとセキュリティが弱くなりませんか？
解説： セキュリティがオプションになっている場合、「費用の都合で使わない」という選択肢が現場に発生してしまいます。セキュリティは“選べる機能”ではなく“最初から守られている設計”であるべきです。
まとめ：安心できる「言葉」より、“制度として守れているか”を確認しよう
「うちは安全です」「通信は暗号化されています」
という“営業トーク”をそのまま受け入れてはいけません。
大切なのは、どこが、どのように、どうやって守られているかを一つずつ確かめることです。
セキュリティとは「安心感」ではなく、「制度に裏付けられた構造」で守るもの。
それを見極める目を、この記事でぜひ身につけてください。
ジュガールワークフローが備える「抜けても止める」仕組み
～スイスチーズモデルを体現した“制度設計としてのセキュリティ”～
これまで解説してきた「スイスチーズモデル」による多層防御と、「突破されることを前提とした備え」。
ジュガールワークフローでは、これらの考え方を前提としたセキュリティ設計がシステム全体に組み込まれています。
この章では、ジュガールがどのような“仕組み”で「抜けても止める」セキュリティを実現しているのかを、レイヤーごとに具体的にご紹介します。
レイヤー① 認証・認可（ID・ログインまわり）
- 2段階認証（MFA）を標準装備（メール・アプリ連携）
- SSO（シングルサインオン）により、社内IDと統合可能
- ロールベースの操作権限設定（閲覧・承認・管理の分離）
- 管理者ID・業務IDの分離によるリスク低減
レイヤー② エンドポイント（PC・スマホの利用環境）
- モバイル専用画面の簡易UIとセッション自動切断設定
- スマートフォンやタブレットでも、ログイン／操作権限は制限付き
- 管理画面へのアクセスはPC限定／IP制限設定あり
レイヤー③ ネットワーク（通信経路）
- 通信はすべてTLS1.2以上で暗号化（外部とのAPI通信も含む）
- IPアドレス制限による拠点外アクセスの制御
- GeoIP制限（国外アクセス遮断）にも対応（実装予定）
レイヤー④ インフラ（クラウド基盤）
- Web Application Firewall（WAF）で攻撃検知・遮断
- オートスケーリング・冗長構成により高可用性を確保
- 24時間365日体制のサーバー監視とアラート発報
レイヤー⑤ アプリケーション（ワークフローの挙動）
- 承認完了後の書類は自動ロック（編集・削除不可）
- 書類の変更履歴・操作履歴は自動で蓄積され、監査対応可能
- テンプレート改修時の影響範囲も事前にチェック表示
レイヤー⑥ データベース（記録・申請情報）
- 顧客ごとに論理的に分離されたデータベース構造（他社とは隔離）
- データは保存時・バックアップ時ともに暗号化（AES256相当）
- 管理者であっても、アプリ外から直接アクセスできない設計
レイヤー⑦ 運用管理（設定・操作・運用プロセス）
- 重要操作は「申請→承認→実行」のステップ制を標準搭載（例：廃棄処理・ルート変更）
- 管理者操作・ログイン履歴はダッシュボードで常時可視化
- アカウント棚卸し・未使用IDの自動ロック機能
「安心」は、“実装された構造”として説明できるべき
ジュガールワークフローでは、
- セキュリティは「ユーザー任せ」にしない
- 「守る仕組み」が、製品そのものに組み込まれている
という方針のもと、開発・設計・運用のすべてが制度設計に基づいて構築されています。
安心して使えるシステムとは、単に「暗号化されています」「認証があります」という説明だけではなく、「仮に抜けても、ここで止まる仕組みがある」と構造的に語れるものです。
まとめ：専門家でなくても、“守れる製品”を選べる
～セキュリティの判断は「機能」より「構造」を見ればいい～
これまで本章では、ワークフローシステムに必要なセキュリティ対策について、専門的な用語をできるだけ使わず、スイスチーズモデルという考え方を通じてわかりやすく整理してきました。
結論として、セキュリティとは「何かひとつで守る」ものではなく、「すり抜けても、次で止める仕組みをいくつ重ねているか」が本質です。
セキュリティは「構造」で守る
～わからなくても、仕組みで守れる製品はある～
セキュリティの専門知識がなくても、次のような視点を持つことで、製品選定の失敗は防げます。
| 質問の視点 | 見るべきこと |
| 認証 | ID・パスワードだけでなく、2段階認証があるか？ |
| 通信 | 通信が暗号化されているか（TLSなど） |
| データ保存 | 顧客ごとにデータが分かれているか？暗号化されているか？ |
| 承認後 | 書類が編集・削除できないようになっているか？ |
| 操作履歴 | 誰が、いつ、何をしたかがログで追えるか？ |
| 検知 | 異常があったときに、すぐに気づける仕組みがあるか？ |
これらは、「難しい技術」ではなく、「制度的な仕組み」として備わっているかどうかを確認すればよいのです。
完璧は求めない。だけど「守れる構造」は必須
セキュリティで最も大切なのは、「リスクを0にすること」ではありません。
それよりも重要なのは、
- 「守れていなかったことに気づけなかった」
- 「なぜ漏えいしたのか説明できない」
- 「他社の攻撃で、自社の情報まで流出した」
といった事態を避ける“設計そのもの”です。
スイスチーズモデルが示すように、どの対策にも穴はあります。
だからこそ、穴が空いていても大丈夫な“重なり”をどう作るかが、製品の価値を分けるのです。
ジュガールで実現できる、“守れる制度設計”
ジュガールワークフローは、次のような安心構造をあらかじめ備えています。
- 認証・通信・記録・保存・運用管理のすべてに「制度的なセキュリティ」
- 顧客ごとのデータ分離と、アクセス制御の細やかな設計
- 攻撃を「防ぐ」だけでなく、「見つけて止める」仕組み
- ログ・履歴・権限のすべてが「あとから説明できる」証拠力
安心は、言葉ではなく“構造”で提供されるもの。
ITに詳しくない方でも、制度に沿って安全に運用できる仕組みが、ジュガールの強みです。
