Jira: Right to erasure
はじめに
GRPR の第 17 条において、個人には個人データの削除権が保証されています。これは、"忘れられる権利" としても知られます。この権利は絶対的なものではなく、特定の状況でのみ適用されます。個人データの削除の削除について、個人の要求に対応するために必要となる妥当な対応の範囲は場合によって異なるため、弁護士に相談することをおすすめします。個人データの削除義務があると判断された場合は、特定のアトラシアン製品内でこれを実行するための方法について、以降の手順をご確認ください。
製品に保存される個人データは、1) アカウントレベルの個人データと 2) フリーフォーム テキスト形式の個人データに区別されます。アカウントレベルの個人データとは、製品内に存在し、製品で各ユーザーを区別するためにのみ使用されるデータ フィールドです。アカウントレベルの個人データの例には、ユーザーの表示名、プロファイル画像またはアバター、メール アドレスが含まれます。これらのデータ要素は通常ユーザーのプロファイル内で確認でき、スペースやコンテンツ内でユーザーが @メンションやタグ付けされた場合にプロフィールを参照できるようにするため、製品全体で使用されます。構造化された個人データ要素を削除すると、製品内で関連する構造化データ要素が表示される箇所やデータベース (後述の制限事項を参照) からデータ要素が取り除かれます。
フリーフォームのテキスト形式で個人データを追加していた場合 (コンテンツのスペースへの入力やカスタム フィールドのラベル名など)、製品のグローバル検索機能を使ってこのような個人データを検出し、個別に削除する必要があります。
説明
Personal Data (PD) for a specific user can be spread across multiple components of Jira. We've detailed these components and areas in the Jira: Right of access by the data subject article. In this article, we'll describe how to remove personal data for a specific user, if required. Depending on your Jira version, you can either do it directly from Jira or use workarounds, that is run SQL scripts on your database. We strongly recommend you stop Jira to run these scripts, which will result in downtime for your Jira instance.
バージョンの互換性
- Anonymizing users directly in Jira (recommended)
Jira Core and Jira Software 8.7 and later, and Jira Service Desk 4.7 and later. - Using workarounds and running SQL scripts on your database
Jira Core and Jira Software 7.0 and later, and Jira Service Desk 3.0 and later.
Some SQL statements are only available for certain products or versions, e.g. Jira Software or Jira Service Desk 3.5 onwards. These limitations are documented in comments inside the SQL scripts, before each table.
Removing personal data
Anonymizing users in Jira
Anonymizing users in Jira allows you to hide or delete any data that can identify them as a real person. This includes names, usernames, avatars, personal settings, and any occurrences of those around Jira. For more info on what the user anonymization looks like and what exactly gets anonymized, see Anonymizing users.
Using workarounds and running SQL scripts on your database
As with all recommendations and workarounds, you should test and validate these processes in a test environment prior to rolling them to your production environment.
概要
This section contains a high-level overview of the process required to remove personal data from a Jira instance. Specific instructions on how to remove personal data from a Jira instance are covered in the next section.
Deleting or modifying PD
Deleting and modifying user PD is virtually the same process. This is because we don't recommend fully deleting a user account from Jira. User accounts are an integral part of the Jira data structure and critical for maintaining data consistency on your system.
Rather than deleting the data, we recommend modifying PD elements in the account to replace PD with data elements that do not identify the user. For example, replacing the username "johnsmith" with "deleteduser1". This way the system will be able to function correctly while allowing you to "delete" profile-level PD that may otherwise identify the user. You can also use this process if you want to modify a user's PD - for example, if "nicholassmith" is known as "nicksmith."
Modifying user PD - high-level overview
Modifying user PD has to be performed in several steps, depending on where the data is stored. Some PD can be modified through the user interface (UI), while other PD has to be modified directly in the database (SQL). We recommend using the UI where possible to avoid the risk of unintentional data modification or deletion. Making changes from within the UI ensures that the Lucene index and Jira caches are updated.
To modify the user data you have perform the following steps (detailed steps are described in the next section):
- Changes you can make in the UI:
- Handling PD in "structured" data fields
- Modify data in the user profile. This depends on the type of user directory Jira is using:
- If Jira is using the internal directory, please read Managing your user profile for information on how to do modify the user profile.
- If Jira is using an external user directory, you will need to follow the instructions for the external user directory to update the profile, and then Synchronizing the data with Jira.
- Remove a user's avatar in their user profile
- Modify data in the user profile. This depends on the type of user directory Jira is using:
- Handling PD in "free-form text" data fields that are JQL searchable (issue-related)
- Handling PD in "structured" data fields
- Changes that require SQL update statements (SQL update statements must be executed against a Jira instance which has been stopped):
- Optional modification of "user_key" - only if "user_key" contains PD.
- Handle PD in "free-form text" data fields that are not JQL searchable (non issue-related)
- After change actions (only if SQL update statements were executed)
- Reindex Jira
Process to remove personal data from a Jira instance
Step 1 - (UI) Handling PD in "structured" data fields in the user profile
This step depends on the configuration of Jira. You can manage users within Jira by using "Internal user directory" or user management can be performed in an "External user directory". More information on user directories can be found on this page: Configuring user directories.
The procedure for modifying personal data depends on which kind of directory Jira uses for a specific user.
You must have the Jira Administrator or Jira System Administrator global permission to be able to manage users in Jira applications. To find out which kind of directory is used for specific user perform following steps:
- Select > User Management.
- ページの一番上にあるフィルターを使用してユーザー一覧からユーザーを探します。
- Check the Directory column in the table, it will contain the directory used to manage the user. This should tell you whether you're using an internal or external user management system.
- Click on the user's Full name in the "Full name" column. Take a note of the following details for later use:
- ユーザ名
- 氏名
- メール
Obtain the user_key for the specific user and check if it contains PD. You have to use the username obtained from the user profile in the previous step.
On Windows, you should have CURL installed, use this or find another way to call the REST API or use the SQL query.
Using Jira's REST API to obtain the "key" value from the response:
curl -u admin:admin http://localhost:2990/Jira/rest/api/latest/user?username=example_username { "self":"http://localhost:2990/Jira/rest/api/2/user?username=example_username", "key":"user_key", "name":"example_username", "emailAddress":"johndoe@example.com", "avatarUrls":{"48x48":"","16x16":""}, "displayName":"John Doe", "active":true, "timeZone":"Australia/Sydney", "locale":"en_AU", "groups":{"size":2,"items":[]}, "applicationRoles":{"size":2,"items":[]}, "expand":"groups,applicationRoles" } In this example user key has value "user_key"
Using a SQL query (replace [username] with the user name we are looking for)
select user_key from app_user where lower_user_name = LOWER('[username]')
Once you have determined the type of directory and you have obtained the PD from the user profile, you can proceed with the next steps.
External user directory
These steps should be performed if your Jira instance uses an external user directory.
There are 2 options that you can take to remove a user's PD, either modify the details to something anonymous, or delete the user completely:
- Modify the user's PD in the external directory:
- Modify the user's PD and disable their user account in the external directory.
- Synchronize the external directory with Jira.
- Delete the user's PD from an external directory
- Follow the steps from Modify the user's PD in the external directory above. Right now user data in Jira should be updated (synchronised) with the data from external directory, and user account should be inactive.
- Find and delete the user from the external directory.
- Synchronize the external directory with Jira.
- At this point 2 things can happen:
- If the user has not created any issues, and they're not the reporter, creator or assignee of any issues, then they will be deleted and removed from the user list.
- If the user has at least one comment or there is at least one issue that user is reporter/creator/assignee, then the user will be deactivated.
External user directory with delegated authentication
These steps should be performed if the user resides with an external user directory with delegated authentication.
- Disable or delete the user in the external directory.
- Follow the steps from Internal user directory below.
内部ユーザー ディレクトリ
These steps should be performed if the user resides within an internal user directory.
Remove user avatar
Jira allows users to upload avatars (to be used in profile page and displayed on view issue page). An avatar may contain PD (eg. user photo).
Step 2 - (UI) Handling PD in "free-form text" data fields that are JQL searchable (issue-related)
Personal data can be stored in Jira issues or entities associated with issues e.g. comments, worklogs etc. Jira allows free-text searching (using JQL - Jira Query Language see: Searching for issues ) in issues and entities associated with issues (issue fields, comments, worklogs, text-searchable custom fields).
JQL searching can be used to search for PD stored in issues. We'll use the "text" field to perform searching as it searches through Summary, Description, Environment, Comments, Worklogs, and custom fields that use "free text searcher". Read more on Advanced searching. If personal data on your instance is stored in fields that are not handled by a "text" field, then you need to alter the JQL query to search in those additional fields.
重要な注意事項
- You will only get search results for entities you have the right to view. Make sure you have full admin rights if you want to search for all instances of PD.
- There may be some fields you don't have access to. If "none" is selected for custom field Search Templates, then JQL searching will omit this field. Such fields have limited processing and nobody will be able to perform the search by this field's value.
- PD stored in archived projects and issues is not searchable by JQL (unless you choose to restore a project). You can search for this data by using SQL statements, as described in Step 3 - Changes that require SQL update statements.
- To go to the issue search and search for sensitive data, choose Issues > Search for issues.
- Click Advanced.
- Enter your JQL: "text ~ 'clause to search'" and click search. This will search in: comments, description, summary, environment, worklogs + text searchable custom fields.
- Individually modify all comments/summary/description/issue fields/worklogs/custom fields returned in your results.
Step 3 - (SQL) Changes that require SQL update statements (these are not possible in the UI):
Always back up your data before performing any modifications to the database. If possible, test any change, insert, update, or delete SQL commands on a staging server first.
This step consists of several sub-steps:
- Stop you Jira instance - to avoid mismatch (data loss/inconsistencies/corruption) between DB and caches used by Jira
(Optional) Modifying user_key - perform only when user_key contains PD.
Handle PD "free-form text" data fields that are not JQL searchable - deals with free text data stored in entities that are non JQL searchable.
- Start the Jira instance - this will ensure that the database modified values are properly loaded into Jira caches
Stop your Jira instance
This step is required because Jira caches a lot of data and updating the database directly when Jira is still working could cause data loss, inconsistencies or corruption.
See: Start and Stop Jira applications.
Modifying user_key - (Optional - only when user_key is PD)
Jira uses the user_key (database table app_user column user_key) internally as a foreign key in other entities eg. Jira issue, issue comment, default assignee etc.
A user_key may contain personal data (e.g. the user key could contain the first and last name of a user).
Because the user_key is immutable in Jira, and changing the username for a Jira user will not change it's user_key, SQL queries have to be performed to change the user_key that is used as foreign key in other database entities.
If you use 3rd party add-ons that rely on the user_key, modifying the user_key could cause the add-on to break.
Handle PD "free-form text" data fields that are not JQL searchable
Only data associated with issues can be searched for in Jira using JQL queries, but personal data could also be stored in other entities within Jira (eg. statuses, resolutions, schemes, workflows, screens, archived projects, etc.). In order to search all potential places that personal data could be stored, you need to run a SQL query against the database.
Start your Jira instance
Start the Jira instance - this will ensure that the database modified values are properly loaded into the caches.
See: Start and Stop Jira applications
Step 4 - Follow up actions (only if SQL update statements were executed)
Jira stores certain data in a Lucene inverted-index to make JQL searching possible, so if the SQL update statements were executed you now need to re-index Jira in order to remove stale data from the index.
Scripts to query and/or update project and component lead
A user can be assigned as a project or component lead, and as such you may need to find and/or update these details. User account can't be deactivated if the user is a project or component lead.
The following scripts can be used to query and update the project and component leads in Jira so user account can be safely deactivated.
Python3 script used for querying/updating leads of projects.
This script is just a proof of concept, and is not supported by Atlassian.
Python3 script used for querying/updating leads of components
This script is just a proof of concept, and is not supported by Atlassian.
制限事項
General Limitations
SQL statements are using pattern matching, so they may match records that don't need to be modified. Manual inspection is suggested before each update to ensure you don't modify records that don't need to be modified.
- The History tab might contain sensitive data - it can be erased via an SQL query, or by cloning the existing issue, and then deleting the existing issue completely.
- If "Modifying user_key" was performed be sure to also follow "Handling PD in other entries" step.
Altered user key could be used in eg. workflow post-function (eg. set assignee in post-function) or as custom-field default value (eg. default "manager" in user picker custom fields).
SQL queries from "Handling PD in other entries" step can help you identify those places and update them accordingly.
JQL Limitations
Jira allows searching by various fields eg. status, priority, resolution, issue type, saved filter, component, version, custom field name, labels etc. (Advanced searching - fields reference). All these entities can be referenced in a JQL search which is saved as a filter, and changes to those entities could break existing saved filters:
- filters (Saving your search as a filter)
- filter subscriptions (Working with search results)
- gadgets that use JQL filters of JQL (Adding and customizing gadgets)
- reports (Reporting)
- boards (Configuring filters)
- board swimlanes (Configuring swimlanes)
- board quick-filters (Configuring Quick Filters)
- possibly other places that rely on saved filters or free-text JQL queries
If you're running Jira Service Desk, then JQL filters can be used in following places:
- Queues (Setting up queues for your team)
- Reports (Setting up service project reports)
- Automation (Automating your service project)
- SLAs (Setting up SLAs)
Database Specific Limitations
- Mysql doesn't have a "REGEXP_REPLACE" function (or any other functions that would work in similar manner), so we're able to find matching records ignoring case, but we're not able to generate sql that will update values in a case-insensitive way. Manual inspection/update is needed in these cases.
- Microsoft SQL Server does not support regular expressions to the extent of other supported databases - records are matched using "LIKE" operator which can match longer substrings. Updates are using a "replace" function which, in conjunction with case insensitive collation, will replace all occurrences case-insensitive to case-sensitive replacement eg. replace("and TEST second as test third", "test", "tESt") = "and tESt second as tESt third".
App Specific Limitations
Jira Service Management
- Insight - Asset Management is an app bundled with Jira Service Management Data Center 4.15 and later. It’s also available for earlier Data Center versions. In some cases, when you anonymize users, their user keys won’t be anonymized in Insight - Asset Management. This affects user keys of users created before Jira Service Management 4.7 (or Jira 8.7). In these versions, user keys look the same as usernames, so some personal data might be visible. Users created in later versions will be fully anonymized, also in Insight - Asset Management. The reason for this difference is that later versions use a different pattern for usernames and user keys, and in this case we’re only able to anonymize the new pattern.
その他の注意事項
お使いの製品バージョンに応じた制約がある可能性があります
上記に関連する GDPR 回避策は、本製品の最新バージョン用に最適化されていることにご注意ください。製品のレガシー バージョンを実行している場合、回避策の効果は限定的である可能性があります。この記事で案内されている回避策を最適化するには、最新の製品バージョンにアップグレードすることを検討してください。
サードパーティ製アドオンは、独自のデータベース テーブルまたはファイルシステム内に個人データを保存する可能性があります。
GDPR コンプライアンスへの取り組みに関する上記の記事は、アトラシアンのサーバーおよびデータセンター製品内に保存されている個人データのみを対象としています。サーバーまたはデータセンター環境にサードパーティ製アドオンをインストールしている場合、お客様のサーバーまたはデータセンター環境でアクセス、転送、または処理する可能性がある個人データと GDPR コンプライアンスへの取り組みについて、サードパーティのアドオン プロバイダにお問い合わせください。
サーバーまたはデータ センターのお客様の場合、アトラシアンはお客様が製品内で保存するように選択した個人データへのアクセス、保管、または処理は行いません。アトラシアンが処理する個人データの詳細については、プライバシー ポリシーを参照してください。