開発と課題管理のツールとの連携

ソフトウェアを開発する組織では、コードの変更がレビューされ、承認されているかが、変更管理のコントロールの中心になります。また、セキュリティーの課題が優先順位を付けて追跡されているかも問われます。このページでは、GitHubなどのバージョン管理とJiraなどの課題管理のツールとの連携として、変更管理のテストに使われる情報、リポジトリーの選び方、チケットを証跡にする方法を説明します。

連携で使われる情報

種類	主な連携先	Drataが確かめること
バージョン管理（Version control）	GitHub、GitHub Enterprise Server、GitLab、Bitbucket、Azure Repos、AWS CodeCommitなど	既定のブランチへのマージにレビューが必須か、コードを変更できるのが許可された社員だけか、アカウントが要員に対応しているか、多要素認証、退職者のアカウントの削除
課題管理（Ticketing）	Jira、Asana、Azure Boards、ClickUp、GitHub Issues、GitLab Issues、Linear、ServiceNow、Shortcut、Trelloなど	セキュリティーの課題のチケットに、担当者と優先度が付いているか

バージョン管理の連携を使う主なテストは次の通りです。

テスト	確かめること
Formal Code Review Process	対象のリポジトリーのブランチの設定で、マージの前にほかの人のレビューが必須になっているか
Only Authorized Employees Change Code	コードを変更できるアカウントが、許可された社員のものか
Production Code Changes Restricted	本番のコードへの変更が制限されているか

課題管理の連携は、テストのほかに、コントロールやテストからのチケットの作成と、チケットを証跡にする操作にも使います。Jiraとの連携では、Jiraのチケットの自動作成にも使います。

GitHubとの連携

GitHubとの連携は、ConnectionsのAvailableタブでGitHubを選び、組織のGitHubのアカウントにDrataのGitHub Appを入れて始めます。GitHub Appを入れる権限が必要です。

【注意】 DrataのGitHub Appは、個人のGitHubのアカウントには入れないでください。組織のアカウントに入れます。

GitHub Appに与える権限は、全て読み取りです。リポジトリーのAdministration、Code scanning alerts、Dependabot alerts、Metadata、組織のMembers、アカウントのEmail addressesです。

リポジトリーの選び方

ヘルプセンターでは、GitHub Appに全てのリポジトリーの読み取りを許可することを勧めています。今あるリポジトリーと、これから作るリポジトリーの両方が対象になるためです。

監視するリポジトリーを絞りたい場合は、GitHubの組織のSettings → GitHub AppsでDrataのアプリのConfigureを選び、Only select repositoriesで対象のリポジトリーを選びます。

絞ったときに変わること	内容
範囲が絞られるテスト	Formal Code Review Process（ブランチの保護の設定を確かめるテスト）だけ
範囲が絞られないもの	コラボレーターと、組織の全てのリポジトリーでのその権限。Only Authorized Employees Change CodeとProduction Code Changes Restrictedのテストで評価される
新しいリポジトリー	自動では対象にならない。対象にするリポジトリーを、その都度手作業で加える

範囲を変えた後は、Formal Code Review Processのテストを実行し直して結果を確かめます。テストを成功させるには、既定のブランチにブランチの保護のルールを作り、マージの前にプルリクエストを必須にします。GitHubのルールセット（組織とリポジトリーのルールセット）にも対応しています。ルールセットを使う場合は、Drataのアプリに組織のAdministrationの読み取りの権限を与え、対象のブランチに既定のブランチか全てのブランチを選び、必要な承認の数を1以上にします。なお、継承された権限（継承されたブランチの制限など）は、Drataでは読み取れません。

社員のアカウントとメールアドレス

Drataは、毎晩の同期で、GitHubのコラボレーターの公開のメールアドレスとユーザー名を取り込み、要員のメールアドレスと照合します。正しく照合されるように、各社員はGitHubの設定で次のことをします。

1. メールアドレスの設定でKeep my email addresses privateのチェックを外します。
2. プロファイルの設定で、公開するメールアドレスを選びます。

社員が個人のGitHubのアカウントを使うことも認められています。その場合は、仕事のメールアドレスを個人のアカウントに追加して確認を済ませ、通知の設定のCustom routingで、組織の通知の送り先を仕事のメールアドレスにします。

バージョン管理のアカウントを確かめる

ConnectionsのManage accountsのVersion Controlでは、バージョン管理から見つかったアカウントを確かめられます。Drataは名前やメールアドレスで、アカウントを要員に自動で対応付けます。対応付けられなかったアカウントは、手作業で対応付けます。

項目	内容
Write access	そのアカウントがコードを書き込めることが意図通りかを示すチェック
Merge to default branch	そのアカウントが既定のブランチにマージできることが意図通りかを示すチェック
多要素認証	連携先から読み取った状態。Drataでは変えられない
Access revoked	バージョン管理でアカウントを削除しても、Drataからは消えず、アクセスがなくなった日時が記録される

Write accessとMerge to default branchのチェックは、連携先の権限を変えるものではありません。そのアカウントが本来持つべき権限をDrataに示すもので、連携先の実際の権限と食い違うと、関係するテストが失敗します。権限を変えるときは、バージョン管理の側で変えます。アカウントの対応付けは、アカウントと要員の対応付けで説明します。

Jiraとの連携

Jira Cloudとの連携には、Jiraの管理者のアクセスと、アプリを入れて承認する権限が必要です。複数のJira Cloudのアカウントをつなげます。

1. ConnectionsのAvailableタブでJiraを選びます。
2. ワークスペースを選び、Account Aliasに連携の名前を入れます（複数のアカウントをつなぐときに見分けやすくなります）。
3. Sourceで、セキュリティーの課題のチケットの見つけ方を、LabelかJQLから選びます。
4. Drataからチケットを作る場合は、Write Accessを有効にします。後から連携の詳細の画面のSetup DetailsでEditを選び、有効にすることもできます。
5. Jiraに移り、求められた権限（view:jira-user、view:jira-work、update:jira-work）を許可します。

セキュリティーの課題の見つけ方

Security Issues are Prioritizedのテストは、Sourceの設定で見つかったセキュリティーの課題のチケットそれぞれに、担当者と、Jira本来のPriorityの項目が入っているかを確かめます。どちらかがないチケットがあると失敗します。

方法	向く場面	動き
Label	セキュリティーの課題に付ける目印を1つに決めて、簡単に運用したい	入れた文字列と一致するラベルを探し、なければ同じ名前のコンポーネント、カスタムフィールドの順に探す
JQL	プロジェクト、課題の種類、カスタムフィールドなどで、細かく絞りたい	入れたJQLの結果をそのまま使う。JQLには課題の種類の条件を含める

【注意】 DrataはJQLの正しさを確かめません。JQLが誤っていたり、条件が厳しすぎたりしてチケットが1件も見つからないと、失敗するチケットがないため、テストは成功になります。JQLはJiraの検索の画面で、想定通りのチケットが返ることを確かめてから入れてください。LabelとJQLの切り替えは、24時間以内の次のAutopilotの実行から反映され、それまでの証跡は消えません。

Jiraのチケットの自動作成

チケットの自動作成は、Jiraとの連携だけで使える機能です。Jira Cloudでは、条件に合う出来事が起きたときに、Jiraのチケットを自動で作れます。Jiraのチケットの自動作成のルールはSettingsのTicket Automationで作ります。ルールを作れるのはAdminとDevOps Engineerのロールのユーザーで、Jiraとの連携でWrite Accessを有効にしておきます。

Jiraとの連携の詳細の画面。Setup Detailsに、Drataからチケットを作るための書き込みの切り替えがある

設定	内容
きっかけの出来事	コントロールの準備状況がNot Readyになった、テストの結果がFailedになった、テストの結果がErrorになった、のいずれか。保存した後は変えられず、変えるときはルールを作り直す
絞り込み	Jiraのチケットを作る対象を絞る。コントロールの場合は、モニタリングの状態、証跡の要否、コントロールオーナー、フレームワーク。テストの場合は、テストのカテゴリー
テストの種類	インフラストラクチャーのカテゴリーでは、本番環境のテスト、コードベースのテスト、その両方から選べる。ほかのカテゴリーは本番環境のテストだけ
チケットの作成先	Jiraのプロジェクトや課題の種類など、Jiraの設定に応じた必須の項目

Jiraのチケットの自動作成のルールは毎晩実行され、条件に合う出来事ごとにJiraのチケットを作ります。同じ出来事について、自動のJiraのチケットが重ねて作られることはありません。複数のワークスペースでJiraをつないでいる場合、Jiraのチケットの自動作成のルールはワークスペースごとに作れますが、実行には主ワークスペースのデータが使われます。チケットの作り方と運用は、チケットの作成と連携で説明します。

チケットを証跡にする

監査人に作業の記録を示すために、完了したJiraのチケットを証跡にできます。是正、調査、承認などの作業をJiraで管理している場合に役立ちます。証跡にできるのは、Admin、Information Security Lead、Workspace Manager、Control Managerのロールのユーザーです。

条件	内容
連携	チケットが、DrataにつないだJiraのアカウントのものであること
チケットの状態	チケットが完了していること
添付ファイル	25MB未満であること

チケットの証跡は、次の手順で作ります。

1. Compliance → Evidenceを開きます。
2. Create evidenceを選びます。
3. 証跡の名前と説明を入れます。
4. 取得元でTicketing providerを選び、JiraのチケットのURL（https://your-domain.atlassian.net/browse/PROJ-123の形）を入れます。
5. 作成日、更新期限、オーナーを入れます。
6. 必要に応じて、Link controlで証跡を1つ以上のコントロールにマッピングします。
7. Saveを選びます。

更新期限は、マッピングしたコントロールが準備完了のままでいられるかに影響します。

作ったチケットの証跡は、EvidenceページのSourceのフィルターでTicketに絞ると探せます。証跡を開くと、Current artifactで日付の更新やチケットを開く操作ができ、チケットのPDFと添付ファイルをまとめたZIPファイルをダウンロードできます。以前の版は、Past artifactsタブに並びます。証跡の作り方はアーティファクトの登録と更新、マッピングは証跡とコントロールのマッピングで説明します。