https://gl-handbook-ja.page/tags/security_standard_cpir/Recent content in Security_standard_cpir on GitLab ハンドブック (非公式日本語訳)HugojaSun, 14 Jun 2026 06:40:47 +0900https://gl-handbook-ja.page/handbook/security/security-operations/sirt/sec-incident-response/Wed, 25 Feb 2026 07:10:33 -0800https://gl-handbook-ja.page/handbook/security/security-operations/sirt/sec-incident-response/<span class="gl-label gl-label-text-light" style=" --label-background-color: #E24329; --label-inset-border: inset 0 0 0 2px #E24329; " > <span class="gl-link gl-label-link"> <span class="gl-label-text"> Visibility: Audit </span> </span> </span> <h2 id="目的">目的<a class="td-heading-self-link" href="#%e7%9b%ae%e7%9a%84" aria-label="Heading self-link"></a></h2> <p><a href="https://gl-handbook-ja.page/handbook/security/security-operations/sirt/">セキュリティインシデントレスポンスチーム (SIRT)</a> は、あらゆるセキュリティインシデントの支援のために <a href="https://gl-handbook-ja.page/handbook/engineering/infrastructure-platforms/incident-management/on-call/#security-team-on-call-rotation">24/7/365</a> のオンコール体制を取っています。緊急のセキュリティインシデントが特定された場合、またはインシデントが発生した可能性があると思われる場合は、<a href="https://gl-handbook-ja.page/handbook/security/security-operations/sirt/engaging-security-on-call/">セキュリティエンジニアオンコールへのエンゲージ</a> を参照し、Slack で自分自身またはパブリック/プライベートチャンネルへの新しいメッセージを書いて <code>/security</code> コマンドを使用してください (このコマンドは Slack のスレッド内では動作しません)。</p> <p>SIRT の責任とインシデントオーナーシップに関する情報は、<a href="https://gl-handbook-ja.page/handbook/security/security-operations/secops-oncall/">SIRT オンコールガイド</a> で確認できます。</p> <h2 id="スコープ">スコープ<a class="td-heading-self-link" href="#%e3%82%b9%e3%82%b3%e3%83%bc%e3%83%97" aria-label="Heading self-link"></a></h2> <h3 id="incident-identification">インシデントの特定<a class="td-heading-self-link" href="#incident-identification" aria-label="Heading self-link"></a></h3> <p>セキュリティインシデント調査は、<a href="https://www.gitlab.com">GitLab.com</a>、その他の GitLab サービス、または GitLab 社の一部としてセキュリティイベントが検知されたときに開始されます。これらの調査は、資格を持つセキュリティチームメンバーによりトリアージされ、トリアージ証拠が明白でリスクのないものであれば誤検知として処理されます。GitLab の顧客、サービス、プロダクト、チームメンバー、サードパーティサービス等に対して潜在的に有害または悪影響を及ぼす可能性があるかどうかについて疑義がある場合、セキュリティチームがインシデントを調査します。</p> <p>インシデントの兆候は、内部の GitLab チームメンバーまたは外部の方から SIRT に <a href="https://gl-handbook-ja.page/handbook/security/#reporting-an-incident">報告</a> できます。セキュリティインシデントの特定および検証に応じて調査をいつ実施するかを判断するのは、セキュリティチームの責任です。</p> <p>GitLab セキュリティチームは、GitLab セキュリティ、利用規約、その他の関連ポリシーの違反または違反の脅威を、セキュリティインシデントとして特定します。</p> <p>SIRT は、サードパーティ侵害を含めて GitLab に重大な影響を及ぼす可能性のあるセキュリティインシデント (個別または合計で重大な侵害となる可能性があるもの) について、<a href="https://internal.gitlab.com/handbook/security/security_operations/sirt/operations/incident_response/material_breach_guidance/material_breach_determination/">Material Breach Determination internal handbook page</a> のプロセスに従います。重大化する可能性のあるインシデントは MNPI (重要非公開情報) として扱います。</p> <h2 id="役割と責任">役割と責任<a class="td-heading-self-link" href="#%e5%bd%b9%e5%89%b2%e3%81%a8%e8%b2%ac%e4%bb%bb" aria-label="Heading self-link"></a></h2> <table> <thead> <tr> <th>役割</th> <th>責任</th> </tr> </thead> <tbody> <tr> <td>GitLab チームメンバー</td> <td>本手続きの要件に従う責任</td> </tr> <tr> <td>SIRT</td> <td>本手続きの実装および実行の責任</td> </tr> <tr> <td>SIRT 経営層 (Code Owners)</td> <td>本手続きの重要な変更および例外の承認の責任</td> </tr> </tbody> </table> <h2 id="手続き">手続き<a class="td-heading-self-link" href="#%e6%89%8b%e7%b6%9a%e3%81%8d" aria-label="Heading self-link"></a></h2> <h3 id="インシデントレスポンスプロセス-本ガイドはすべてのセキュリティインシデントについて以下の活動をカバーします">インシデントレスポンスプロセス: 本ガイドはすべてのセキュリティインシデントについて以下の活動をカバーします<a class="td-heading-self-link" href="#%e3%82%a4%e3%83%b3%e3%82%b7%e3%83%87%e3%83%b3%e3%83%88%e3%83%ac%e3%82%b9%e3%83%9d%e3%83%b3%e3%82%b9%e3%83%97%e3%83%ad%e3%82%bb%e3%82%b9-%e6%9c%ac%e3%82%ac%e3%82%a4%e3%83%89%e3%81%af%e3%81%99%e3%81%b9%e3%81%a6%e3%81%ae%e3%82%bb%e3%82%ad%e3%83%a5%e3%83%aa%e3%83%86%e3%82%a3%e3%82%a4%e3%83%b3%e3%82%b7%e3%83%87%e3%83%b3%e3%83%88%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6%e4%bb%a5%e4%b8%8b%e3%81%ae%e6%b4%bb%e5%8b%95%e3%82%92%e3%82%ab%e3%83%90%e3%83%bc%e3%81%97%e3%81%be%e3%81%99" aria-label="Heading self-link"></a></h3> <ol> <li>検知 <ul> <li>SIRT、その他の社内、または社外のエンティティが、セキュリティ脆弱性または弱点の悪用の可能性、または設定ミスや無意識のエラーの結果と思われるセキュリティまたはプライバシーイベントもしくはリスクを特定する</li> <li>私たちのセキュリティ検知コントロールの 1 つが、確立されたセキュリティベースラインの範囲外のイベントを特定する</li> <li>慎重を期すため、また仮定を検証するために、セキュリティ Issue がインシデントにエスカレーションされる</li> </ul> </li> <li>分析 <ul> <li>SIRT は、報告されたセキュリティまたはプライバシーイベントが実際にセキュリティまたはプライバシーイベントであるかを判断する</li> <li>SIRT は以下の <a href="https://gl-handbook-ja.page/handbook/security/security-operations/sirt/severity-matrix/">インシデント分類</a> 方法論に基づいてインシデントの重大度と優先度を判断する</li> </ul> </li> <li>封じ込め <ul> <li>影響を受けたシステムまたはデータの不正使用または悪意のある使用の拡散を防ぐ</li> <li>インシデントの根本原因を軽減し、最終的に完全に是正することで、さらなる損害や露出を防ぐ</li> <li>SIRT はインシデントの結果として生じる損害を最小化するために、追加のコントロールを実施することがある</li> <li>影響を受けたシステムでの運用を継続することが安全かどうかを判断する</li> <li>影響を受けたシステムの運用を許可または拒否する</li> </ul> </li> <li>根絶 <ul> <li>セキュリティインシデントを引き起こした構成要素を排除する</li> <li>環境または対象システムへの攻撃者のアクセスを除去する</li> <li>影響を受けたシステム周辺のコントロールを強化する</li> </ul> </li> <li>復旧 <ul> <li>インシデントの原因となった問題が修正された後、影響を受けたシステムの運用を回復する努力</li> <li>追加の監視コントロールの実装</li> <li>関連する詳細でインシデントレコードを更新する</li> </ul> </li> <li>インシデント後の分析および活動 <ul> <li>振り返りと教訓の活動</li> </ul> </li> </ol> <h4 id="漏洩した認証情報のインシデント対応プロセス">漏洩した認証情報のインシデント対応プロセス<a class="td-heading-self-link" href="#%e6%bc%8f%e6%b4%a9%e3%81%97%e3%81%9f%e8%aa%8d%e8%a8%bc%e6%83%85%e5%a0%b1%e3%81%ae%e3%82%a4%e3%83%b3%e3%82%b7%e3%83%87%e3%83%b3%e3%83%88%e5%af%be%e5%bf%9c%e3%83%97%e3%83%ad%e3%82%bb%e3%82%b9" aria-label="Heading self-link"></a></h4> <p>認証情報の漏洩が確認された場合、認証情報を直ちに失効させて露出時間を最小化することが重要です。これは自動化、またはセキュリティチームによる手動取り消しによって実現できます。Security はその時点で行動による潜在的な影響が明確に把握されていなくても、さらなる悪用を防ぐため認証情報を直ちに失効させます。場合によっては、認証情報が正当なプロセスで使用されている場合に支障を来すことがあります。失効した認証情報に依存するサービスへの影響の可能性があるため、Security は <code>#security-revocation-self-service</code> Slack チャンネルに通知を投稿し、認証情報の所有者がこのチャンネルを手動または自動のセルフサービスとして使用できるようにします。認証情報はすでに公開され失効しているため、また認証情報所有者がチャンネル内で自分の認証情報を見つけやすくするため、失効した認証情報のクリアテキスト版が通知の一部として公開されます。</p>