セキュリティ対策

1. はじめに

1.1 本文書の目的

本文書は、「脳活ラボ」のセキュリティ対策について技術的根拠とともに説明するものです。

複数の自治体が同一のシステム基盤を共同で利用するマルチテナント方式を採用しているため、データの分離・保護がどのように実現されているかを重点的に解説します。

1.2 対象システム

項目	内容
システム名	脳活ラボ
利用者	自治体職員（管理システム）、住民（LINE アプリ）
提供形態	クラウド型 SaaS

2. セキュリティアーキテクチャ概要

本システムは、多層防御（Defense in Depth） の原則に基づき、4つの独立したセキュリティレイヤーで構成されています。各レイヤーは独立して機能するため、1つのレイヤーが突破された場合でも、他のレイヤーが防御を維持します。

+---------------------------------------+
|  Layer 1: 認証 (Authentication)        |  誰であるかの確認
|  パスワード + TOTP 二要素認証            |
+---------------------------------------+
|  Layer 2: 認可 (Authorization)         |  何ができるかの制御
|  RBAC + 6種の操作権限                   |
+---------------------------------------+
|  Layer 3: データ分離 (Isolation)        |  どのデータに触れるかの制限
|  自治体 ID・部署 ID によるスコープ制御     |
+---------------------------------------+
|  Layer 4: 監査 (Audit)                 |  誰が何をしたかの記録
|  操作ログ・画面ログ・印刷/出力ログ         |
+---------------------------------------+

3. 認証機能

3.1 パスワード認証

職員のパスワードは、以下の方式で安全に管理されています。

項目	仕様
ハッシュアルゴリズム	SHA-256
ソルト	16バイトのランダム値（ログインごとに一意）
保存形式	`{ソルト}:{ハッシュ値}`
平文保存	不可（ハッシュ化後のみ保存）

パスワードは不可逆なハッシュ関数で変換されてから保存されるため、万が一データベースが漏洩した場合でも、元のパスワードを復元することはできません。

3.2 二要素認証（TOTP）

パスワード認証に加え、時間ベースワンタイムパスワード（TOTP）による二要素認証を提供しています。

項目	仕様
方式	TOTP（RFC 6238 準拠）
コード桁数	6桁
有効時間	30秒（前後1ウィンドウの許容あり）
秘密鍵の暗号化	AES-256-GCM
バックアップコード	10個（暗号化保存）

二要素認証を有効にすることで、「知識（パスワード）」と「所持（認証アプリ）」の2つの要素による認証が実現されます。これは総務省ガイドラインにおける多要素認証の考え方に沿った対策です。

TOTP の秘密鍵は AES-256-GCM（認証付き暗号）で暗号化してデータベースに保存しており、暗号鍵が漏洩しない限り秘密鍵を復元することはできません。

3.3 ログイン試行制限

ブルートフォース攻撃（総当たり攻撃）を防止するため、ログイン試行回数を制限しています。

項目	仕様
最大試行回数	5分間に5回
ロックアウト時間	15分間
対象	ログイン ID またはメールアドレス単位

5分以内に5回連続でログインに失敗した場合、当該アカウントは15分間ロックされます。ロックアウト中はパスワードが正しくてもログインできないため、自動化された攻撃を効果的に防止します。

3.4 トークン認証

ログイン成功後は、JWT（JSON Web Token）を発行してセッション管理を行います。JWT とは、ログイン済みであることを証明する電子的な「通行証」のようなもので、画面操作のたびにこの通行証をシステムに提示することで、毎回パスワードを入力せずに安全に操作を続けることができます。

項目	仕様
トークン形式	JWT（JSON Web Token）
署名鍵	職員用と一般ユーザー用で分離
有効期限	設定可能（デフォルト: 1日）

職員用トークンと一般ユーザー（LINE アプリ）用トークンでは異なる署名鍵を使用しています。これにより、一方のトークンが漏洩しても他方のシステムには影響しません。

4. 認可・アクセス制御

4.1 ロールベースアクセス制御（RBAC）

本システムでは、RBAC（Role-Based Access Control） を採用しています。職員に対して1つ以上の「役割（Role）」を付与し、各役割に紐づく「権限クレーム（Claim）」により操作可能な範囲を制御します。

職員 (Staff)
  └── 役割 (Role) ← 複数付与可能
        └── 権限クレーム (RoleClaim) ← 複数設定可能
              ├── リソースタイプ (ClaimType): 16種
              └── 操作権限 (ClaimValue): 6種

職員に複数の役割が付与されている場合、すべての役割の権限が統合されます（いずれかの役割で権限があれば、その操作が許可されます）。これにより、組織の業務分掌に応じた柔軟な権限設定が可能です。

4.2 権限の種類と粒度

操作権限（6種）

各リソースに対して、以下の6種類の操作権限を個別に設定できます。

権限	説明	具体例
read	データの閲覧	一覧画面・詳細画面の表示
write	データの登録・更新	新規作成、編集
delete	データの削除	レコードの削除
print	帳票の印刷	PDF 帳票の出力
export	データの外部出力	CSV ファイルのエクスポート

「削除」権限は「編集」権限から独立しているため、「データの編集はできるが削除はできない」といった細かな制御が可能です。同様に「印刷」「データ出力」も独立した権限として管理されており、情報の持ち出しリスクを最小限に抑えることができます。

リソースタイプ（16種）

権限制御の対象となるリソースは以下の16種類です。

リソース	説明
user	ユーザー（住民）管理
staff	職員管理
venue	施設管理
log	ログ管理
eventMaster	イベントマスター
eventSchedule	イベントスケジュール
userTag	ユーザータグ
recommendedProgram	おすすめプログラム
notification	お知らせ
quocardPay	QUOカードPay
quocardPayValueCode	QUOカードPayバリューコード
cloudStorage	クラウドストレージ
video	動画
resident	住民
stampRally	スタンプラリー
supportTicket	サポートチケット

16種のリソース x 5種の操作権限 = 最大80通り の権限設定が可能であり、組織の業務要件に合わせたきめ細かなアクセス制御を実現します。

4.3 アクセス制御の適用フロー

すべての API リクエストは、以下の4段階のチェックを通過する必要があります。

1. 認証トークン検証
   └── JWT トークンの有効性を確認し、職員を特定

2. リソース種別の権限チェック (authScopes)
   └── 「この職員はこのリソースタイプにアクセスできるか」を判定

3. アクセススコープ算出
   └── 職員の自治体 ID・部署 ID を特定し、アクセス範囲を決定

4. データクエリへのスコープ強制付与
   └── データベースクエリに自治体 ID・部署 ID の条件を自動追加

各段階は独立して動作し、すべてを通過しなければデータにアクセスできません。この多段階チェックにより、単一の防御層への依存を排除しています。

5. マルチテナントデータ分離

5.1 論理分離の仕組み

本システムでは、複数の自治体が同一のデータベースを共有していますが、すべてのデータアクセスに対して自自治体のデータのみに限定するアクセス制御が自動的に適用されるため、他自治体のデータへのアクセスを防止する設計になっています。

データの保護は、アプリケーション側の制御とデータベース側の制御の2段階で行われます。

アプリケーション側の制御（画面操作時）

チェックポイント	説明
1. 操作権限の確認	ログイン中の職員が、その操作（例: 住民情報の閲覧）を行う権限を持っているかを確認します
2. 所属情報の自動判別	職員がどの自治体・どの部署に所属しているかをシステムが自動的に判別し、以降の処理に引き継ぎます

データベース側の制御（データ取得時）

チェックポイント	説明
3. データの自動絞り込み	データベースへの問い合わせ時に、自分の自治体のデータだけが取得されるよう、検索条件が自動的に追加されます

このように、アプリケーション側とデータベース側でそれぞれ独立した制御を行っているため、仮にどちらか一方に不具合があっても、もう一方がデータ漏洩を防止します。

5.2 他自治体のデータへの不正アクセス防止

万が一、通信内容が改ざんされ、他の自治体のデータを取得しようとする不正なリクエストが送られた場合でも、システムは以下の手順で自動的に防御します。

検知: リクエストに含まれる自治体の情報と、ログイン中の職員が所属する自治体の情報を比較し、不一致を検出します
記録: 不正なアクセスが試みられたことをシステムログに記録します
自動修正: リクエストの自治体情報を、職員が実際に所属する正しい自治体の情報に自動的に置き換えます
結果: 他の自治体のデータは一切表示されません

この防御はシステム内部で自動的に行われるため、画面側の操作や設定に関係なく、常にデータが保護されます。

5.3 想定される脅威と防御の仕組み

想定される状況	システムの防御内容	結果
職員が他の自治体のデータを閲覧しようとする	職員の所属自治体を自動判別し、自分の自治体のデータのみに絞り込みます	他自治体のデータは表示されません
通信内容が改ざんされ、他の自治体のデータを取得しようとする	不正を検知して記録し、正しい自治体の情報に自動修正します	他自治体のデータは表示されず、不正な試みが記録されます
閲覧のみ許可されている職員が、データの登録・更新を行おうとする	操作の種類（閲覧・登録・更新・削除）ごとに個別の権限チェックを行います	許可されていない操作は拒否されます
削除権限のない職員が、データの削除を行おうとする	削除は登録・更新とは別の独立した権限として管理されています	削除権限がなければ操作は拒否されます
一般利用者が他の利用者のデータにアクセスしようとする	利用者ごとに自分のデータのみ閲覧できるよう自動制限されます	他の利用者のデータは表示されません

5.4 物理分離方式との比較

「自治体ごとに別のサーバーを用意する（物理分離）方式」と本システムの「論理分離方式」を比較します。

観点	物理分離（自治体別サーバー）	論理分離（本システム）
データの独立性	サーバー単位で完全分離	アプリケーション層で自治体単位に分離（3重チェック）
セキュリティパッチ適用	各サーバー個別に対応が必要	一元管理で即時全体適用
セキュリティ基準の統一	サーバーごとにばらつくリスク	全自治体に同一のセキュリティ基準を自動適用
運用コスト	自治体数に比例して増加	共有基盤で効率化
障害影響範囲	他自治体に影響なし	基盤障害時は全体に影響（冗長化構成で軽減）
スケーラビリティ	サーバー追加が必要	基盤のスケールアップ/アウトで対応
監査の一貫性	個別に監査が必要	統一された監査ログで一元管理

論理分離方式の優位性

セキュリティパッチの即時適用: 脆弱性が発見された場合、すべての自治体に対して同時にパッチを適用できます。物理分離方式では各サーバーへの個別対応が必要なため、パッチ適用の遅延リスクがあります。
セキュリティ基準の統一: すべての自治体に対して同一のセキュリティ基準が自動的に適用されます。物理分離方式ではサーバーごとの設定ミスにより、セキュリティレベルにばらつきが生じるリスクがあります。
監査の一元管理: すべての自治体の操作ログが統一されたフォーマットで記録されるため、横断的な監査や不正検知が容易です。

6. 監査・ログ機能

6.1 4種のログ

本システムでは、4種類のログを 自動的に 記録しています。職員が意図的にログの記録を回避することはできません。

ログ種別	記録内容	用途
操作ログ（OperationLog）	誰が・いつ・何を登録/更新/削除したか	操作追跡・インシデント調査
画面アクセスログ（ScreenLog）	どの画面にいつアクセスしたか	アクセス傾向分析・不正検知
印刷ログ（PrintLog）	いつ・誰が・何を印刷したか	情報持ち出し管理
出力ログ（OutputLog）	いつ・誰が・何を CSV エクスポートしたか	データ出力管理

6.2 ログの特徴

自動記録: すべてのログはシステムにより自動記録されます。データの登録・更新・削除操作には操作ログが、画面表示にはアクセスログが、印刷・CSV 出力にはそれぞれ専用のログが自動的に付与されます。職員の操作による記録漏れはありません。
不正試行の記録: 他自治体の ID を指定するなどの不正なアクセス試行は、警告ログとして記録されます。
タイムスタンプ付き: すべてのログにはタイムスタンプが付与されており、操作の時系列を正確に追跡できます。

7. まとめ

多層防御による安全性

本システムは、「認証」「認可」「データ分離」「監査」の4層からなる多層防御アーキテクチャを採用しています。各レイヤーは独立して機能するため、単一障害点が存在せず、1つのレイヤーに問題が発生した場合でも他のレイヤーがデータを保護します。

マルチテナント論理分離の妥当性

複数の自治体が同一のシステム基盤を共有する論理分離方式は、アプリケーション層での3重チェック（API 認可層・アプリケーション層・データアクセス層）と不正試行の自動検知・記録により、他自治体のデータへのアクセスを確実に防止します。

さらに、論理分離方式には以下の運用上のメリットがあります。

セキュリティパッチの即時一元適用 により、パッチ適用の遅延リスクを排除
全自治体への同一セキュリティ基準の自動適用 により、設定ミスによるばらつきを排除
統一された監査ログによる一元管理 により、横断的な不正検知が可能

これらの特性により、本システムは複数の自治体が安全に共同利用できるセキュリティ基盤を提供しています。