セキュリティおよび技術ポリシーの例外プロセス
例外
セキュリティおよび技術ポリシーに対する例外は、追跡可能な形式でポリシー承認者によって追跡および承認される必要があります。例外プロセスは、各ポリシーで定義されるべきです。
規制、コンプライアンス、機密性、完全性、可用性に関する要件などの情報セキュリティ上の考慮事項は、企業が中央でサポートまたは推奨される業界標準を採用する場合に最も簡単に満たすことができます。GitLab は最小権限の原則の下で運営されますが、中央でサポートまたは推奨される業界の技術が、特定の職務や会社のニーズに対して常に実現可能であるとは限らないと理解しています。前述の標準または推奨される技術からの例外は推奨されません。ただし、セキュリティおよび技術ポリシーの例外について合理的かつ正当なビジネスおよび／または研究上の理由があり、代替技術を適切に実装し維持するための十分なリソースがあり、本ドキュメントおよびその他の関連ドキュメントに記載されたプロセスが遵守され、その他のポリシーや標準が守られる場合には、検討されることがあります。
チームメンバーが標準的な業務の流れまたはポリシーで許容される範囲からの例外を必要とする場合、依頼者は Exception Request を Security Assurance 部門に提出する必要があります。これには、少なくとも Issue テンプレートに記載された要素が含まれます。
例外リクエストの承認要件は Issue テンプレート内に記載されています。依頼者は、承認マトリクスに基づいて承認を提供する必要がある適切な個人にタグ付けする必要があります。
ビジネス側が承認決定に対して異議を申し立てたい場合、その異議申し立ては [email protected] にいる Legal に送信されます。Legal は、例外が認められた場合に会社にもたらされる潜在的なリスクについての意見書を作成します。Legal の意見書は最終決定のために CEO および CFO に転送されます。
例外承認には以下が含まれている必要があります:
- リスク／影響を低減するために推奨される補完的な統制（例: 財務上重要なシステムへの管理者権限には、システム内のユーザー活動の監査ログとレビューが必要となる場合があります）
- 関連する例外リクエスト Issue に記載されること。Issue の「Approvals」エリアの全セクションを記入する必要があります。
例外リクエストが提出されると、以下の一般的な流れが進行します:
- 依頼者は、例外リクエストの種類に応じて、所属部門長またはポリシー、標準、手続きの管理者から承認を受けます。
- 依頼者の部門による承認後、関連するポリシーを所有するチームが例外リクエストをレビューします。
- Security Compliance は、例外リクエストに現在または将来のコンプライアンス上の影響があるかどうかを判断します。
- ポリシーオーナーは、適切な補完的な統制が文書化されていることを確認するためにリクエストをレビューし、リクエストに関連する全体的なリスクレベルを判断する際に Security Compliance や他の SME からの意見を考慮します。
- ポリシーオーナーは最終決定を文書化し、必要に応じて例外リクエストによるリスクを軽減するための推奨アクションプランを文書化します。
- 例外は中央の例外管理スペースに記録されます。
- 例外は有効期限が近づくと再確認され、例外の延長が必要な場合は、新たに承認された延長リクエストが必要となります。
bfd74782)