サービスデスクへのアクセスを管理する

プロジェクト設定 > カスタマー権限に進み、サービスデスクでリクエストを送信できるユーザーとカスタマーがリクエストを共有できるユーザーを選択します。

このページの内容

リクエストを送信できるユーザーの選択

サービスデスクでリクエストを送信するには、カスタマーになる必要があります。チームがカスタマーになるユーザーを制御できるようにするか、カスタマーがサービスデスクでアカウントを作成できるようにします。

リクエストを送信できるユーザー説明
プロジェクトに追加されたカスタマーチームはカスタマーページを通じて、またはカスタマーの代わりにリクエストを出すことによって、カスタマーをプロジェクトに追加します。
Jira サイトにアカウントがあるユーザーは自動的に顧客リストに追加され、リクエストを送信できます。
サービスデスクにメール送信可能またはポータルでリクエスト送信可能なユーザー
  • 新規のカスタマーはカスタマーポータル経由でサービスデスクにアカウントを作成できます。
  • 電子メール リクエストにより、送信者のアカウントが自動的に作成されます。
  • カスタマーがリクエストを共有できるようにした場合、リクエストを共有するユーザーもカスタマーになり、リクエストを送信できます。
  • スパムボットによってカスタマー ポータルからアカウントが作成されるのを防ぐため、ハニーポット技術が有効化されています。

 このオプションが無効化されている場合、Jira 管理者はこの Jira サイトのサービス デスクに対してパブリック サインアップを無効化しています。詳細情報 

When you choose this option, you have no control over who can create an account and raise requests. We strongly recommend that you use the Customers who have an account on this Jira site option instead, unless the requirement for a Jira account won’t work for your use case.

Read more in our security advice

リクエストを共有できるカスタマーの選択

カスタマーが組織、サービスデスク内のユーザー、またはまだカスタマーになっていないユーザーとリクエストを共有できるように設定することが可能です。カスタマーがリクエストを共有するユーザーは、そのリクエストの参加者になります。リクエスト参加者はコメントの付加、リクエストの共有、報告者と同じ Jira Service Desk からの通知の受信が可能です。リクエスト参加者について詳細を読む

次の表は、カスタマーがリクエストを共有できる方法の説明です。

カスタマーが共有できるユーザー説明
組織内の他のカスタマー
  • カスタマーは組織とのリクエストの共有、またはプライベートリクエストの送信が可能です。
  • カスタマーは共有する相手を組織内で検索できます。
     
  • 組織外のカスタマーはリクエストを共有できません。
メールアドレスを知っている相手

組織内の他のカスタマーはさらに次のことが可能です。

  • カスタマーはサービスデスクのいずれかのユーザーとリクエストを共有できますが、相手のメールアドレスを知っている場合に限られます。
  • サービスデスクにメールを送信できるか、ポータルでリクエストを送信できる場合、そのカスタマーは、まだカスタマーではないユーザーとリクエストを共有できます。リクエストを共有するユーザーはカスタマーになります。
このプロジェクト内で検索されるカスタマーまたは組織
  • カスタマーはプロジェクト内の誰とでもリクエストを共有できます。サービス デスクを検索して共有相手を見つけることもできます。
  • サービスデスクにメールを送信できるか、ポータルでリクエストを送信できる場合、まだカスタマーではないユーザーとそのリクエストを共有できます。リクエストを共有するユーザーはカスタマーになります。

サービスデスクが承認者フィールドなどのユーザーピッカー カスタムフィールドを使用する場合、この設定を選択してカスタマーがユーザーを選択できるようにしてください。

チームに最適な設定の選択

チームに権限を設定する方法が不明ですか? 以下にカスタマー権限を効果的に設定する方法について、いくつか提案を示します。

状況リクエストを送信できるユーザーカスタマーが共有できるユーザー
請負業者の休暇願いを処理するサービスデスクが存在する。請負業者のみがサービスデスクを使用でき、請負業者以外のユーザーが休暇願いの提出先について混乱することがないようにしたい。 プロジェクトに追加されたカスタマー組織内の他のカスタマー
会社に IT サービスデスクがあり、全従業員が自分自身のアカウントを作成してリクエストをメールで送信できるようにしたい。 この Jira サイトにアカウントがあるカスタマーこのプロジェクト内で検索されるカスタマーまたは組織
チームは個人向けにソフトウェアサポートを行っている。たとえば、個人が財務管理に使用する無料の SAAS アプリケーションを企業が作成する場合、カスタマーがバグや質問をメールでサービスデスクのメールチャンネルに送信できるようにすることが可能。サービスデスクにメール送信可能またはポータルでリクエスト送信可能なユーザーメールアドレスを知っている相手

Security advice: Choosing who can raise requests

This is a security advice regarding the option Who can raise requests.

When allowing anyone to create and raise requests, we strongly recommend that you use a separate domain for your incoming email account and configure this account to filter against automatic emails by blocking the addresses with a local-part, such as “no-reply”, “support”, “servicedesk”, and so on.

理由

Configuring your Jira Service Desk instance using an incoming email address with a domain at your company level can result in bad actors abusing the system to gain access to restricted services.

For example, assume that your domain is http://mycompany.com, and you have set up a customer portal with an incoming email support@mycompany.com, allowing anyone to create and raise requests. Now, let’s say a bad actor is trying to gain access to teamsinspace.com for which your company already has an account (e.g. admin@mycompany.com).

If the bad actor creates a new ticket in your customer portal and adds no-reply@teamsinspace.com as a participant, they can now go to teamsinspace.com and open an account for support@mycompany.com and provide a team name including the ticket number. Since teamsinspace.com includes the team name in their confirmation emails (and other websites might include other details), such an email will be sent to your incoming email address in Jira Service Management, and added as a comment to the ticket. By clicking on the confirmation email, the bad actor could open an account on teamsinspace.com on behalf of your company.

Mitigating this issue

Using a separate domain or sub-domain dedicated for your customer portal will help prevent this as long as you make sure to not sign up to services using that domain. What’s more, adding filters against automatic emails (e.g. “no-reply”) at the incoming email account level will further help mitigate the issue because no-reply emails will be blocked.

最終更新日 2021 年 4 月 30 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.