メインコンテンツへスキップ

Documentation Index

Fetch the complete documentation index at: https://factory-docs-auto-sync-jp-docs.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

アイデンティティとアクセス管理制御は、誰がDroidを実行できるか、どの環境で、どのようなポリシーの下で実行するかを制御します。 このページでは、アイデンティティモデル、ロール、環境の概要を説明します。詳細なSSOとSCIM設定手順は SSO、IdP、SCIMプロビジョニング にあります。

​
アイデンティティモデル

すべてのDroid実行は、3つのアイデンティティ次元に関連付けられます：

ユーザーまたはマシンID

人間の開発者はSSO（SAML/OIDC）で認証し、ディレクトリグループとロールを継承します。自動化（CI/CD、スケジュールジョブ）は、長期トークンまたはワークロードIDを持つマシンIDで実行されます。

組織 / プロジェクト / フォルダ

アクティブなリポジトリと.factory/フォルダが、組織、プロジェクト、 フォルダコンテキストを決定します。これらのレベルのポリシーが、Droidが使用できるモデル、ツール、 連携を決定します。

ランタイム環境

DroidがノートPC、CIランナー、サンドボックス化されたVM/devcontainerのどこで実行されているかが環境属性として取得されます。ポリシーはこれらを異なる扱いにできます（例: CIやサンドボックス内でのみ高い自律性を許可）。

セッションメタデータ

各Droidセッションは、セッションID、CLIバージョン、gitブランチなどのメタデータを記録し、監査とOTELテレメトリで利用できます。

​
組織アイデンティティとSSO（概要）

ほとんどの企業は、Okta、Azure AD、またはGoogle Workspaceなどのアイデンティティプロバイダー（IdP）とFactoryを統合します。 高レベルでは：
  • 組織メンバーシップは、Factory組織とチームにマッピングされたIdPグループから派生します。
  • SSOサインインにより、開発者は企業の認証情報を使用してWebプラットフォームとDroidの両方にアクセスできます。
  • ロール情報（例：Owner、Admin、User）は、IdPグループからFactoryロールに流れます。
IdPアプリケーションの設定、属性のマッピング、プロビジョニングの有効化を含む、段階的なSSOとSCIM設定については、SSO、IdP、SCIMプロビジョニング を参照してください。

​
ロールベースアクセス制御（RBAC）

Factoryは3つの主要なアクター分類を区別します：
  • 組織管理者
    • モデルポリシー、グローバルコマンドの許可/拒否リスト、デフォルトのテレメトリターゲットを含む、組織レベルの .factory 設定を定義します。
    • どのデプロイメントパターン（クラウド、ハイブリッド、エアギャップ）がサポートされ、Droidバイナリがどこで実行できるかを決定します。
    • 最大自律性レベルやユーザー提供のBYOKキーが許可されるかどうかなどのセキュリティ機能を設定します。
  • プロジェクトオーナー/メンテナー
    • バージョン管理に存在するプロジェクトレベルの .factory/ フォルダーを所有します。
    • 組織ポリシーを弱めることなく拡張する、チーム固有のモデル、ドロイド、コマンド、フックを提供します。
    • Droidを特定のリポジトリやディレクトリに制限するなど、プロジェクト固有のポリシーを設定します。
  • 開発者
    • ~/.factory/ で個人設定をカスタマイズします（例：許可されたセット内でのデフォルトモデル選択）。
    • ローカル、IDE、またはチーム提供のスクリプトやCIジョブを通じてDroidを実行します。
    • 組織またはプロジェクトレベルで定義された設定を上書きすることはできません。
ロール割り当てはIdPからFactoryに流れ、階層設定エンジンが各ロールが実際に変更できる内容を強制します。正確な優先順位ルールについては 階層設定と組織管理 を参照してください。

​
デバイス、環境、ワークスペーストラスト

DroidはCLIであるため、多くの環境で実行できます：
  • 開発者のラップトップ（macOS、Linux、Windows）
  • リモート開発サーバーまたはワークスペース
  • CIランナーとビルドエージェント
  • 強化されたVMとdevcontainer
エンタープライズ顧客は通常、Droidをエンドポイント管理とワークスペーストラスト制御と組み合わせます：
Jamf、Intune、その他のMDMソリューションなどのツールを使用して、Droidバイナリのインストール場所、実行できるユーザー、読み取れる設定ファイルを制御します。一般的なパターンは次のとおりです:
  • 管理対象ユーザーアカウントでのみDroidの実行を許可する。
  • 設定ディレクトリを会社管理のボリュームに制限する。
  • OSレベルのディスク暗号化と画面ロックポリシーを適用する。
Droidを既知のリポジトリと環境でのみ信頼済みとして扱います:
  • 開発者のマシンでDroidを特定のパスまたはリポジトリに固定する。
  • 信頼できないコードには、追加承認またはサンドボックス環境を必須にする。
  • プロジェクトレベルの.factory/フォルダを使用し、どのリポジトリが”Droid-ready”か、どのポリシーを適用するかを示す。
同じ開発者が、ノートPC、CI、分離コンテナなど複数のコンテキストでDroidを実行する場合があります。ポリシーはこれらの違いを考慮できます:
  • devcontainerまたはCIランナー内でのみ、より高い自律性や強力なツールを許可する。
  • ノートPCで実行している場合はネットワークアクセスやコマンド実行を制限する。
  • 環境固有のアラートをサポートするため、OTELテレメトリに環境属性を付与する。

​
アイデンティティがポリシーとテレメトリにどのように流れるか

アイデンティティと環境情報は主に2つの方法で使用されます：
  1. ポリシー評価 – 階層設定（組織 → プロジェクト → フォルダー → ユーザー）はアイデンティティを使用して、特定の実行にどの設定バンドルが適用されるかを決定します。
  2. テレメトリと監査 – Droidは user.id、team.id、session.id、環境タグなどの属性を含むOTELメトリクス、トレース、ログを出力するため、組織別およびチーム別のダッシュボードを構築できます。
これらのアイデンティティがテレメトリでどのようにエンコードされるかの詳細については、コンプライアンス、監査、モニタリング を参照してください。