カスタム連携

社内で開発したシステムや、オンプレミスの製品など、Drataに標準の連携がないシステムでも、データをDrataに送って証跡の収集とモニタリングを自動化できます。この仕組みがカスタム連携です。このページでは、標準の連携がないシステムのデータを取り込む方法として、カスタム連携の仕組み、APIでデータを送る流れ、カスタムテストと組み合わせてモニタリングの対象に加える方法を説明します。

カスタム連携の仕組み

カスタム連携（Custom Connections and Tests）は、次の2つの機能の組み合わせです。

機能	内容
カスタム連携	クラウドでもオンプレミスでも独自のシステムでも、外部のシステムからJSONの形のデータをDrataに送る
カスタムテスト	送ったデータに対して、自分で決めた条件でテストを実行する

カスタム連携は、一部のプランで使えます。ご契約のプランで使えるかどうかは、正規販売代理店（デジタルアクセルズ）にご相談ください。

全体の流れは次の通りです。

1. カスタム連携を作り、送るデータの形（スキーマ）を決めます。
2. 最初のデータを送り、連携とスキーマが正しく動くかを確かめます。
3. データを定期的に送る仕組みを作ります。
4. Test Builderで、データを確かめるカスタムテストを作ります。
5. テストの結果を確かめ、コントロールにマッピングします。

【注意】 カスタム連携は、標準の連携とは違い、Drataがデータを取りに行く仕組みではありません。連携先のシステムの設定、データを送る処理の自動化と、送る頻度は、自社で決めて作ります。開発者がAPIを使って処理を組む必要があり、かかる時間は社内のシステムの複雑さによって変わります。

標準の連携がないシステムには、カスタム連携のほかに、パートナーが作ってDrataに証跡を送るパートナーの連携もあります。連携の種類は連携の全体像で説明しています。

カスタム連携を作る

1. 左側のナビゲーションでConnectionsを開き、右上のCreate connectionを選びます。
2. 連携の名前と説明を入れ、ワークスペースを選びます。
3. データの取得元（データソース）の名前と説明を入れます。
4. スキーマを、JSON Schemaか、サンプルのJSONのデータで指定し、ValidateかGenerateで確かめます。
5. テストの結果でレコードを見分けるための表示名（Display name）に使う項目を選びます。
6. データを送るためのAPIキーを、新しく作るか、既存のものを使うかを選びます。

決めること	内容
スキーマの指定	サンプルのJSONのデータを入れると、Drataがスキーマを自動で作る。勧められる方法で、自社のシステムのAPIの実際の応答をサンプルに使うと、実際のデータに合ったスキーマになる。JSON Schemaで、構造、データの型、必須の項目を自分で定義することもできる
データの形	最上位に、文字列か数値の項目（名前、メールアドレス、IDなど）が少なくとも1つ必要。最上位を配列にした形には対応しない。最上位に配列の項目が含まれるのは構わない。入れ子の配列が複雑な場合は、テストを作るときに高度なエディターが必要になることがある
表示名	例えば多要素認証が有効でないユーザーを探すテストなら、メールアドレスを表示名にすると、結果で誰かが分かる
APIキー	新しく作る方法が勧められ、必要なスコープがあらかじめ付く。既存のキーを使う場合は、Custom Connections DataのCreate Data、Create and Update Data、Delete Dataのスコープが必要

APIでデータを送る流れ

データは、Drata APIに、APIキーを付けたPOSTの要求で送ります。要求の本文では、dataの項目の中にデータを入れます。

POST https://public-api.drata.com/public/custom-connections/{connectionId}/resources/{resourceId}/records
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "data": {
    "email": "jane.doe@example.com",
    "status": "active"
  }
}

項目	内容
JSONの大きさ	5MBまで
要求の数の上限	送信元のIPアドレスごとに、1分あたり500件
応答	新しいレコードを作ったときは201 Created、既存のレコードを更新したときは200 OK
IDがない場合	新しいレコードとして作られ、DrataがUUIDを付ける
IDがある場合	同じIDのレコードがあれば更新され、なければそのIDで新しく作られる
配列で送った場合	1件ずつ検証、処理され、応答に1件ごとの状態のコードが返る

送ったデータは、カスタム連携の画面のManageタブで確かめられ、View Dataで中身を見られます。

データを送る処理を自動化する

最初のデータを送れたら、連携先のシステムからデータを取り出してDrataに送る処理を、定期的に動くようにします。継続的なモニタリングにするためです。

方法	内容	向く場面
ノーコードの自動化のサービス	Torq、Tines、Make、Zapierなどで、データを取り出してDrata APIに送る流れを作る	エンジニアの支援がない、早く始めたい
スクリプトと定期実行	PythonやNode.jsなどのスクリプトを、cronなどで毎日や毎時に実行する	処理の内容と実行の時期を細かく決めたい
クラウドの関数	AWS Lambdaなどの関数を、スケジュールや出来事をきっかけに実行する	クラウドを中心に使っている
社内のデータ連携の基盤	Airflow、Workato、MuleSoftなどの既存の流れに、Drataへの送信を加える	社内にデータ連携の基盤と担当者がいる

【運用のポイント】 スクリプトを使う場合は、サーバー、Dockerのコンテナ、サーバーレスの関数、CI/CDの定期実行など、スケジュールで動かせる場所に置きます。DrataのAPIキーは、環境変数やシークレットの管理の仕組みに保管し、スクリプトに直接書かないでください。

APIキーを管理する

APIキーは、SettingsのAPI Keysで作成、確認、取り消しをします。

項目	内容
有効期限	12カ月（既定）、無期限（Never）、任意の日付（Custom）から選ぶ
許可するIPアドレス	キーを使える送信元のIPアドレスを絞れる。空欄にすると、全ての送信元から使える
スコープ	個別に選ぶ（Custom）、全ての読み取り、全ての読み取りと書き込みから選ぶ
キーの値	作ったときにしか表示されない。安全な場所に保管する
状態	Active、Expires soon（30日以内に期限切れ）、Expired、Revoked。期限切れと取り消し済みのキーは、元に戻せない

API全般と、APIキーの代わりに短い期間のトークンを使うOAuthのアプリケーション（SettingsのOAuth Applications）は、Drata APIとMCPで説明します。APIの詳細は、Drata APIの開発者向けのドキュメントにあります。

カスタムテストと組み合わせる

カスタム連携で送ったデータは、カスタムテストで確かめて初めて、モニタリングの対象になります。カスタムテストは、MonitoringのTest Builderで作ります。

設定	内容
カテゴリー	Custom
提供元	カスタム連携の名前
条件	データソースを選び、確かめる属性と値を決める（例：多要素認証の項目がtrueであること）

作ったテストは下書きとして保存され、下書きのまま実行して動きを確かめられます。確かめた後に公開すると、モニタリングと証跡の収集の対象になります。テストの結果では、特定のレコードを以後のテストから除外することもできます。最後に、テストをコントロールにマッピングします。

カスタムテストの作り方と、下書きと公開の流れは、カスタムテストを作るで説明します。

端末のデータを送る

MDMや資産管理のシステムがDrataの連携に対応していない場合は、カスタムの端末連携（Custom Device Connection）で、端末のデータを送れます。カスタム連携の機能の一部を、DrataのMDMのテストの判定に合わせて絞ったもので、一部のプランで使えます。ご契約のプランで使えるかどうかは、正規販売代理店（デジタルアクセルズ）にご相談ください。

項目	カスタム連携との違い
作り方	ConnectionsのAvailableタブでMDMのカテゴリーに絞り込み、Custom Device Connectionをつなぐ
スキーマ	Drataが決めた端末のスキーマに合わせる。要員のID、シリアル番号、ディスクの暗号化、ファイアウォール、ウイルス対策、自動更新、パスワードマネージャーの状態などの項目がある
テスト	送ったデータが、端末のカテゴリーのテストにあらかじめ対応付けられる。カスタムテストを作る必要はない
APIキーのスコープ	読み取り、追加、更新、削除のデータのスコープが必要。新しく作ると、あらかじめ付く

データを送る処理と頻度を自社で作る点は、カスタム連携と同じです。MDMとの連携については、MDMとセキュリティー製品との連携で説明しています。