サービス プロジェクトに対するアクセスの管理
[プロジェクト設定] > [カスタマー権限] の順に移動して、サービス デスクでリクエストを登録できるユーザーと、カスタマーがリクエストを共有できるユーザーを選択します。
このページの内容
リクエストを送信できるユーザーの選択
サービスデスクでリクエストを送信するには、カスタマーになる必要があります。チームがカスタマーになるユーザーを制御できるようにするか、カスタマーがサービスデスクでアカウントを作成できるようにします。
| リクエストを送信できるユーザー | 説明 |
|---|---|
| プロジェクトに追加されたカスタマー | チームはカスタマーページを通じて、またはカスタマーの代わりにリクエストを出すことによって、カスタマーをプロジェクトに追加します。 |
| Jira サイトにアカウントがあるユーザーは自動的に顧客リストに追加され、リクエストを送信できます。 | |
| 誰でもサービス プロジェクトにメールを送信したり、ポータルでリクエストを登録したりできます。 |
このオプションが無効になっている場合は、Jira 管理者がこの Jira サイトのサービス デスクへのパブリック サインアップを有効化していません。パブリック サインアップを有効化する方法をご確認ください。 このオプションを選択すると、アカウントを作成してリクエストを登録できるユーザーを管理できなくなります。Jira アカウントの要件がお客様のユース ケースで機能しない場合を除いて、 [この Jira サイトにアカウントがあるカスタマー] オプションを代わりに使用することを強くお勧めします。 |
リクエストを共有できるカスタマーの選択
カスタマーが、組織、サービス デスクのユーザー、またはまだカスタマーになっていないユーザーとリクエストを共有できるように設定できます。カスタマーがリクエストを共有するユーザーがリクエストの参加者になります。リクエスト参加者は、リクエストのコメントや共有ができ、Jira Service Desk から報告者と同じ通知を受け取ります。リクエスト参加者の詳細についてはこちらをご確認ください。
次の表は、カスタマーがリクエストを共有できる方法の説明です。
| カスタマーが共有できるユーザー | 説明 |
|---|---|
| 組織内の他のカスタマー |
|
| メールアドレスを知っている相手 | 顧客は組織にいる他の顧客とリクエストを共有できます (上記のオプションと同様)。また、次のことを行えます。
|
| このプロジェクト内で検索されるカスタマーまたは組織 |
サービス プロジェクトで承認者フィールドなどのユーザー ピッカー カスタム フィールドを使用する場合は、この設定を選択して顧客がユーザーを選択できるようにしてください。 |
リクエストに投票できる顧客の選択
顧客がカスタマー ポータルでリクエストに直接投票できるようにできます。これによって、Jira インスタンスにユーザー アカウントは不要で、完了を確認するリクエストに投票できます。
ポータルで投票を有効にするには、Jira インスタンスでグローバル投票を有効にする必要があります。
次の表に、この設定のさまざまなオプションを示します。
| 顧客はポータルで投票できるか? | 説明 |
|---|---|
| はい。ポータルへのアクセス権を持つすべての顧客がポータルで直接投票できます。 | 顧客がポータルでリクエストを表示すると、投票するための追加オプションが表示されます。その後、投票を追加または削除できます。
|
| いいえ、顧客はポータルで直接投票できません。 | グローバル投票が有効になっている場合、Jira インスタンスにアカウントを持つユーザーは Jira でリクエストを直接表示すれば、リクエストに引き続き投票できます。顧客はこのようなアカウントを持っていない可能性があるため、このオプションによって事実上投票はエージェントだけに制限されます。 |
チームに最適な設定の選択
チームに権限を設定する方法が不明ですか? 以下にカスタマー権限を効果的に設定する方法について、いくつか提案を示します。
| 状況 | リクエストを送信できるユーザー | カスタマーが共有できるユーザー | 顧客は投票できるか? |
|---|---|---|---|
| 請負業者の休暇申請を処理するサービス プロジェクトが存在します。請負業者のみがサービス プロジェクトを使用できて、請負業者以外のユーザーが休暇申請の提出先について混乱しないようにしたいです。 | プロジェクトに追加されたカスタマー | 組織内の他のカスタマー | いいえ。ほとんどの場合、請負業者は休暇申請を投票不要です。 |
| 会社に 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" など) に対するフィルターを追加すると返信不可メールがブロックされるため、課題をさらに軽減できます。