セキュリティ

設計哲学

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) を全テーブルに適用し、アプリケーション層のバグでも横断アクセスが起きないよう二重化しています。さらに権限に応じた 列単位のマスク を組み合わせ、ロールや権限が変わると次回同期時に見える行・項目が自動的に絞り込まれます。RLS を一時的に外して動作する必要のある内部処理（初期プロビジョニング等のごく限られたシステム経路のみ）も、どこで・なぜ外すかを 1 箇所で宣言し、自動検証で網羅性を担保しています。

アクセス制御

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

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

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

外部連携や自動化には、本人のアカウントに紐づく 個人アクセストークン (PAT) も利用できます。有効期限が必須（無期限のトークンは発行できません）で、アカウントの全ログアウトと同時に一括で無効化でき、バックアップ・エクスポートなど機微情報をまとめて取得する操作には使えません。発行・管理方法はアカウントを参照してください。

監査ログ

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

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

記録される操作（アクション）の種類は、実装からもれなく導出される型で管理しており、書き漏れが構造的に起きないようになっています。書き込み経路も単一の仕組みに一本化されているため、機微な操作は確実に記録されます。

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

認証

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

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

ネットワーク保護

クラウドへの通信はエッジの WAF（Web Application Firewall）を経由し、SQL インジェクションやクロスサイトスクリプティングといった典型的な攻撃を既定で遮断します。

インシデント対応

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