セキュリティ

設計哲学

niyase は 規模を問わず同一強度 のセキュリティを提供します。「軽いセキュリティで安いプラン」は作りません。SOC 2 Type II をはじめとする監査基準の水準で運用し、認証取得を準備中です。

データ暗号化

場所	暗号化
デスクトップ DB	SQLite 暗号化（OS keyring 連携）
モバイル DB	SQLCipher（expo-sqlite v16+）
クラウド DB	カラムレベル暗号化（PII）+ at-rest 暗号化
バックアップファイル	同一の暗号化適用
通信	TLS 1.3

機微情報（マイナンバー・口座番号等）はアプリケーション層でも暗号化して保管しています。

テナント分離

クラウド DB は Central DB / WS DB に分離しています:

• Central DB: ユーザー・スペース（slim）・課金等の共通情報
• WS DB: 各スペースの業務データ（社員・勤怠・給与・会計等）

WS DB は他スペースの WS DB にアクセスできません。物理的にデータ漏洩経路を遮断しています。

加えて Postgres の RLS (Row Level Security) を全テーブルに適用し、アプリケーション層のバグでも横断アクセスが起きないよう二重化しています。さらに権限に応じた 列単位のマスク を組み合わせ、ロールや権限が変わると次回同期時に見える行・項目が自動的に絞り込まれます。

アクセス制御

スペース内の役割 (role):

役割	権限
OWNER	スペース全権・課金・削除
ADMIN	メンバー管理・設定変更
MEMBER	一般業務
各機能のカスタムロール	プラグイン側で定義可能

OWNER の譲渡は必ず明示操作で行います。

監査ログ

すべての書き込み操作は監査ログに残ります:

• 誰が（user_id・端末）
• いつ（タイムスタンプ）
• どこで（スペース・メニュー）
• 何を（テーブル・レコード ID・before/after）
• どこから（IP・User-Agent）

監査ログは WORM (Write Once Read Many) として保管し、後から改ざんできません。

認証

• パスワード + 2 段階認証（TOTP）
• パスキー（推奨）
• Google ログイン
• セッション一覧 + 個別ログアウト
• デバイス ID + 不審ログイン検知

PPAP（ZIP パスワードの別送）は採用しません。

インシデント対応

セキュリティに関する問題を発見した場合は security@niyase.com までご連絡ください。