データチームのデータ管理ページ

目的

データ管理は、エンタープライズデータプラットフォームの管理・保護・ガバナンスおよびそれに関連する活動に関するプラクティスとポリシーをカバーします。エンタープライズデータプラットフォームの技術コンポーネントは GitLab テックスタックに記載されています。

スコープ

データセキュリティプラクティス

エンタープライズデータプラットフォームは多くのシステムから収集されたデータをキャプチャ・処理・保存します。このデータのすべてが同じ重要性を持つわけではなく、私たちはクリティカルシステムティアフレームワークとデータ分類標準を使用して、どのデータが最も重要でどのように最適に保護するかを決定します。

役割と責任

標準

Snowflake

私たちは Snowflake でロールベースのデータアクセス方式を展開しています:

• ユーザーアクセスは Okta で管理され、アクセスリクエストは GitLab で管理されます
• 各ユーザーは職務機能に基づいた1つ以上のロールが割り当てられ、この設定は Permifrost で管理されます

追加のコントロールには以下が含まれます:

• データ分類標準に基づき、データはデータベースとスキーマで管理されます
• すべてのクエリ/ユーザー/プロセスは定義済みのウェアハウスまたはコンピュートリソースに割り当てられます
• パスワードはローテーションされます

データのカテゴリ化

GitLab のデータプラットフォームには複数のカテゴリがあります。各カテゴリがすべてのデータに適用されることを強調することが重要です。つまり、すべてのデータプロダクト（抽出されたソース・テーブル・行・フィールド・ダッシュボード・ポンプなど）はそれぞれのデータカテゴリに該当します。

個人データ取り扱い

個人データ（PII）はエンタープライズデータプラットフォーム全体で特別な取り扱いが必要です。個人データの管理方法を以下の原則で指導します:

• データ最小化: 特定のビジネス目的に必要でない限り、データプロダクトに個人データを含めないでください。
• 動的マスキング: Snowflake の PREP および PROD レイヤーの個人データフィールドには常に動的マスキングポリシーを適用してください。
• 統一されたアプローチ: すべての個人データ（GitLab チームメンバーデータと外部ユーザー/顧客データの両方）を同じ最高の感度基準で取り扱ってください。従業員と外部ユーザーの PII の区別を作らないでください。これはコンプライアンスと実装を複雑にします。
• 公開データの例外: 以下のチームメンバーデータ要素は単独では公開データであるためマスキングを必要としません: チームメンバーの名前・業務用メールアドレス・GitLab ユーザー名。ただし、これらの要素が他のデータと組み合わせられた場合（例: イベント出席のためのチームメンバー名 + 場所、またはユーザー名 + MR レスポンスタイム）、個人データとなりマスクが必要です。
• 権限の整合: 動的にマスクされた個人データのアクセス権限は、可能な限り基礎となるデータソースの権限を反映するべきです。これは、ビジネス機能ごとにマスキングロールを持つことを意味します（例: マーケティング個人データ・Sales 個人データ・ピープルチーム個人データ）。チームメンバーは通常のアクセスリクエストプロセスを通じてこれらへのアクセスをリクエストできます。

一般的なデータセキュリティコントロール

• データコントロールを定義する目的において、エンタープライズデータプラットフォームは Tier 1 システムです。
• 重要: 顧客のプライベート RED データはエンタープライズデータプラットフォームへの永続的な保存が禁止されています。

• データインフラ: データウェアハウスの一部としてデータにアクセスまたは処理し、エンドユーザーにデータを提供するシステムを含みます。
• データウェアハウスコントロール: エンタープライズデータウェアハウスは Tier 1 システムです。
• エンドポイントデバイス: データウェアハウスにアクセスできるすべてのエンドポイントは Tier 1 に分類されます

四半期ごとのデータヘルス＆セキュリティ監査

四半期ごとの監査は、適切な人が正しいデータアクセス設定を持ち、データパイプラインが正しく動作していることを確認するなど、システムセキュリティを検証するために実施されます。

このプロセスは四半期ごとのデータヘルス＆セキュリティ Issue テンプレートによってサポートされています。~"Quarterly Data Health and Security Audit" ラベルは、四半期ごとの監査に関連するすべての Issue とマージリクエストに使用されます。

活動のサンプルチェックリスト:

Snowflake

• オフボードされた従業員のアカウントを Snowflake から削除します
  • オフボードされた GitLab チームメンバーのすべての Snowflake アカウントは、オフボード日から削除する必要があります。このアクティビティは roles.yml 内のオフボードされた GitLab チームメンバーのアクティブなアカウントを確認します。非アクティブユーザーが roles.yml から削除されると、週次 DAG snowflake_cleanup がそれらを Snowflake から削除します。削除されたアクティブなアカウントは、以後すべてのデータ・スクリプト・その他の成果物を保持しなくなります。
• すべてのユーザーアカウントにパスワードが設定されていないことを検証します。
• 孤立したテーブルを削除します
  • dbt で管理されているテーブルは、dbt で管理されなくなったり不要になった場合に手動で削除する必要があります。このアクティビティは dbt で管理されているテーブルと比較して、孤立したテーブルを調べます。特定された孤立テーブルは使用されていないことを検証した上で削除されます。
• 未使用モデルを削除します
  • 使用されていないモデル（テーブルとビュー）は削除され、それらを生成するコードはアナリティクスリポジトリから削除されます。未使用モデルは以下のように定義できます:
    • 3か月以上クエリされていない。 または
    • Airflow アカウントが唯一のユーザーであり、下流のモデルがそれに依存していない。
  • 削除対象としてフラグが立てられたテーブルのレビューは、削除前にアナリティクスコミュニティによって行われます。これにより、誤ってフラグが立てられたテーブルを保持できるようにします。

Airflow

• 90日より古いログファイルを削除します。
  • このランブックに従って、PVC を削減するために古い Airflow のログファイルを削除してください。ディスクスペースが不足すると Airflow が動作しなくなります。

Monte Carlo

• オフボードされた従業員を Monte Carlo から無効化します
  • オフボードされた GitLab チームメンバーのすべての Monte Carlo アカウントは、オフボード日から無効化する必要があります。このアクティビティはオフボードされた GitLab チームメンバーのアクティブなアカウントを確認します。その後、アクティブなアカウントはすべて無効化されます。
• 監査実施時点から過去90日以内にログインしていないアカウントを Monte Carlo から無効化します。
  • 90日以上ログインしていない名前付き Monte Carlo アカウントは無効化されます。GitLab チームメンバーが再度アクセスを希望する場合は、通常の AR を作成する必要があります。マネージャーの承認後、ライセンスが利用可能であればアカウントが有効化されます。

注記: 90日間は変更される可能性があります。現時点では、Monte Carlo の使用頻度が低いチームメンバーもいるため（Snowflake や Tableau ほど頻繁には必要ない）、90日間のしきい値を設定しています。将来的にはこれを変更する可能性があります。

Tableau

• オフボードされた従業員のユーザーを Tableau から削除します
• 90日以上 Tableau アクセスを持っているが、過去90日間ログインしていないユーザーを削除します

例外

この手順の例外は、情報セキュリティポリシー例外管理プロセスに従って追跡されます。

参照

• コントロールドキュメント手順

ページのソースコードを見る - ページの編集 - please contribute.