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