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

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

このページの内容

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

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

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

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

このオプションを選択すると、アカウントを作成してリクエストを登録できるユーザーを制御できなくなります。Jira アカウントの要件がお客様のユース ケースで機能しない場合を除いて、[この Jira サイトにアカウントがある顧客] オプションを代用することを強くお勧めします。

セキュリティに関するアドバイスの続きを読む

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

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

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

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

顧客は組織にいる他の顧客とリクエストを共有できます (上記のオプションと同様)。また、次のことを行えます。

  • サービス プロジェクト内のいずれかのユーザーとリクエストを共有できます (相手のメール アドレスを知っている場合)
  • If anyone can email the service project or raise a request in the portal, then customers can also share requests with people who aren’t customers yet. They can provide email addresses of these people and Jira will create accounts for them. Such unregistered email addresses can only be entered in the Share this request or Raise this request on behalf of fields, but not regular user picker fields.
このプロジェクト内で検索されるカスタマーまたは組織
  • カスタマーはプロジェクト内の誰とでもリクエストを共有できます。サービス デスクを検索して共有相手を見つけることもできます。
  • If anyone can email the service project or raise a request in the portal, then customers can also share requests with people who aren’t customers yet. They can provide email addresses of these people and Jira will create accounts for them. Such unregistered email addresses can only be entered in the Share this request or Raise this request on behalf of fields, but not regular user picker fields.

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

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

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

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

セキュリティ勧告: リクエストを登録できるユーザーの選択

これは、リクエストを登録できるユーザーのオプションに関するセキュリティ勧告です。

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.

この課題の軽減

カスタマー ポータル専用の別のドメインまたはサブドメインによって、そのドメインを使用するサービスにサインアップしない限りこれを防げます。さらに、受信メール アカウント レベルで自動メール ("no-reply" など) に対するフィルターを追加すると返信不可メールがブロックされるため、課題をさらに軽減できます。

最終更新日 2021 年 7 月 19 日

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

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