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