セキュリティとプライバシー

suya CLI が認証情報をどう扱うか、そして Subaya がお客様のデータをどう分離するか。

API キーはシークレットです

SUBAYA_API_KEY は、プラットフォーム上のアイデンティティに直接解決される認証情報です。他の あらゆるシークレットと同様に扱ってください:

• リポジトリに決してコミットしない、またはイメージに焼き込まない。
• 環境変数または CI/CD のシークレットストアを通じて注入する。
• コンソールからキーを発行・失効させ、それを必要とするワークロードにスコープする。

export SUBAYA_API_KEY="sk_..."
suya auth whoami      # confirm the identity the key resolves to

認証情報の優先順位

複数の認証情報が存在する場合、suya は次の順序で解決します:

1. --token グローバルフラグ
2. SUBAYA_API_KEY
3. ローカルに保存された OAuth トークン

--token フラグはすべてに優先するため、コマンドラインの明示的なトークンが常に勝ちます — 一度限りの上書きに便利ですが、長命のシークレットをシェル履歴に置くのは避けてください。

トークンストレージ

OAuth ブラウザフロー（suya auth login）は、そのトークンを ~/.config/suya/ の下にローカルに 保存します。このディレクトリはお客様のアクティブなセッションを保持します。通常のファイル システムのアクセス権限で保護してください。それを消去し、サーバー上のトークンを失効させるには:

suya auth logout      # log out and revoke the local token
suya auth status      # confirm local auth state, no server call

テナント分離

Subaya のテナンシーは組織 → ワークスペース → プロジェクトにスコープされます:

• 組織は最上位テナントです — 課金、メンバー、ライセンスがここに存在します。
• ワークスペースは組織内のプロジェクトをグループ化します。
• プロジェクトは作業の単位です。

データは組織間およびワークスペース間で分離されます: 認証情報とクエリは、それが属するテナントに スコープされるため、ある組織の設計、シミュレーション、アーティファクトが別の組織に見える ことはありません。完全なテナンシーモデルについては コアコンセプト をご覧ください。

関連

• 認証と API キー — 2 つの認証モードの詳細。
• CLI: auth — suya auth の完全なリファレンス。