Skip to main content
Starfort は、テナントのリソースを 4 階層の構造のもとに整理し、その最上位（Global）にはプラットフォームそのものが位置します。

Company

最上位のテナントです。Control Profile、Agent User、Desktop Agent の Access Key、クォータなど、全社的な設定を保持します。

Organization

チームや事業部門のための、Company 内のグループです。

Project

Module Instance（Project Guardian / Project Stratum）を作成し、認証情報を管理する場所です。各プロジェクトには固定のタイプがあります。
Global は Company の上位に位置し、プラットフォーム運用者（System Admin）が管理する、システム全体に及ぶスコープであり、個々の会社のデータからは分離されています。

​
Account と Multi-Company

Account は、コンソールにログインする認証主体です — トラフィックが統制対象となる Agent User や API End User とは区別されます。1 つの Account は複数の Company に同時に所属できます（Multi-Company）。ログイン時に会社を選んでコンテキストを切り替えます。認証（本人確認）と権限は分離されています — Account が認証を行いますが、その権限は (Account, Company) コンテキストで解決され、1 つのコンテキストが複数のロールを保持できます。 テナントは分離されています。ポリシー、ログ、権限のデータが、Company や Project の境界を越えて公開されることはありません。

​
プロジェクトタイプ

プロジェクトを作成する際にそのタイプを選択します。タイプは後から変更できません。
  • API — 自社アプリケーションに Guard API を組み込むためのものです。API キーを管理します。
  • Desktop Agent — Windows の Desktop Agent を通じて、従業員の AI ツール利用を保護するためのものです。Control Profile と Agent User を通じて管理されます。

​
Project 配下の Module Instance

Project のタイプがトラフィックの入ってくる連携方式を決めるのに対し、Project 内で何を検査するかは Module Instance が決めます。Project は付与されたエンタイトルメントの範囲内で Module Instance — Project Guardian（テキスト入力）と Project Stratum（ファイル） — を作成・削除します。この 2 つの軸は互いに独立しているため、どちらの Project タイプでも 2 つのモジュールを併用できます。Module Instance を参照してください。

​
ロール

アクセスは RBAC によって統制されます。Role は IAM Policy（システムアクセスのルール）をまとめたものであり、Account にロールが付与されます。標準のロールは次のとおりです。 Organization と Project は、4 つのロールすべてを自動作成します。Company は Owner と Viewer のみを自動作成します。IAM Policy を組み合わせて Custom Role を定義することもできます。
IAM Policy ≠ Guard Policy。 IAM Policy は、誰がシステムにアクセスできるかを統制します（RBAC、Account → Role）。Guard Policy は、コンテンツを統制します（Project Guardian → 入力/出力のフィルタリング）。どちらも Console で管理されますが、目的は異なります。

​
階層に従うガバナンス制御

​
Kill Switch（3 階層）

Kill Switch は、Organization、Project、Module Instance（Project Guardian・Project Stratum）という 3 つのリソース階層における緊急用の切り替えスイッチであり、いずれの階層も独立して切り替えられます。有効化すると、その階層配下のすべての Module Instance を停止する一方で、各リソース自身の状態は保持します。解除すると、保持された状態から再開します。Module Instance 単位で発動できるため、Project 全体を止めずに特定のモジュールだけを緊急遮断できます。注意点:
  • Company には独自の Kill Switch がありません — 代わりに、上位の権限がその配下のすべてのリソースをトリガーできます。
  • これは API Key の状態（Active / Inactive / Revoked）とは直交します。Bastion はリクエストごとに両方を検証します。
  • マスターである System Guardian は、Kill Switch の対象外です。
Kill Switch の使用を参照してください。

​
Audit Log とモニタリング

  • 監査ログ は、ガバナンスの変更のみ — 管理上/運用上の操作 — を記録します。ランタイムのリクエスト/レスポンスのトレース、システムの自動イベント（ハートビート、ヘルスチェック）、単純な読み取り、拒否された試行は記録しません。監査ログには 2 つの階層があります。Company 監査ログ と、/aim System 監査ログ です。これは改ざん不可能です。監査ログを参照してください。
  • モニタリング（Opticon）は、プロジェクトごとのランタイムのトレース — 監査ログ とは別の記録レイヤー — を表示します。トレースのモニタリングを参照してください。
初めての方は、Account Admin 向けクイックスタートで、Company、Organization、Project、Guardian、キーの作成までを一通り順を追って説明しています。