JIRA: Data protection by design and by default
GDPR の第 25 条は、データ保護バイ デザイン・デフォルトの原則を定めています。これは広義的な原則であり、状況や処理対象の個人データのタイプに応じて意味や用途が異なります。この原則は各組織に対して固有であり、順守に必要となる対応内容を判断する際には弁護士に相談することをおすすめします。このような対応の例として、個人データの処理に使用する特定のサードパーティ アプリケーションが、個人データの入力時にプライバシーに配慮した既定設定になっているか、などが考えられます。以下は、特定のアトラシアン製品で利用できる、関連する設定および構成の概要と、制限事項についての説明です。
The following document describes how user Personal Data (PD) may be accessible in JIRA by the individual, JIRA administrators, authenticated users, and non-authenticated users (if the JIRA instance is publicly accessible).
There can be multiple sources of PD in JIRA, such as a user profile, issues/comments etc. For a more comprehensive list please refer to JIRA: Right to erasure
The information on this page relates to JIRA Core and JIRA Software 7.0 and later, and JIRA Service Desk 3.0 and later.
JIRA can operate in two modes:
- Private - Only administrators can provide new users with access to an instance.
- Public - Anyone can access the instance upon sign up.
Public means that anyone can sign-up and create an account, and by doing so they potentially gain the ability to browse user profiles, depending on how the JIRA permission schemes are set. To check and/or disable public mode, follow this guide: Configuring Jira application options.
Access for "Anyone" group
JIRA can be configured in such way that "Anyone" can access and browse issues and projects, and create issues with the browse user permission (which means they can see a list of the current JIRA users). An administrator would need to check for any occurrence of a permission granted to the "Anyone" group. Review the following documentation for more information on:
- Global permissions - Managing global permissions
- Permission schemes - Configuring permissions
- Permission schemes REST API - API docs
Similar to the "Anyone" group described above, a filter can be shared with publicly when the filter owner decides to add a share of "Public". This means the filter is available to users who are not logged in, and is accessible publicly. For more information on public filters, review this guide: Anonymous users able to see shared filters dashboards or project issues.
JIRA is extremely flexible and has a large ecosystem of integrations provided by third party vendors. JIRA administrator may need to pin-point any plugins, add-ons or integrations that are processing PD or can disclose PD to other systems, for example:
- Webhooks - any information regarding an issue (including PD) can be sent in the webhook request, you should check how the recipient of this information is processing it.
- Plugins and add-ons - think about any integrations on the instance e.g. the HipChat plugin may be displaying some issue information (possibly containing PD) to some HipChat rooms.
- Workflow post-functions, custom scripts, any sort of additional functionality set up to automatically send information elsewhere.
There is currently no way to automatically list these areas.
Users have little control over the emails that they're sent by JIRA, or that they generate to other users as a result of their actions, for example adding a comment to an issue, or transitioning an issue between statuses. JIRA administrators have full control over the notification schemes, which control notifications and emails, and for more information on notification schemes, review this guide: Configuring email notifications.
Restrict viewing profiles
There is no way to restrict a user who is logged in from viewing another user's profile and the information it contains.
The JIRA administrator may:
- Restrict a user's email address from being displayed on the profile page by using the global property "User email visibility": Configuring Jira application options
- Disable the "Details" web panel on a user's profile page, however the display name and avatar will still be displayed in the page header. This can be done by navigating to the "Atlassian JIRA - Plugins - User Profile Plugin" on your Add-ons page, and disabling it's "custom-user-details" module. This will also remove the user's ability to edit their own profile if you're using JIRA's internal user management.
Restrict viewing issues
JIRA administrators can restrict access to JIRA issues and their associated data by assigning proper permissions to users/groups:
In addition to permission schemes, issue-level security can be set up to further restrict access to some issues:
Restrict viewing project data
Project administrators can:
- control access to project details view (along with some global entities)
- maintain components/versions for project
- assign users to project roles
The process of revoking the "Administer project" permission can depend on the configuration of the permission scheme used by project, but it's usually performed through project roles.
Disable the history tab
The Issue history tab can contain information about changes on an issues fields and custom fields, and these changes can contain PD. For information on how to disable this tab, please review How to hide the "History" tab in the issue panel.
JIRA Service Desk specific information
User profiles in JIRA Service Desk are stored and categorised by JIRA, and can be split across two roles:
- Customers / Help Seekers - During customer creation, a user is created in JIRA with customer privileges.
- Agents - During agent creation, a user is created and then elevated to agent.
By design, project administrators can restrict share and manager fields to their organisation in JIRA Service Desk project settings. For more information, review this guide: Set up customer permissions.
There are several areas in JIRA Service Desk that may contain PD if it's been inadvertently added in the form of free text. These areas are:
Queues are essentially JQL searches. The queue name or the JQL search could contain personal data. Queues are set up and maintained by project administrators, and can be viewed by agents and JIRA users, but not by customers.
Access to SLA data is restricted based on the user's roles/permission level. By default, only project admins can configure SLAs and Calendars. If there is any personal data in the text fields, this will be viewable by agents. Project administrators are also allowed to import SLAs from another project, and if there is any personal data in the original SLA, the information will be imported to the new SLA.
Request types have various text fields where customers and agents can add personal data. Request types are configured by JIRA administrators and project administrators, and the configuration could contain PD if it's added.
Invite and General Emails
Email content and data is stored for email batching and sending emails to customers. Sent emails are purged after 30 days. There are free text fields that may contain PD in notification templates and emails stored. When a user is invited to JIRA, we store the email address of the invited user and the username of inviter. The username of a user that changes the supported language for translated customer notifications is also stored.
There are some free text fields such as name, description, comment contains matcher etc. that can contain personal data. Only project administrators can see the usernames/emails of users involved in automation rules. The user doesn't have control over their PD if it's used in automation modules.
Canned responses are not available for customer use, only for agent and project administrator use. However, once a Canned Response is used by adding it to a comment, it is treated as any other comment content and can be viewed by any user who has access to comments. An agent who creates a Canned Response doesn't have any control over who can see that Canned Response since it is automatically available to all agents. There is no permission schema in place for Canned Responses.
Access to the approver list is automatically given to anyone who has access to a request, both on the agent view and the customer portal. It is not possible to restrict access to the approvers list, other than restricting access to the request itself.
Knowledge Base integration with Confluence
By design, JIRA Service Desk preserves the permission or restriction level of Confluence pages. When an anonymous or unlicensed user from the customer portal views a knowledge base article hosted in Confluence, and if the proper permissions are in place, the user profile macro will not be rendered. Actual data about the article (title, content, author) is stored in Confluence.
Project administrators are the only type of user that has access to fields that may potentially hold PD. There is no way to restrict access to a specific user's personal data since data is stored in a non-structured way/free text form.
- There is no functionality that allows restricting access to a single profile.
上記に関連する GDPR 回避策は、本製品の最新バージョン用に最適化されていることにご注意ください。製品のレガシー バージョンを実行している場合、回避策の効果は限定的である可能性があります。この記事で案内されている回避策を最適化するには、最新の製品バージョンにアップグレードすることを検討してください。
GDPR コンプライアンスへの取り組みに関する上記の記事は、アトラシアンのサーバーおよびデータセンター製品内に保存されている個人データのみを対象としています。サーバーまたはデータセンター環境にサードパーティ製アドオンをインストールしている場合、お客様のサーバーまたはデータセンター環境でアクセス、転送、または処理する可能性がある個人データと GDPR コンプライアンスへの取り組みについて、サードパーティのアドオン プロバイダにお問い合わせください。
サーバーまたはデータ センターのお客様の場合、アトラシアンはお客様が製品内で保存するように選択した個人データへのアクセス、保管、または処理は行いません。アトラシアンが処理する個人データの詳細については、プライバシー ポリシーを参照してください。