AWS PrivateLink × SCIM で実現する セキュアで運用負荷の低い Databricks 基盤の構築 CA DATA NIGHT #10 2026.06.25 発表者 @tsudash0 

自己紹介 @tsudash0 所属: サイバーエージェント > メディア統括本部 > Data Science Center （DSC ） 役割: データエンジニア, インフラエンジニア 経歴: 2012 年からデータ領域のソフトウェアエンジニアとして働き始める サイバーエージェント歴 2015 年〜2022 年 正社員（全社のデータ基盤運用、データマネジメント業務） 2025 年〜 業務委託（某プロジェクトのデータエンジニア） インフラも含めたデータ基盤の設計・構築・運用 AWS / Databricks / Snowflake / Google Cloud / Terraform どういう人か: データ基盤を長期的に機能させるための原理・設計・組織を考えるエンジニア by Claude データ基盤のシステムアーキテクチャ設計、データアーキテクチャ設計 DMBOK データマネジメントによる成熟度の評価から施策立案 2 

もくじ 1. プロジェクト全体像 2. 運用面での対策 1. メダリオンアーキテクチャで職責を分離 2. Databricks Asset Bundle によるジョブ管理 3. セキュア面での対策 1. Private Link の構成 2. SCIM による IdP 統合 4. 得られた学び 5. まとめ 3 

プロジェクト全体像 

このプロジェクトはCA グループのある事業におけるデータ活用プロジェクトです。 事業側の戦略担当者が人力で行なっていたダッシュボード構築を自動化しながら、更なる知見を得るためにデータサイ エンティストやBI エンジニアが協業してデータ分析を行なっています。 プロジェクトが進行し、データが活用されるに従って徐々にメンバーは増えていますが、私が担当するデータエンジニ アリング領域はリソースが少ないのが現状です： 役割 2025 年秋 2026 年現在 マネージャー 1 名 1 名 アプリエンジニア - 2 名 データサイエンティスト - 2 名 BI エンジニア 1 名 2 名 データエンジニア 1 名（20% 稼働） 1 名（20% 稼働） 5 

データ基盤への要件 データエンジニアの工数が少ないため、データサイエンティストやBI エンジニアでもデータ加工が必要: メダリオンアーキテクチャによる職責分離 Databricks のマネージドサービスを利用。Notebook ベースでのデータ加工を中心としたETL プロセスを導入 データは一部機密性のあるもの（PII 、PHI 等）が含まれ、セキュリティの優先度が高い SCIM による権限の一元管理 PrivateLink 利用によるネットワークセキュリティの確保 Databricks を選んだ理由 2025 年内に Snowflake, Databricks 双方で PoC を行いました。CA グループではどちらも利用実績がありますが、今回 のプロジェクトでは Databricks を採用しました。 理由としては： データエンジニアのリソースが少なく、データサイエンティストやBI エンジニアだけでもデータ管理できるプラット フォームがよかった Databricks の Notebook を中心としたデータ加工方法がデータサイエンティストと相性がよかった メダリオンアーキテクチャーを導入しやすく、エンジニア・アナリストでの職責分離がしやすかった 6 

今日のゴール 同じような制約を持つ方に向けて、今日はこんな話をします。 「少人数でも回せるセキュアなデータ基盤」 のヒントにな れば幸いです： エンジニアリソース不足 Notebook 中心運用 + DAB でアナリスト自走を支援しながらコード管理を支援 セキュリティ要件 PrivateLink + SCIM で安全かつ運用負荷低 7 

現在のアーキテクチャ システムアーキテクチャーは次のようになっています： データソース GitHub AWS ECS Databricks on AWS Unity Catalog QuickSight Data Source1 API Data Source2 API ... Databricks Asset Bundle マスターデータ登録システム S3: データソースの Raw Data S3: マスターデータの Raw Data datasource1-ingestion datasource2-ingestion ... Databricks Jobs/ Pipelines (ETL) Bronze Silver Gold Dashboards API API JSON JSON AWS DMS Load (Job) DeltaLiveTable Transform (Job) Transform (Job) deploy 8 

運用負荷を減らす対策 

対策1: メダリオンアーキテクチャで職責を分離 データ基盤のシステムアーキテクチャーにはさまざまな選択肢がありますが、このプロジェクトでは Databricks のマネ ージドサービスを中心に据えたシンプルな構成にしています。 特にデータ加工においてデファクトスタンダードである dbt も採用を見送りしています： 連携データソースが多く、データエンジニアの稼働時間がほとんどがデータ抽出に取られてしまう プロジェクト内のアナリストで dbt 運用経験があるメンバーがいない （私も Databricks に向けた dbt の最適なオプションなど把握していなかった） リアルタイム集計の需要が一部あり、dbt だけでは対応できないケースが見えていた これらの理由から、以下のように職責を分離。アナリストが自走できるような環境としました： データエンジニア：データソースからデータを集め、差分連携や重複排除などの処理までを行う アナリスト：準備されたデータを、ダッシュボード用に結合・加工する ※アナリスト側でもDatabricks を利用した様々な最適化をしてデータ加工していますが、今回は割愛 10 

職責分離の全体像 🔧 データエンジニア領域 📊 DS / BI エンジニア領域 データソース ECS S3 Bronze ( データソース) Silver ( データソース) Silver ( ドメイン) Gold ( ドメイン) QuickSight データ品質担保 重複排除・型変換 ビジネスロジック ⾃由に加⼯可能 QuickSight ⽤に最適化 ポイント: Silver 層を2 つに分離 レイヤー 担当 役割 Silver ( データソース) データエンジニア 重複排除・型変換などデータ品質担保 Silver ( ドメイン) DS / BI エンジニア ビジネスロジックに基づく自由な加工 → 境界が明確になり、お互いの作業が干渉しない 11 

対策2: Databricks Asset Bundle (DAB) によるジョブ管理 Databricks Asset Bundle (DAB) は、Databricks のジョブ、パイプライン、ノートブックなどのリソースを YAML ベー スで宣言的に管理し、デプロイを自動化するための公式ツールです（公式ドキュメント） IaC （Infrastructure as Code ）: ジョブ定義を Git で管理可能 環境分離: targets で dev / prod などを切り替え CI/CD 対応: CLI でデプロイを自動化（対応予定） 変数サポート: 環境ごとにパラメータを差し替え 12 

DAB 導入の目的 このプロジェクトでは、データエンジニアが担当する領域と、一部のデータサイエンティストの作業領域で DAB を導入 しています。 課題 DAB による解決 ジョブ定義が UI に散らばり、差分管理が困難 YAML で Git 管理、PR レビュー可能 dev/prod で設定を手動で変更 targets で環境を宣言、切り替えコマンド1 つ デプロイ手順が属人化 databricks bundle deploy で誰でも同じ結果 ジョブ変更の履歴が追えない Git のコミット履歴で追跡可能 本プロジェクトでの活用 Ingestion ジョブ: 各種データソースのデータ取り込みを DAB で管理 スケジュール実行: cron で定期実行を定義 GitHub Actions 連携: PR マージ時に本番へ自動デプロイ( 対応中) 13 

管理しているバンドル構成 databricks-asset-bundle/ ├── bundles/ │ ├── ingestion-datasource1/ # データソース1 の S3 -> Bronze -> Silver までの加工処理を定義 │ ├── ingestion-datasource2/ # データソース2 の S3 -> Bronze -> Silver までの加工処理を定義 │ │ └── src/ # ノートブックや Python スクリプト │ │ ├── databricks.yml # バンドル定義 │ │ ├── resources/ # ジョブ定義 │ └── ingestion-master/ # マスターデータの Delta Live Table 定義 └── README.md 14 

サンプル: databricks.yml （バンドル定義） バンドル全体の メタデータと共通設定を定義するファイルです： bundle: name: myproject-ingestion variables: env: default: dev catalog: default: myproject include: - resources/*.yml targets: dev: mode: development default: true prod: mode: production variables: env: prod catalog: myproject permissions: - group_name: myproject-databricks-admin level: CAN_MANAGE 15 

サンプル: ジョブ定義（resources/*.yml ） 各 Databricks リソース（Jobs, Pipelines 等）を定義するファイルです： resources: jobs: ingestion_datasource1_activities: name: "[${bundle.target}] Ingestion Datasource1" description: "Load Datasource1 data from S3 (hourly)" schedule: quartz_cron_expression: "0 35 * * * ?" timezone_id: Asia/Tokyo tags: domain: ingestion source: datasource1 layer: bronze tasks: - task_key: load_datasource1_activities notebook_task: notebook_path: ../src/load_datasource1_activities.ipynb base_parameters: env: ${var.env} catalog: ${var.catalog} - task_key: transform_silver_activities depends_on: - task_key: load_datasource1_activities notebook_task: notebook_path: ../src/transform_silver_activities.ipynb 16 

DAB コマンド一覧 # バンドルの検証（YAML 構文チェック） databricks bundle validate # dev 環境へデプロイ databricks bundle deploy -t dev # prod 環境へデプロイ databricks bundle deploy -t prod # ジョブを即時実行 databricks bundle run -t dev ingestion_datasource1_activities # デプロイ状態の確認 databricks bundle summary -t prod # リソースの削除（クリーンアップ） databricks bundle destroy -t dev 17 

セキュリティ面の対策 AWS PrivateLink 構成 

なぜ PrivateLink が必要か Databricks on AWS は、Compute Plane （データ処理を行うクラスター）が Control Plane （UI やAPI ）と通信する 際、デフォルトではパブリックネットワークを経由します。セキュリティ要件の高い環境では、この通信をプライベー トネットワーク内に閉じ込める必要があります。 Private Link 構成 Control Plane （Databricks 管理） AWS ap-northeast-1 Customer VPC (10.10.0.0/16) Public Subnets 10.10.101.0/24, 10.10.102.0/24 PrivateLink Subnets 10.10.3.0/24, 10.10.4.0/24 Private Subnets 10.10.1.0/24, 10.10.2.0/24 Internet Databricks が管理 ・Workspace UI / REST API ・ジョブスケジューラ ・クラスタマネージャ Workspace UI & REST API SCC Relay Secure Cluster Connectivity S3 (Unity Catalog Managed Storage) Internet Gateway S3 Gateway Endpoint NAT Gateway Backend REST Endpoint Backend Relay Endpoint Databricks Cluster (Compute Plane) Compute Plane （顧客管理） ・クラスタ / ノートブック実⾏ ・データ処理 ・顧客VPC 内で動作 ユーザー ライブラリの ダウンロード等 REST API (Port 443) SCC (Port 6666) PrivateLink (Backend) PrivateLink (Backend) Data Access Gateway Endpoint 19 

PrivateLink の種類と採用方針 Databricks では 3 種類の PrivateLink が提供されています（公式ドキュメントより） ： 種類 保護する通信 本環境 インバウンド（フロントエンド） ユーザー → Workspace UI/API 対応検討中 アウトバウンド（サーバーレス） サーバーレスコンピュート → 顧客リソース（S3 等） (Databricks 側で対応※) クラシック（バックエンド） クラシックコンピュート → Control Plane 対応済 ※ サーバーレスは、Databricks 側の環境に S3 Gateway Endpoint が置かれており、同一リージョンであれば閉域網で 通信される 本環境の方針: クラシック（バックエンド） を優先的に実装 構成手順: PrivateLink 構成手順（公式） Terraform サンプル: GitHub 今後の対応予定: インバウンド（フロントエンド）: SSO + MFA で保護中だが、より厳格なセキュリティ要件対応時に検討 20 

VPC エンドポイント構成（クラシック向け） クラシック PrivateLink 用に、3 種類の VPC エンドポイントを構成しています： エンドポイント 種別 目的 Backend REST Interface Workspace UI & REST API Backend Relay Interface Secure Cluster Connectivity S3 Gateway プライベート S3 アクセス（クラシック Cluster 用） ネットワーク構成 VPC を以下のサブネットに分割し、PrivateLink 専用のサブネットを設けています： サブネット CIDR 用途 Private Subnet 10.10.1.0/24, 10.10.2.0/24 Databricks コンピュート PrivateLink Subnet 10.10.3.0/24, 10.10.4.0/24 VPC エンドポイント配置 Public Subnet 10.10.101.0/24, 10.10.102.0/24 NAT Gateway 21 

通信経路のセキュリティ 経路 保護方式 説明 クラシック Cluster → Control Plane PrivateLink REST API / SCC 通信は VPC 内で完結 クラシック Cluster → S3 Gateway Endpoint AWS バックボーン経由、NAT 不要 サーバーレス→Unity Catalog (Databricks 管理 S3) Databricks 内部 Silver/Gold 層は安全 サーバーレス→顧客管理 S3 (Bronze 層) Databricks で対応済 同一リージョンならS3 へのアクセスは安 全 ユーザー → Workspace パブリック SSO + MFA で保護 ストレージ構成: Bronze 層: 顧客管理 S3 → サーバーレスからのアクセスは今後対応 Silver / Gold 層: Databricks 管理 S3 ( Unity Catalog ) → サーバーレスでも安全 Terraform による IaC 管理 これらの設定はすべて Terraform で管理しており、以下の資料を参考に実装： 構成手順: PrivateLink 構成手順（公式） Terraform サンプル: GitHub 22 

セキュリティ面の対策 SCIM による IdP 統合 

なぜ SCIM 連携が必要か CA グループでは PERMAN という認証認可基盤を独自で構築・運用しています。Databricks や QuickSight へのユーザ ー連携を PERMAN 経由にすることで以下の利点が得られます： ユーザー管理の一元化: 入退社やロール変更を PERMAN 側で行えば、各サービスに自動反映 アクセス権限の可視化: 誰がどのデータ・ダッシュボードにアクセスできるか PERMAN で確認可能 監査対応: PERMAN の履歴で権限変更を追跡できる PERMAN ( 認証認可基盤) AWS Lambda Databricks QuickSight Databricks ⽤ ロール設定 QuickSight ⽤ ロール設定 Databricks SCIM Sync QuickSight SCIM Sync ユーザー登録 & Group 連携 ログイン ユーザー登録 & Group 連携 ログイン 管理者 利⽤者 ポイント 管理者は PERMAN だけを 変更すればよい ⾃動同期 ( 定期 or イベント駆動) 設定 設定 «trigger» «trigger» SCIM API SCIM API 24 

Databricks との統合 現時点では Databricks はユーザーが直接使っていませんが、Genie などのインタラクティブにデータ活用できる仕組み にも興味をもっており、中長期的には Databricks を直接利用する可能性があります。 そのため、PERMAN を用いてユーザー管理を一元化したいのですが、PERMAN は Databricks との SCIM 連携に対応し ていませんでした。 しかし Databricks API を利用した実装は難しくありませんでした。どのように実装したのかを簡単にご紹介します。 使用技術 カテゴリ 技術 用途 言語 Go 社内の類似 Lambda を流用（Python でも可） Databricks API SCIM 2.0 REST API ユーザー・グループ同期 HTTP クライアント net/http （Go 標準） SDK 不要、自前実装 PERMAN API GraphQL ロール・ユーザー取得 シークレット管理 AWS Secrets Manager トークン保管 25 

SCIM 関連の Databricks API はシンプル メソッド エンドポイント 用途 GET /scim/v2/Users ユーザー一覧取得 POST /scim/v2/Users ユーザー作成 GET /scim/v2/Groups グループ一覧取得 POST /scim/v2/Groups グループ作成 PATCH /scim/v2/Groups/{id} グループ更新（メンバー追加・削除） 公式ドキュメント: https://docs.databricks.com/api/account/accountscim ポイント 公式 SDK 不要: SCIM は標準仕様なので net/http だけで実装可能 エンドポイントは5 つだけ: Users GET/POST, Groups GET/POST/PATCH 実装期間: 約1 週間（テスト含む） 26 

EventBridge (1 時間ごと) EventBridge (1 時間ごと) Lambda (Go) Lambda (Go) PERMAN (GraphQL) PERMAN (GraphQL) Databricks (SCIM API) Databricks (SCIM API) スケジュール実⾏ GraphQL: search_roles (prefix: "ca-***-databricks-*") ロール⼀覧 loop [ 各ロールごと] GraphQL: users_by_role(role_id) ユーザー⼀覧 GET /scim/v2/Groups 既存グループ⼀覧 GET /scim/v2/Users 既存ユーザー⼀覧 alt [ 新規グループ] POST /scim/v2/Groups 201 Created alt [ 新規ユーザー] POST /scim/v2/Users 201 Created alt [ メンバーシップ変更] PATCH /scim/v2/Groups/{id} (members 追加/ 削除) 200 OK 正常終了 27 

実装例 // Databricks クライアント（SDK不要、標準HTTPで十分） type DatabricksClient struct { httpClient *http.Client token string accountURL string // https://accounts.cloud.databricks.com } // ユーザー作成（POST /scim/v2/Users） func (c *DatabricksClient) CreateUser(user *DatabricksUser) error { body, _ := json.Marshal(user) req, _ := http.NewRequest("POST", c.accountURL+"/scim/v2/Users", bytes.NewReader(body)) req.Header.Set("Authorization", "Bearer "+c.token) req.Header.Set("Content-Type", "application/scim+json") return c.httpClient.Do(req) } // グループへメンバー追加（PATCH /scim/v2/Groups/{id}） func (c *DatabricksClient) AddMemberToGroup(groupID, userID string) error { patch := map[string]interface{}{ "schemas": []string{"urn:ietf:params:scim:api:messages:2.0:PatchOp"}, "Operations": []map[string]interface{}{{ "op": "add", "path": "members", "value": []map[string]string{{"value": userID}}, }}, } body, _ := json.Marshal(patch) req, _ := http.NewRequest("PATCH", c.accountURL+"/scim/v2/Groups/"+groupID, bytes.NewReader(body)) // ... } 28 

QuickSight との統合 QuickSight は事業側のユーザーも閲覧するため、権限設定後すぐにダッシュボードを見れる必要があります。そのた め、イベントドリブンの SCIM 連携を実装しました。 us-east-1 ap-northeast-1 EventBridge QuickSight PERMAN (CA Group IdP) CloudTrail (Console Login) EventBridge Rule (ConsoleLogin Filter) AWS Console Login は us-east-1 にのみ記録 Lambda (perman-sync-quicksuite) Custom Event Bus (perman-sync-event-bus) EventBridge Rule (Login Trigger) SCIM API Groups Users GraphQL API Roles Users 処理内容 1. ログインユーザーの Email 取得 2. PERMAN でロール検索 3. QuickSight グループ同期 4. メンバーシップ更新 クロスリージョン転送 us-east-1 → ap-northeast-1 Custom Event Bus 経由 Login Event PutEvents (Cross-Region) Trigger GraphQL Query SCIM API Create/Update Create/Update 29 

QuickSight 権限の特殊な挙動 AWS Console へのログインイベントは、東京リージョン（ap-northeast-1 ）ではなく us-east-1 の CloudTrail に のみ記録されます。Lambda は ap-northeast-1 で動かしたいため、クロスリージョンのイベント転送が必要でし た。 初回連携時: IAM Policy の quicksight:CreateReader 等を参照して QuickSight 権限が決まる 連携後: IAM Policy と QuickSight 権限は 連動しない IAM Policy を変更してもユーザーの QuickSight 権限は変わらない QuickSight 側で権限を昇格することは可能（ただし降格は不可） このため、運用としては： デフォルト: 全員「Reader 」で作成 必要に応じて: 管理画面から手動で「Author 」へ昇格 30 

得られた学び 

最後に感想として、得られた学びを共有いたします。 プロジェクトやチーム体制によって適切なツールは異なる 今回のプロジェクトでは Databricks のマネージドな機能を利用し、技術スタックを積まない方向性にしています。 例えばデータ加工処理に dbt を採用せず、Notebook や Python スクリプトによるデータ抽出・変換を行なっています。 ブロンズ・シルバー層まではデータエンジニアがプログラムとデータの品質を保つ必要はありますが、Notebook 形式に よってゴールド層はデータサイエンティストやBI エンジニアがフットワーク軽くデータを構築できる体制にできまし た。 また、そのおかげで各担当者が自分の領域にオーナーシップをもてており、より良いデータ加工の方法はないか Databricks の機能を色々と試したりしています。例えば LakeFlow Spark 宣言型パイプライン (SDP) を使って、シルバー 層以降のデータ加工をストリーミング変換にする領域もあります。 このように Databricks のネイティブ機能を利用しやすい環境にすることで、Databricks の新機能も取り入れやすくな ります。 32 

ドキュメントが充実していて読みやすい 今回のプロジェクトでは SCIM や Private Link を組み込んだ基盤を実装するなど、初めての開発が多かったです。 しかし、Private Link の解説ページなどを見ていただいたら分かりますが、難しい概念が丁寧に解説されており、非常 に読みやすく理解しやすいです。参考実装も Github に上がっており、Databricks 社の方々や AI の力も借りつつ、無事 に機能リリースすることができました。 33 

Genie が優秀 散々語られていると思いますが、1 つ事例を紹介させてください。 今回 DAB を紹介しましたが、実は旧開発環境から本番環境にジョブを移植する必要があり、その際に DAB を導入しま した。 DAB の実装は次の通りです： 開発環境に、DAB の github リポジトリを連携 Genie に DAB 化したいジョブを共有 Genie が対象ジョブの Notebook, ジョブ設定(YAML), DAB 用の設定ファイルを構築し、リポジトリに追加 本番環境へ bundle deploy 環境間のジョブ移設は手間なことが多いですが、Genie + DAB であっという間に作業が済んでしまい感動しました。 34 

さいごに 小さいプロジェクトで、Databricks をどう活用して、運用しやすくセキュアな基盤を目指すか、というお話をさせてい ただきました。 Databricks でこんなことをしている、こんな便利な機能があるなど、是非懇親会でお話させてください。 ご清聴ありがとうございました！ 35