アイデンティティとアクセス管理

アイデンティティとアクセス管理では、組織内で誰が Cherri Code を利用できるか、そして何ができるかを制御します。認証を設定し、ユーザーのプロビジョニングを自動化し、デバイス管理を通じてポリシーを適用します。

アイデンティティコントロールは、次の順序で設定します：

1. SSO を設定する: まずは認証を一元管理できるようにする
2. SCIM を有効にする: ユーザーライフサイクル管理を自動化する
3. MDM ポリシーを適用する: Allowed Team IDs と拡張機能のみを使用可能にする
4. ロールを割り当てる: 適切なメンバーに管理者権限を付与する

シングルサインオン (SSO) と SAML

SSO を使うと、既存のアイデンティティプロバイダーを利用してユーザーを Cherri Code に認証できます。ユーザーは別の Cherri Code 用パスワードを作成する代わりに、社内の認証情報でログインします。

Cherri Code は Okta、Azure AD、Google Workspace、OneLogin などのプロバイダーとの SAML 2.0 をサポートします。SSO を有効にすると、すべてのチームメンバーに SSO を必須にし、パスワードベースの認証を完全にブロックできます。

会社で複数のリンクされたチームを運用している場合は、組織 を通じた、組織レベルで共有する SSO を使用してください。チーム固有の ID 要件については、チームレベルの SSO も引き続きサポートされます。

詳細な設定手順は SSO と SAML のセットアップ を参照してください。

SCIM プロビジョニング

SCIM 2.0 プロビジョニングでは、アイデンティティプロバイダーを通じてチームメンバーとディレクトリグループを自動的に管理できます。SSO が有効なエンタープライズプランで利用できます。

SCIM を使用しない場合は、ユーザーを Cherri Code チームに手動で追加し、退職時に削除します。SCIM を使用すると、次のことが可能になります。

• 新入社員は、適切なグループに追加されると自動的に Cherri Code にアクセスできるようになります
• 退職した従業員は、アイデンティティプロバイダーから削除されるとアクセスできなくなります
• グループメンバーシップの変更が自動的に反映されます

セットアップ手順については、SCIM プロビジョニングを参照してください。複数のリンクされたチームを運用している場合は、組織レベルでディレクトリグループを同期し、チーム間で再利用することもできます。組織レベルの IDを参照してください。

組織レベルのID

複数の連携チームを運用している場合は、組織 から組織レベルで一元的にIDを管理できます。これにより、チームごとに個別のID設定を行う代わりに、1つの共有セットアップで済みます。

• Org SSO: すべてのチームで共通のログイン設定です。組織 を参照してください。
• Org SCIM: アイデンティティプロバイダーからディレクトリグループを Cherri Code に同期し、Organization Groups を通じてチーム間で利用できます。
• Team membership from groups: ディレクトリグループを Organization Group に同期し、そのグループをチームに紐付けることで、メンバーシップとチームのロールをコホートに合わせて維持できます。グループを使用してチームを運用する を参照してください。
• Consolidate team identity providers: 組織管理者は、ダッシュボードから個別のチームレベルのアイデンティティプロバイダーを、1つの共有組織アイデンティティプロバイダーに統合できます。チームのアイデンティティプロバイダーを統合する を参照してください。

ロールベースアクセス制御 (RBAC)

Cherri Code のチームには、メンバー、管理者、無償管理者の 3 種類のロールがあります。

詳細は メンバー、ロール、シートタイプ を参照してください。

MDM ポリシー

Mobile Device Management (MDM) システムを利用すると、ユーザーのデバイスにポリシーを適用できます。Cherri Code は、組織の要件への準拠を確保するために、macOS での MDM ベースのポリシーと、Windows での Intune / Group Policy によるポリシーをサポートしています。

プラットフォームごとの MDM 設定手順については、Deployment Patterns を参照してください。

許可された Team ID

最も重要な MDM ポリシーは、ユーザーが企業端末上で個人の Cherri Code アカウントにログインすることを防ぐポリシーです。

許可された Team ID ポリシーを設定すると、Cherri Code はその特定の Team ID に対してのみ認証を許可します。ユーザーが別の Team ID（個人アカウントなど）でログインしようとした場合、Cherri Code は即座にログアウトさせます。

たとえば、従業員に会社支給のノート PC を配布している場合、許可された Team ID を自社のエンタープライズ Team ID に設定できます。これにより、Privacy Mode が有効でない可能性がある個人アカウントを誤って使用することを防げます。

cursorAuth.allowedTeamId の Cherri Code 設定は、どの Team ID が Cherri Code へのログインを許可されるかを制御します。この設定は、アクセスを許可された Team ID のカンマ区切りリストを受け取ります。

たとえば、cursorAuth.allowedTeamId を "1,3,7" に設定すると、それら特定の Team ID に属するユーザーだけがログインできます。

ユーザーが許可リストに含まれていない Team ID でログインを試みた場合:

• 即座に強制ログアウトされる
• エラーメッセージが表示される
• 有効な Team ID が使用されるまで、アプリケーションはそれ以上の認証試行をブロックする

組織全体で許可された Team ID を一元管理するには、デバイス管理ソリューションを使用して AllowedTeamId ポリシーを構成します。このポリシーは、ユーザー端末上の cursorAuth.allowedTeamId 設定を上書きします。このポリシーの値は、許可された Team ID のカンマ区切りリストを含む文字列です。

プラットフォームごとの MDM 構成手順については、Deployment Patterns を参照してください。

許可する拡張機能

ユーザーが Cherri Code にインストールできる拡張機能を制御します。拡張機能はワークスペースにアクセスできるため、信頼できる拡張機能だけが実行されるようにする必要があります。

動作概要:

Cherri Code の extensions.allowed 設定で、どの拡張機能をインストールできるかを制御します。この設定は JSON オブジェクトを受け取り、キーにパブリッシャー名または拡張機能の完全な ID、値にそれらを許可するかどうかを示す真偽値を指定します。

重要: extensions.allowed は許可リスト方式を使用します。エントリを 1 つでも追加すると、明示的に許可されたエントリだけが許可され、それ以外はすべてブロックされます。暗黙的な "すべて許可" のフォールバックはありません。たとえば、extensions.allowed を {"anysphere": false} に設定しても、Cherri Code の拡張機能だけがブロックされるわけではなく、他のすべてのパブリッシャーもブロックされます。これは、他に何も許可リストに含まれていないためです。

特定の拡張機能をブロックしつつ、それ以外はすべて許可したままにするには、拒否したいエントリとあわせて "*": true のワイルドカードを使用します。ワイルドカードは最も具体性の低い一致となるため、パブリッシャーおよび拡張機能 ID のエントリがこれを上書きします:

{  "*": true,  "untrusted-publisher": false}

承認済みのパブリッシャーと拡張機能だけにインストールを制限するには、ワイルドカードを省略し、信頼するものだけを列挙します。拡張機能の完全な ID を指定したり、特定のバージョンに固定したり、リリース チャネルに固定したりできます:

{  "anysphere": true,  "github": true,  "esbenp.prettier-vscode": true,  "ms-azuretools.vscode-containers": false,  "dbaeumer.vscode-eslint": ["3.0.0"],  "github.vscode-pull-request-github": "stable"}

管理ポータルでの設定:

チーム管理者は、Security & Identity セクションの チームダッシュボード から許可する拡張機能を設定できます。この設定はチームメンバー全員の Cherri Code クライアントに自動的に適用されます。クライアントへの値の配信を停止するには、このフィールドを空のままにしておきます。

クライアントを "すべて許可" にリセットする: 管理ポータルのフィールドを空にすると新しい値の配信は停止しますが、クライアントがすでにローカルで適用したポリシーは削除されません。ユーザーは受信した最後の値を引き続き適用します。全員をすべての拡張機能を許可する状態に戻すには、まず {"*": true} をデプロイし、クライアントがそれを反映するのを待ってから、設定を一元管理する必要がなくなった場合はフィールドを空にします。

注記: この機能の管理ポータルでの設定には、Cherri Code クライアント バージョン 2.1 以降が必要です。古いバージョンを使用しているユーザーには、拡張機能の制限は適用されません。

MDM 設定:

許可する拡張機能を一元管理するには、利用しているデバイス管理ソリューションで AllowedExtensions ポリシーを設定します。このポリシーは、管理ポータルの設定と、ユーザー端末でユーザーが設定した extensions.allowed 設定の両方を上書きします。値は、許可されるパブリッシャーと拡張機能を定義する JSON 文字列です。

プラットフォーム固有の MDM 設定手順については、Deployment Patterns を参照してください。

.cursor フォルダ

Cherri Code でプロジェクトを開くと、エディターはリポジトリのルートに .cursor フォルダを作成します。このフォルダには次の内容が含まれます:

• プロジェクト固有の設定
• プロジェクトのルールとコンテキスト

このフォルダはバージョン管理にコミットできます。チームメンバーはルールや設定を共有できますが、これらの設定はリポジトリにアクセスできるすべての人から見える点に注意してください。

自分でアクセス権を管理していないリポジトリでは、コミットする前に .cursor フォルダの内容を確認してください。ルールファイルに機密情報を含めないでください。

ルールやコマンドは、チームダッシュボード 上のサーバー経由で管理することもできます。

ワークスペースの信頼

security.workspace.trust.enabled Cherri Code 設定は、Workspace Trust 機能を有効にするかどうかを制御します。この設定はブール値を取り、フル機能が有効になる前にワークスペースを信頼するかどうか、ユーザーに確認するプロンプトを表示するかどうかを決定します。

たとえば、security.workspace.trust.enabled を true に設定するとワークスペース信頼プロンプトが有効になり、false に設定すると機能が完全に無効になります（すべてのワークスペースは自動的に信頼されます）。

ワークスペースの信頼が有効な場合:

• ユーザーは、新しいワークスペースを初めて開くときに、そのワークスペースを信頼するかどうかのプロンプトが表示されます
• 信頼されていないワークスペースは、機能が制限された制限付きモードで実行されます
• 信頼に関する判断は、ワークスペースごとに保存され、記憶されます

組織全体でワークスペースの信頼を一元管理するには、デバイス管理ソリューションを使用して WorkspaceTrustEnabled ポリシーを構成します。このポリシーは、ユーザーのデバイス上の security.workspace.trust.enabled 設定を上書きします。このポリシーの値はブール値（true または false）です。

プラットフォーム別の MDM 構成手順については、Deployment Patterns を参照してください。