サービス プロジェクトに対するアクセスの管理

[プロジェクト設定] > [カスタマー権限] の順に移動して、サービス デスクでリクエストを登録できるユーザーと、カスタマーがリクエストを共有できるユーザーを選択します。

このページの内容

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

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

リクエストを送信できるユーザー説明
プロジェクトに追加されたカスタマーチームはカスタマーページを通じて、またはカスタマーの代わりにリクエストを出すことによって、カスタマーをプロジェクトに追加します。
Jira サイトにアカウントがあるユーザーは自動的に顧客リストに追加され、リクエストを送信できます。
誰でもサービス プロジェクトにメールを送信したり、ポータルでリクエストを登録したりできます。
  • 新規カスタマーは、カスタマー ポータルを経由してサービス デスクに自分のアカウントを作成できます

  • メール リクエストを登録すると、送信者のアカウントが自動的に作成されます。

  • カスタマーがリクエストを共有できるようにした場合、リクエストを共有するユーザーもカスタマーになり、リクエストを送信できます。

  • スパムボットがカスタマー ポータルからアカウントを作成するのを防ぐために、ハニーポット技術が有効化されています。

  • Jira 管理者がログイン不要のポータルを有効にしている場合にこのオプションを選択すると、ログインしなくても誰でもポータルにアクセスしてリクエストを登録できます。ログイン不要のポータルに関する詳細をご確認ください。

このオプションが無効になっている場合は、Jira 管理者がこの Jira サイトのサービス デスクへのパブリック サインアップを有効化していません。パブリック サインアップを有効化する方法をご確認ください。

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

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

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

You can allow customers to share requests with their organizations, Jira groups they're part of, anyone in the service desk, or people who aren't customers yet. The people customers share with become participants in the request. Request participants can comment on and share requests, and receive the same notifications from Jira Service Desk as the reporter. Learn more about request participants

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

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

他のカスタマーとのリクエストの共有

メールアドレスを知っている相手

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

  • サービス プロジェクト内のいずれかのユーザーとリクエストを共有できます (相手のメール アドレスを知っている場合)
  • サービス プロジェクトにメールを送信できる、またはポータルでリクエストを登録できる場合、その顧客はまだ顧客はないユーザーとリクエストを共有できます。顧客はこれらのユーザーのメール アドレスを提供することができて、Jira でそのユーザーのアカウントが作成されます。このような未登録のメール アドレスは、[このリクエストを共有] フィールドにのみ入力でき、通常のユーザー ピッカー フィールドには入力できません。
このプロジェクト内で検索されるカスタマーまたは組織
  • 顧客はプロジェクト内の誰とでもリクエストを共有できます。また、サービス プロジェクトを検索して共有相手を見つけられます。
  • サービス プロジェクトにメールを送信できる、またはポータルでリクエストを登録できる場合、その顧客はまだ顧客はないユーザーとリクエストを共有できます。顧客はこれらのユーザーのメール アドレスを提供することができて、Jira でそのユーザーのアカウントが作成されます。このような未登録のメール アドレスは、[このリクエストを共有] フィールドにのみ入力でき、通常のユーザー ピッカー フィールドには入力できません。

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

カスタマーがリクエストをグループと共有できるようにするかどうかの選択

エージェントとプロジェクト管理者は、サービス プロジェクトのカスタマーとして追加された Jira グループを対象に、課題ビューからリクエストを共有できます。プロジェクト管理者は、この共有機能をヘルプ依頼者にまで拡張して、追加の権限管理なしに、カスタマー ポータルで各自が所属している Jira グループとリクエストを共有できるようにすることもできます。 

グループとの共有を許可するには、[カスタマーはリクエストをグループと共有できますか?] の [このプロジェクトに追加されたカスタマー グループとの共有を許可する] チェックボックスを選択します。

リクエストに投票できる顧客の選択

顧客がカスタマー ポータルでリクエストに直接投票できるようにできます。これによって、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" など) に対するフィルターを追加すると返信不可メールがブロックされるため、課題をさらに軽減できます。

最終更新日 2024 年 8 月 8 日

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

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