TASHIKA Docs

Appearance

セキュリティ要件 ​

本ドキュメントは、TASHIKAプラットフォームのセキュリティに関する要件を定義します。

NOTE

分類は IPA 非機能要求グレード 大項目 E に準拠しています。

SR-001: ユーザー種別とアクセス範囲 ​

ユーザー種別アクセス範囲
従業員自分のデータのみ
企業管理者自社全従業員のデータ
代行事業者スタッフ担当顧問先のみ
代行事業者管理者全顧問先 + スタッフ管理
システムサポート全テナント（個人情報マスキング下、閲覧のみ）
システム管理者全テナント + システム設定変更

SR-002: 認証要件 ​

  • 水平スケーリングに対応した認証方式を採用すること
  • セッション管理をサーバー側で行い、同時セッション数制限（SR-005）の実施基盤とすること
  • (将来)IDaaS移行オプション: エンタープライズ顧客からSOC2等のコンプライアンス認証が求められた場合、外部IDaaSへの移行を可能とすること
  • SSO連携: エンタープライズSSO（SAML 2.0 / OIDC）有効時は、IdP認証成功後にTASHIKAのセッションを確立する。SSO認証とローカル認証を共通のセッション確立フローに統合すること（→ SR-012）

SR-003: 多要素認証 (MFA) 要件 ​

  • 代行事業者（Agency）、企業管理者、システム運営者には、2要素認証を必須とする
  • 従業員（Employee）にはオプションで提供
  • TOTP（Authenticatorアプリ）をサポートすること

SR-004: 認可要件 ​

  • ポリシーベース認可を採用し、単なるロールだけでなくクレームに基づくアクセス制御を行うこと
  • TenantPolicy: テナント間のデータ分離をDBレベル（RLS）で強制すること
  • AgencyPolicy: 顧問先横断アクセスを適切に制御すること
  • ImpersonationPolicy: 代理ログイン時は個人情報を自動マスキングし、閲覧のみ許可すること
  • DepartmentScopePolicy: 企業管理者に部署スコープ（→ DM-205）が設定されている場合、当該部署（及び配下部署を含む設定時は配下部署）に所属する従業員のデータのみにアクセスを制限すること。スコープ未設定の企業管理者は全部署にアクセス可能
  • ExternalApiPolicy: OAuth2.0 / OpenID Connect に準拠し、スコープに基づくアクセス制御を行うこと

SR-005: セキュリティポリシー要件 ​

パスワードポリシー ​

  • 最小12文字、大文字/小文字/数字/記号を含む複雑性要件
  • 過去5世代のパスワード再利用禁止
  • 定期的な変更強制は行わない（NIST SP 800-63B 準拠）

セッション管理 ​

  • 同時セッション数制限（デフォルト3デバイス）
  • アイドルタイムアウト（30分）
  • 管理者による強制ログアウト機能（全デバイスからの即時セッション破棄）
  • セッション一覧表示: ユーザーが自分のアクティブセッション（デバイス、IP、最終アクセス日時）を確認・個別破棄可能

ログイン試行制限 ​

  • 5回連続失敗でアカウント一時ロック（15分）
  • 異常なIPからのアクセスにはCAPTCHA表示、レート制限を適用

パスワードリセット ​

  • メールベースのパスワードリセット、リンク有効期限（1時間）
  • リセット完了時に本人確認メール通知
  • パスワードリセット実行時、全アクティブセッションを無効化

招待・オンボーディング ​

  • 従業員は自己登録不可。管理者が招待 → メールで初回ログイン用リンク送付 → パスワード設定
  • 招待リンクの有効期限（7日）と再送機能

SR-006: マルウェア対策要件 ​

  • 従業員がアップロードした全ファイル（画像/PDF/XML）に対し、保存前に自動ウイルススキャンを実行すること
  • 感染ファイルの保存を防止し、アップロード者に警告を表示すること

SR-007: 代理入力モード要件 ​

  • スマホを使えない/拒否する従業員のため、管理者が紙で回収した内容を代理入力できる機能を提供すること
  • 「誰が代理入力したか」を監査ログに明記すること
  • 代理入力中は画面上に「代理入力モード」であることを常時表示すること

SR-008: APIセキュリティ要件 ​

レート制限 ​

  • テナントごとに API レート制限を適用（デフォルト: 1,000 req/min）
  • レート超過時は 429 Too Many Requests を返却
  • バースト許容: 短時間の突発的なリクエストは一定量まで許容

Webhook セキュリティ ​

  • Webhook送信時にHMAC-SHA256署名をヘッダーに付与
  • 受信側（外部システム）は署名検証でリクエストの真正性を確認
  • Webhookペイロードにはマイナンバー等の機微情報を含めない（IDベースで参照）

通信セキュリティ ​

  • 全通信にTLS 1.3を強制。TLS 1.2以下は拒否
  • HSTS (HTTP Strict Transport Security) を有効化
  • CSP (Content Security Policy) を適用し、XSS攻撃を防止
  • CORS: 許可されたオリジンのみにAPI応答を返却

SR-009: データ分類と保護レベル ​

分類例保護要件
極秘 (Restricted)マイナンバーアプリケーションレベル暗号化。アクセスログ必須。閲覧は最小限の権限者のみ
機密 (Confidential)給与額、扶養親族情報、申告データDBレベル暗号化（保存時暗号化）。RLSによるテナント分離。代理ログイン時はマスキング
社内限定 (Internal)従業員氏名、部署、メールアドレスRLSによるテナント分離。操作ログ記録
公開 (Public)税額表、保険料率マスタ特別な保護は不要。改ざん防止のみ

SR-010: インシデント対応要件 ​

検知 ​

  • 異常パターン（大量ダウンロード、深夜の大量アクセス、通常とは異なるIPからのログイン等）を自動検知しアラートを発報すること

対応フロー ​

  • セキュリティインシデント発生時の対応フロー（検知 → 封じ込め → 影響調査 → 通知 → 復旧 → 再発防止）を整備すること
  • マイナンバー漏洩時は個人情報保護委員会への報告義務を遵守すること

通知義務 ​

  • 個人データの漏洩・滅失・毀損が発生した場合、関係する企業管理者および従業員に速やかに通知すること
  • 通知内容: 事象の概要、影響範囲、講じた措置、問い合わせ窓口

SR-011: シークレット管理 (Secrets Management) ​

アプリケーションが使用するすべてのシークレット（暗号鍵、接続文字列、APIキー等）は、一元管理された鍵管理サービスを通じて安全にライフサイクル管理すること。

ローテーションポリシー ​

シークレット種別ローテーション頻度備考
マイナンバー暗号鍵 (DEK)年次→ CR-009
マイナンバー鍵暗号鍵 (KEK)年次HSM 保護
認証トークン署名鍵90日
DB 接続認証情報90日
外部 API キー発行元のポリシーに準拠期限30日前にアラート
TLS 証明書自動更新期限30日前にアラート

ゼロダウンタイムローテーション ​

  • ローテーション中はデュアルキー方式（新旧鍵の並行運用）を採用し、サービス停止を伴わないこと

緊急ローテーション要件 ​

シークレットの漏洩が疑われる場合、以下の手順を即時実行可能とする:

  • 漏洩した鍵の即時無効化（並行運用期間なし）
  • 新しい鍵の生成と適用
  • 影響を受けた全セッションの強制無効化（認証トークン署名鍵の場合）
  • インシデント対応フロー（→ SR-010）との連携

禁止事項 ​

  • シークレットのソースコード・設定ファイルへのハードコード
  • シークレットの環境変数での直接管理（鍵管理サービス経由を必須とする）
  • シークレットのログ出力・エラーメッセージへの含有
  • 本番シークレットの開発・ステージング環境での流用

SR-012: SSO・フェデレーション認証要件 ​

エンタープライズSSO導入に伴うセキュリティ要件を定義する。

SAML 2.0 セキュリティ ​

  • SAML Response の XML署名検証を必須とし、未署名または検証失敗のアサーションを拒否すること
  • アサーションの NotBefore / NotOnOrAfter を検証し、リプレイ攻撃を防止すること（使用済みアサーションIDをキャッシュして重複排除）
  • Assertion Consumer Service (ACS) URL のホワイトリスト検証を行うこと
  • IdP メタデータの署名証明書有効期限を監視し、期限30日前にアラートを発報すること

OIDC セキュリティ ​

  • Authorization Code Flow + PKCE (Proof Key for Code Exchange) を必須とし、認可コード横取り攻撃を防止すること
  • ID Token の検証: iss（発行者）、aud（対象者）、nonce（リプレイ防止）、exp（有効期限）を必ず検証すること
  • state パラメータによる CSRF 防止を実施すること
  • トークンエンドポイントとの通信は TLS 1.3 を強制（→ SR-008）

セッション管理 ​

  • SSO セッションと TASHIKA セッション（JWT）は独立管理とする。IdP 側でセッションが切れても、TASHIKA のアクセストークン有効期限内（15分）は継続利用可
  • Single Logout (SLO): IdP 起点のログアウト要求（SAML LogoutRequest / OIDC Front-Channel Logout）を受け付け、TASHIKA 側のセッションを破棄すること
  • SSO 強制モード有効時、ローカル認証でのログインは break-glass アカウントのみに制限すること

監査・運用 ​

  • SSO 設定の変更（IdP 追加・削除・プロトコル変更・証明書更新）は監査ログに記録すること
  • SSO 認証の成功・失敗イベントを監査ログに記録し、異常パターン検知（→ SR-010）の対象とすること
  • IdP 障害時のフォールバック: SSO 強制モードであっても、break-glass アカウントによるローカル認証を維持し、管理者のロックアウトを防止すること