サービス プロジェクトに対するアクセスの管理
[プロジェクト設定] > [カスタマー権限] の順に移動して、サービス プロジェクトでリクエストを登録できるユーザーと顧客がリクエストを共有できるユーザーを選択します。
このページの内容
リクエストを送信できるユーザーの選択
サービス プロジェクトでリクエストを登録するには、顧客になる必要があります。チームが顧客になるユーザーを制御できるようにするか、顧客が自分のアカウントを作成できるようにします。
| リクエストを送信できるユーザー | 説明 |
|---|---|
| プロジェクトに追加されたカスタマー | チームはカスタマーページを通じて、またはカスタマーの代わりにリクエストを出すことによって、カスタマーをプロジェクトに追加します。 |
| Jira サイトにアカウントがあるユーザーは自動的に顧客リストに追加され、リクエストを送信できます。 | |
| 誰でもサービス プロジェクトにメールを送信したり、ポータルでリクエストを登録したりできます。 |
このオプションが無効な場合、Jira 管理者はこの Jira サイトのサービス プロジェクトに対してパブリック サインアップを無効にしています。詳細をご参照ください。 このオプションを選択すると、アカウントを作成してリクエストを登録できるユーザーを制御できなくなります。Jira アカウントの要件がお客様のユース ケースで機能しない場合を除いて、[この Jira サイトにアカウントがある顧客] オプションを代用することを強くお勧めします。 |
リクエストを共有できるカスタマーの選択
顧客が組織、サービス プロジェクト内のユーザー、またはまだ顧客になっていないユーザーとリクエストを共有できるように設定できます。顧客がリクエストを共有するユーザーは、そのリクエストの参加者になります。リクエスト参加者は、リクエストにコメント、リクエストを共有、報告者と同じ通知を Jira Service Management から受信できます。リクエスト参加者の詳細についてご確認ください。
次の表は、カスタマーがリクエストを共有できる方法の説明です。
| カスタマーが共有できるユーザー | 説明 |
|---|---|
| 組織内の他のカスタマー |
|
| メールアドレスを知っている相手 | 顧客は組織にいる他の顧客とリクエストを共有できます (上記のオプションと同様)。また、次のことを行えます。
|
| このプロジェクト内で検索されるカスタマーまたは組織 |
サービス プロジェクトで承認者フィールドなどのユーザー ピッカー カスタム フィールドを使用する場合は、この設定を選択して顧客がユーザーを選択できるようにしてください。 |
チームに最適な設定の選択
チームに権限を設定する方法が不明ですか? 以下にカスタマー権限を効果的に設定する方法について、いくつか提案を示します。
| 状況 | リクエストを送信できるユーザー | カスタマーが共有できるユーザー |
|---|---|---|
| You have a service project that handles contractors' leave requests. Only contractors can use the service project, and you don't want non-contractors don't get confused about where to request leave. | プロジェクトに追加されたカスタマー | 組織内の他のカスタマー |
| 会社に IT サービスデスクがあり、全従業員が自分自身のアカウントを作成してリクエストをメールで送信できるようにしたい。 | この Jira サイトにアカウントがあるカスタマー | このプロジェクト内で検索されるカスタマーまたは組織 |
| チームは個人向けにソフトウェア サポートを行っている。たとえば、個人が財務管理に使用する無料の SAAS アプリケーションを企業が作成する場合は、顧客がバグや質問をメールでサービス プロジェクトのメール チャンネルに送信できるようにできます。 | 誰でもサービス プロジェクトにメールを送信したり、ポータルでリクエストを登録したりできます。 | メールアドレスを知っている相手 |
セキュリティ勧告: リクエストを登録できるユーザーの選択
これは、リクエストを登録できるユーザーのオプションに関するセキュリティ勧告です。
誰でもリクエストを作成して登録できるようにする際は、受信メール アカウント用に別のドメインを使用して、"no-reply"、"support"、"servicedesk" などのローカル パートを含むアドレスをブロックすることで自動メールを絞り込むようにこのアカウントを設定することを、強くお勧めします。
理由
会社レベルのドメインを持つ受信メール アドレスによって Jira Service Management インスタンスを設定すると、悪意のあるユーザーがシステムを悪用して制限されたサービスにアクセスする可能性があります。
例
たとえば、ドメインが http://mycompany.com で、受信メール support@mycompany.com によってカスタマー ポータルを設定して、誰でもリクエストを作成して登録できるようにしたとします。ここで、悪意のあるユーザーが teamsinspace.com にアクセスしようとしており、会社にはこのドメインのアカウントがすでに存在するとします (例: admin@mycompany.com)。
悪意のあるユーザーがカスタマー ポータルで新しいチケットを作成して no-reply@teamsinspace.com を参加者として追加した場合、そのユーザーは teamsinspace.com にアクセスして support@mycompany.com のアカウントを開設し、チケット番号を含むチーム名を指定できます。teamsinspace.com ではその確認メールにチーム名が含まれているため (他の Web サイトには他の詳細情報が含まれている可能性があります)、このようなメールが Jira Service Management の受信メール アドレスに送信されて、コメントとしてチケットに追加されます。確認メールをクリックすることで、悪意のあるユーザーは会社に代わって teamsinspace.com にアカウントを開設できます。
この課題の軽減
カスタマー ポータル専用の別のドメインまたはサブドメインによって、そのドメインを使用するサービスにサインアップしない限りこれを防げます。さらに、受信メール アカウント レベルで自動メール ("no-reply" など) に対するフィルターを追加すると返信不可メールがブロックされるため、課題をさらに軽減できます。