組織

OpenFactory の組織 API には、組織のメンバーシップに加えて、オプションのグループ、ユニット、チームが保存されます。また、会話/バリエーションを共有するためのターゲットも提供します。


organization
├── members: owner | admin | member
├── groups: organization-level sharing collections
└── units
    ├── unit members
    └── teams
        └── team members

この階層は認証入力です。ロールラベルは、すべてのビルド、VM、ダウンロード、または展開エンドポイントが意図したポリシーを適用していることを証明するものではありません。各ロールが現在管理しているルートについては、ロールと権限の範囲を参照してください。

コアオブジェクト

組織: トップレベルのメンバーシップと管理境界。ユーザーは複数の組織に所属できます。
グループ: 共有ターゲットとして使用される組織メンバーの名前付きコレクション。それは管理上の階層ではありません。
ユニット: 独自のメンバーシップと保存されたワークフローロールを持つ部門のようなコンテナー。
チーム: 独自のメンバーシップと保存されたワークフローロールを持つユニットの子。

ユーザーは組織の下に追加される前に、組織のメンバーである必要があります。

安全なセットアップ手順

組織を作成します。作成者が所有者になります。
永続的な運用を組織に依存する前に、2 人目の責任ある所有者を追加します。
ユーザーを正確な電子メールアドレスに招待し、必要な最も低い組織の役割を割り当てます。
ユニットまたはチームは、その範囲が実際のワークフローを変更する場合にのみ追加します。
各代表的な役割を使用して、許可されたアクションと拒否されたアクションを 1 つずつテストします。
役割の削除とセッションの更新後の共有とメンバーシップの動作を確認します。

招待には有効期限があり、電子メールが招待と一致するアカウントによって受け入れられる必要があります。チケットや公開ログ内の招待トークンを送信しないでください。

コンテキストと所有権

組織の選択は、表示されるコラボレーションデータに影響を与える可能性がありますが、個々のリソースには引き続き所有者ルールと共有ルールが適用されます。 2 人のユーザーが同じ組織に属しているという理由だけで、プライベートビルドまたはアーティファクトへのアクセスを推測しないでください。サポートされている場合は明示的な共有を使用し、ダウンロード/VM アクションを個別にテストします。

隔離の証拠

組織と共有ルートは、対象範囲の操作に対してメンバーシップチェックと同じ組織の検証を実行します。「テナント分離」はより広範なシステムプロパティであり、会話、ビルド、アーティファクト、VM、API、キャッシュ、エクスポート、ログにわたるテナント間の拒否パステストが必要です。組織階層だけをその証拠として使用しないでください。

管理上の保護措置

複数の所有者がサポートされています。唯一の所有者は離れることができません。
所有者のみが別の所有者を昇格したり、組織を削除したりできます。
削除とメンバーシップの削除は、依存アクセスに影響を与える可能性があります。最初に、共有、ユニット、チーム、アクティブなセッション、および所有されているリソースをインベントリします。
ポリシーで外部監査記録が必要な場合は、外部監査記録を保存します。現在の役割リストは履歴監査証跡ではありません。

共有とユニットとチームに進みます。