プロンプトと適用可能なシナリオ
マルチテナントB2Bドキュメントサービスでは、認証済みユーザーがPDF、JPEG、PNGの添付ファイルをアップロードでき、ファイルあたりの上限は20 MiBです。処理完了後は、同じテナント内の認可されたメンバーのみがファイルをダウンロードできます。クライアントはバイト列、元のファイル名、拡張子、Content-Type、申告サイズを制御できるため、これらの値はいずれも信頼できません。
セキュアなアップロード、スキャン、公開、ダウンロードのAPIを設計してください。また、この設計が以下をどのように防止するかを説明してください。
- Webシェル、偽装されたタイプ、二重拡張子、パストラバーサル、オブジェクトの上書き
- 悪意のあるPDF、画像パーサーのエクスプロイト、マルウェア、ポリグロットファイル
- テナント間アクセス、公開オブジェクトURLの漏洩、危険なインラインレンダリング
- サイズ超過リクエスト、ストレージクォータの枯渇、スキャンの競合、スキャナーの停止
- スキャン通過後のファイルの差し替え、および完了呼び出しの重複による状態破損
20 MiBの制限、3つの許可フォーマット、B2Bテナントモデルは面接用の制約であり、普遍的なセキュリティ推奨事項ではありません。候補者はアイデンティティ、アップロードプロトコル、オブジェクトストレージ、非同期処理、ダウンロード認可を堅牢な境界へと統合する必要があります。中心となる能力はバックエンドAPIおよびサービスのセキュリティであるため、カテゴリはbackendです。
面接官が評価するポイント
第一に、候補者が不変条件（インバリアント）を確立できるかです。セキュリティ判定を通過していないバイト列は隔離状態にとどまり、ビジネスユーザーによる読み取り、アプリケーションによるパース、アプリケーションのプライマリオリジンからの配信は行えません。クライアントのファイル名がストレージパスになることは決してありません。すべての読み取りは再度認可されます。
第二に、タイプ検証における多層防御を理解しているかです。拡張子、リクエストのContent-Type、ファイルシグネチャ、パーサーの結果は、それぞれ部分的な証拠にすぎません。サービスは、ビジネス許可リスト、正規化、構造パース、マルウェアスキャン、そして必要に応じて再エンコードやコンテンツの無害化・再構築（CDR）を組み合わせる必要があります。
第三に、明示的な非同期ステートマシンを設計できるかです。バイト列を受信したことは、オブジェクトが隔離領域に到達したことを意味するだけであり、ファイルが利用可能になったことを意味しません。APIには処理中、利用可能、拒否、技術的失敗の状態と、正確な再試行、タイムアウト、クリーンアップのルールが必要です。
第四に、スキャンの競合（レースコンディション）を捉えているかです。スキャナーは特定のバイトシーケンスを判定します。判定後に同じオブジェクトキーが上書き可能である場合、AVAILABLEレコードが一度もスキャンされていないコンテンツを指す可能性があります。判定結果はイミュータブルなオブジェクトバージョンまたはコンテンツハッシュに紐付けられ、公開は条件付きでなければなりません。
第五に、脅威モデルに取得処理を含めているかです。ランダムなキーは推測困難性を高めますが、テナントおよびオブジェクトの認可の代わりにはなりません。ダウンロードには制御されたハンドラーまたは有効期間の短い署名付きURL、安全なレスポンスヘッダー、隔離されたオリジン、意図的なキャッシュポリシーが必要です。
回答前に確認すべき明確化のための質問
- ファイルはどのように使用されますか？ ダウンロードのみ、ブラウザプレビュー、テキスト抽出、サムネイル生成、サードパーティ処理ではリスクが異なります。パーサーが1つ増えるごとに攻撃対象領域が広がります。
- 3つのフォーマットで十分ですか？ このシナリオではZIP、Office、その他のあらゆるフォーマットを拒否できます。アーカイブをサポートする場合は、階層の深さ、ファイル数、展開後サイズ、圧縮率の制限が必要になります。
- ユーザーはどのように認証しますか？ クッキー認証ではCSRF対策が導入されます。ベアラートークンでも適切なCORS、スコープ、漏洩対策が必要です。
- オブジェクトストレージへの直接アップロードは必要ですか？ APIは小さなファイルをストリーミングできます。より高い同時実行性では、単一の隔離オブジェクトにスコープされた有効期間の短い認証情報を発行し、アップロード後に実際のオブジェクトを検証できます。
- 誰がアップロード、ステータス確認、ダウンロード、削除を行えますか？ テナントのロール、オブジェクトの所有権、監査要件を個別に定義してください。単にログインしていることを確認するだけでは不十分です。
- スキャンのSLAはどうなっていますか？ 待機時間、再試行回数、フェイルクローズ（安全側に倒す）動作、障害時にユーザーに表示される状態を定義してください。
- コンプライアンスやデータ所在（レジデンシー）の要件はありますか？ 暗号化キー、保持期間、監査ログ、削除、バックアップのクリーンアップに制約がある場合があります。
- 何をもって成功とみなしますか？ バイトの保存、スキャン通過、認可されたダウンロードは、それぞれ異なるAPIセマンティクスを持つべき3つのマイルストーンです。
30秒の回答フレームワーク
「私は3つの不変条件から始めます。未スキャンのファイルは隔離領域にのみ存在すること、サーバーがストレージキーを生成し元のファイル名は制限されたメタデータにとどめること、すべてのダウンロードでテナントおよびオブジェクトの認可を実行することです。ライフサイクルはPENDING_UPLOAD → QUARANTINED → SCANNING → AVAILABLE/REJECTED/FAILEDです。
アップロードの作成時、サービスはユーザーのロール、クォータ、許可フォーマット、20 MiBの制限をチェックし、推測不能で上書き不可能なオブジェクトキーを生成します。バイト列は実行不可・非公開の隔離ストレージにストリーミングされます。サーバーは実際のサイズ、正規化された拡張子、ファイルシグネチャ、制約付きパーサーの出力を検証し、隔離されたワーカーがマルウェアスキャンを実行します。判定結果はオブジェクトバージョンまたはSHA-256に紐付けられ、それらの値が一致している場合にのみ公開が成功します。
ダウンロード時、サービスはテナントとオブジェクトの権限を再確認し、有効期間の短い署名付きURLを返すか、Content-Disposition: attachment、正確で安全なタイプ、X-Content-Type-Options: nosniffを付与してオブジェクトをストリーミングします。スキャナーの障害時はオブジェクトを利用不可のままにし、上限付きの再試行をトリガーします。クォータ、レート制限、同時実行数、タイムアウト、ライフサイクルクリーンアップによってリソースを抑制します。この設計をタイプ偽装、悪意あるファイル名、テスト用マルウェアサンプル、サイズ超過ストリーム、重複完了処理、オブジェクト置換、テナント間アクセスによって検証します。」
ステップバイステップの詳細解説
ステップ 1: 信頼境界とセキュリティ不変条件を定義する
クライアントは、すべてのマルチパートバイト列、ファイル名、Content-Type、申告サイズ、リクエスト順序を制御します。APIゲートウェイ、アプリケーションサービス、オブジェクトストレージイベント、スキャンキューも処理の重複、遅延、順序の入れ替わりを引き起こす可能性があります。以下の不変条件を中心に設計を構築します。
- 隔離オブジェクトにはパブリックな読み取りアクセス権がなく、Webサーバーによって実行されることはない。
- 認可された
AVAILABLEオブジェクトのみがダウンロード可能である。 - ビジネスレコードの
tenant_idは、自由に指定されたリクエストフィールドではなく、認証済みコンテキストから取得される。 - 元のファイル名がパス構築やオブジェクト検索に関与することは決してない。
- セキュリティ判定はイミュータブルなバイト列に紐付けられ、公開処理によってその判定が別のバージョンに引き継がれることはない。
- 例外、タイムアウト、判定不能な結果は常にフェイルクローズ（安全側に倒す）となる。
ファイル名をランダム化することと、オブジェクトを非公開に保つことは、別々の問題を解決します。ランダムなオブジェクトキーは上書き、パス操作、安易な推測を防ぎます。認可とプライベートストレージは機密性を提供します。設計には両方が必要です。
ステップ 2: ステートマシンにより受信と利用可能性を分離する
最小限のステートマシンは以下のとおりです。
PENDING_UPLOAD
├─ bytes verified ─> QUARANTINED ─> SCANNING
│ ├─ safe ─> AVAILABLE
│ ├─ malicious/invalid ─> REJECTED
│ └─ scanner unavailable ─> FAILED
└─ expired/abandoned ─> EXPIREDPOST /uploadsはセッションを作成し、upload_idを返します。直接アップロードの場合、指定された隔離オブジェクトにのみ書き込み可能な有効期間の短い認証情報も返します。POST /uploads/{id}/completeは信頼できる検証とスキャンをトリガーするため、202 Acceptedが適切です。GET /uploads/{id}はステータスを報告します。ダウンロードのエントリポイントはAVAILABLEに対してのみ現れます。
各状態遷移にはデータベースの条件を使用します。例えば、現在QUARANTINEDにあるレコードのみがSCANNINGに入ることができます。したがって、キューの重複配信やcomplete呼び出しの繰り返しがあっても、同じ遷移は最大で1回しか適用されません。FAILEDは技術的な処理失敗を意味し、REJECTEDはファイルまたはポリシーが無効であったことを意味します。これらを1つの曖昧なエラーにまとめると、復旧と監査の能力が低下します。
ステップ 3: バイト列を安全に受信し、リソースを制限する
セッション作成時に、アップロード権限、テナントの残りクォータ、ユーザーレート、要求されたビジネスフォーマットをチェックします。ランダムなupload_idと、quarantine/{tenant-id}/{uuid}のようなオブジェクトキーを生成します。元のファイル名は長さ、制御文字、Unicodeについて正規化し、表示用メタデータとしてのみ保持します。
APIがアップロードをプロキシする場合、バイト列を隔離ストレージへストリーミングし、読み取りながらカウントします。プロセス ché メモリ内にファイル全体をバッファリングするのではなく、20 MiBを超えた時点で即座に中止します。直接アップロードの場合、ストレージシステムが許す限り厳格に、メソッド、オブジェクトキー、有効期限、サイズで署名のスコープを絞り込みます。その後も信頼できるサービスがオブジェクトのメタデータを読み取り、実際の長さ、バージョン、所有権を検証します。クライアントの完了リクエストを決して信頼しません。
隔離バケットまたはディレクトリはデフォルトで非公開、実行不可、メインアプリケーションオリジンから分離され、最小権限の認証情報でアクセスされます。期限切れセッション、放棄されたアップロード、最終的なスキャン状態にはライフサイクルクリーンアップが必要であり、孤立したオブジェクトが無期限にクォータを消費しないようにします。
ステップ 4: タイプ検証、パース、悪意あるコンテンツのスキャンを組み合わせる
チェックは低コストなものから高コストなものへと実行できますが、単一のレイヤーだけでAVAILABLEをもたらすことはできません。
- 正規化された拡張子にPDF、JPEG、PNGの許可リストを適用する。
- クライアントの
Content-Typeはヒントとして扱う。明らかな不一致は拒否するが、証拠としては決して使用しない。 - 有効なマジックプレフィックスだけでは不十分であるため、シグネチャと完全な構造を検査する。
- 更新された制約付きパーサーを使用して、ファイル全体がパース可能であることを確認する。
- 隔離されたワーカーでマルウェアスキャンを実行し、エンジンとルールのバージョンを記録する。
- デコードされた画像を再エンコードし、リスクモデルで妥当とされる場合はPDFに対してコンテンツの無害化・再構築（CDR）を検討する。
スキャナーとパーサーは、攻撃者が制御可能なバイト列を処理します。CPU、メモリ、一時ディスク、時間、ネットワークアクセスが制限されたサンドボックス内で実行してください。このシナリオではアーカイブを拒否するため、解凍爆弾（高圧縮ファイル）、ネスト、アーカイブのパストラバーサルの分岐が排除されます。アンチウイルスは絶対的な安全性を証明するものではないため、ストレージの分離、安全な取得、最小限のパースが依然として必要です。
ステップ 5: 公開前に判定結果をイミュータブルなバイト列に紐付ける
スキャンジョブはイミュータブルな隔離version_idを読み取り、SHA-256を計算します。その結果には、少なくともupload_id、オブジェクトバージョン、ハッシュ、実際のサイズ、検出されたタイプ、スキャンエンジンのバージョン、判定結果が含まれます。
公開処理は条件付きデータベース遷移を実行します。レコードがSCANNINGになり得るには、依然としてAVAILABLEのままであり、そのオブジェクトバージョンとハッシュがスキャン入力と一致している必要があります。オブジェクトストレージ側でもそのバージョンが上書きされるのを防ぎます。システムがファイルを承認済みエリアにコピーする場合、ターゲットは新しいランダムキーを取得し、コピー操作は正確なソースバージョンを指定します。不一致があれば、古い判定を再利用するのではなく、再隔離または拒否を行います。
この紐付けにより、確認時と使用時の不一致（Time-of-Check to Time-of-Use: TOCTOU）ギャップを解消します。攻撃者が安全なバイト列をアップロードして合格結果を取得した後に、同じキーを悪意のあるバイト列に置き換えることはできません。ストレージのバージョニングがない場合は、1回書き込み（Write-Once）のオブジェクトキーまたはコンテンツアドレス指定ストレージを使用し、ビジネスレコードが最終的なイミュータブルオブジェクトのみを指すようにします。
ステップ 6: ダウンロードを認可し、ブラウザの解釈を制御する
GET /files/{id}/downloadは認証情報から現在のテナントを導出し、オブジェクトの所有権、ロール、削除状態、AVAILABLEステータスをチェックします。UUIDを使用しているからといって、これらのチェックを省くことはできません。認可後、アプリケーションはオブジェクトをストリーミングするか、1つのオブジェクトと操作に紐付けられた有効期間の短い署名付きURLを発行します。
プレビューを必要としない添付ファイルの場合、Content-Disposition: attachment、安全にエンコードされた表示ファイル名、サーバーが確認したメディアタイプ、X-Content-Type-Options: nosniffを返します。ファイルのオリジンをメインアプリケーションのクッキードメインから分離することで、アクティブコンテンツがプライマリセッションに影響を与える可能性を低減します。ユーザーの権限を変更しても既に発行されたURLが即座に失効するとは限らないため、署名付きURLの有効期間は短く保ちます。
取得パスには、レート制限と帯域幅制御、認可監査イベント、およびプロキシやキャッシュがプライベートレスポンスを保持できるかどうかに関する明示的な決定も必要です。ログにはオブジェクトID、テナント、アクター、結果を含めますが、ファイル内容や再利用可能な署名付きURLは含めません。
ステップ 7: 障害、冪等性、クォータ、可観測性を設計する
スキャンがタイムアウトしたか利用できない場合、ファイルは利用不可のままとなります。ワーカーはバックオフを伴う上限付きの回数で再試行できます。再試行を使い果たすと、制御された手動または自動の復旧のためにFAILEDに入ります。明確に悪意があるか構造的に無効な結果はREJECTEDに入り、隔離バイト列は保持ポリシーに従って削除されます。
作成エンドポイントは冪等性キーを受け入れることができるため、クライアントのタイムアウトによって複数のセッションが作成されるのを防ぎます。完了、スキャン結果の消費、削除では、冪等性を確保するために条件付き状態遷移を使用します。同時実行制限は、ユーザーごとのアップロード、テナントの総バイト数、ファイルごとのサイズ、キューの深さ、テナントごとのスキャンスロットをカバーし、1つのテナントがグローバルな容量を独占できないようにします。
有用なメトリクスには、各状態の滞在時間、隔離バイト数、期限切れセッション、スキャンの合格/拒否/失敗率、再試行回数、キューの滞留時間、パーサーのタイムアウト、テナント間拒否、ダウンロード認可の失敗が含まれます。監査イベントには遷移、オブジェクトバージョン、ハッシュ、ポリシー、スキャナーバージョンが記録され、オペレーターが「どの正確なバイト列がどのルールに基づいて判定されたか」を回答できるようにします。
ステップ 8: 敵対的マトリクスで完全なパスを検証する
最低限、以下をテストします。
.jpg.php、大文字小文字の混在、Nullバイト、サイズ超過のUnicodeファイル名- 偽装された
Content-Type、有効なプレフィックスと悪意ある末尾を持つファイル、不正な形式のPDF、ポリグロットファイル - 安全な環境でのEICARテストファイル、およびパーサーのタイムアウトやリソース制限に達するサンプル
- ちょうど20 MiB、1バイト超過、長さヘッダー欠落、低速ストリーム、多数の同時アップロード
- 同一の冪等性キー、同時完了呼び出し、重複キューメッセージ、古いスキャン結果
- スキャン中のオブジェクト置換試行（バージョンまたはハッシュの不一致により公開できないことの証明）
- 別のテナントによるステータス読み取り、ダウンロード、削除の試行（すべてのリクエストが拒否されること）
- スキャナーの停止、ジョブのタイムアウト、アプリケーションの再起動、孤立オブジェクトのクリーンアップ
- 添付ファイル、メディアタイプ、
nosniff、キャッシュ、署名付きURLの有効期限に関するダウンロード動作
合格基準はセキュリティとビジネス上の正確性の両立です。拒否されたファイルにダウンロードパスが決して提供されないこと、安全なファイルが最終的に利用可能になること、再試行によって重複レコードが作成されないこと、未認可リクエストからデータが漏洩しないこと、障害時にフェイルクローズが維持されること、リソース使用量が制限内に収まること、監査証跡から決定チェーン全体が再構築できることです。
優れた回答例
「私はアップロードを隔離、判定、公開の各ステージに分割し、判定を通過していないバイト列をビジネスユーザーが読み取ることは決してできないという不変条件を設けます。セッション作成時、認証からtenant_idを導出し、ロール、20 MiBの制限、テナントクォータ、PDF/JPEG/PNGの許可リストをチェックし、ランダムで上書き不可能な隔離キーを生成します。元のファイル名は、長さ制限のある正規化された表示用メタデータとしてのみ保持します。
バイト列はAPI経由でストリーミングするか、その隔離キーにスコープされた有効期間の短い認証情報を使用します。完了時、サーバーは実際のサイズ、オブジェクトバージョン、所有権を検証し、レコードをPENDING_UPLOADからQUARANTINEDへ条件付きで移動させ、非同期でスキャンします。検証では拡張子、サーバー検出タイプ、完全な構造パース、マルウェアスキャン、適切な再エンコードを組み合わせます。スキャナーは制限されたリソースとネットワークアクセス下で動作します。
スキャナーはイミュータブルなバージョンを読み取り、SHA-256を計算します。レコードがAVAILABLEになり得るのは、依然としてSCANNINGであり、バージョンとハッシュの両方がスキャン入力と一致している場合のみです。したがって、スキャン後に安全なファイルを差し替えても古い判定を再利用することはできません。スキャナー障害時は上限付きの再試行を伴いフェイルクローズとなり、明確に悪意があるか適合しないコンテンツはREJECTEDになります。
すべてのダウンロードは、ストリーミングまたは有効期間の短いURLを発行する前に、テナント、オブジェクト権限、AVAILABLEステータスをチェックします。添付ファイルには隔離されたオリジン、Content-Disposition: attachment、X-Content-Type-Options: nosniffを使用します。その後、状態の滞留時間、隔離バイト数、キューの滞留時間、スキャナーバージョンを監視しながら、タイプ偽装、EICAR、サイズ超過ストリーム、重複完了処理、オブジェクト置換の競合、テナント間読み取り、スキャナー障害をテストします。」
よくある間違い
- 拡張子のみをチェックする → 二重拡張子、大文字小文字の変更、偽装されたコンテンツによってバイパスされる → ビジネス許可リスト、正規化、シグネチャ、構造パース、スキャンを組み合わせる。
Content-Typeを信頼する → クライアントはリクエストヘッダーを自由に選択できる → 初期フィルタリングにのみ使用し、最終的なタイプはサーバー側で検出する。- 元のファイル名をパスとして使用する → パストラバーサル、上書き、ファイルシステムの正規化バグが発生可能になる → ランダムなオブジェクトキーを生成し、名前は制限されたメタデータとしてのみ保持する。
- 保存されたバイト列を即座にダウンロード可能にする → スキャン完了前に悪意のあるバイト列が公開されてしまう → 隔離を使用し、
AVAILABLEを唯一の公開条件とする。 - アンチウイルス通過で安全性が保証されると主張する → 新種のサンプル、パーサーのバグ、アクティブコンテンツのリスクは残る → 隔離、最小限のパース、安全なヘッダー、認可を維持する。
- 上書き可能なキーをスキャンする → 合格結果が後から置換されたバイト列に適用される可能性がある → イミュータブルなバージョンまたはコンテンツハッシュを紐付け、条件付きで公開する。
- UUIDを認可とみなす → オブジェクトIDの漏洩によってテナント間読み取りが可能になる場合がある → ステータス確認、ダウンロード、削除に対してオブジェクト認可を実行する。
- 直接アップロード後のクライアント完了通知を信頼する → クライアントはサイズ、タイプ、所有権について虚偽の申告ができる → サーバー側で信頼できるオブジェクトメタデータとバイト列の証拠を読み取る。
- スキャナー障害時にフェイルオープンにする → インフラ障害がセキュリティバイパスにつながる → フェイルクローズにし、制限内で再試行し、正確な処理中状態を開示する。
- ファイルごとのサイズのみを制限する → 単体では有効な多数のファイルによってストレージとスキャンが枯渇する可能性がある → テナントクォータ、レート、同時実行数、キューのバックプレッシャーを適用する。
- 任意のファイルをプライマリオリジン上でインラインレンダリングする → ブラウザの解釈やアクティブコンテンツがメインセッションに影響を与える可能性がある → デフォルトで添付ファイルダウンロードとし、ファイルのオリジンを分離する。
フォローアップの質問と回答
フォローアップ 1: マジックバイトを既にチェックしているのに、なぜ完全な構造パースを行うのですか？
シグネチャは通常、先頭の数バイトしかカバーしません。攻撃者は有効なヘッダーの後に別のフォーマットを配置したり、複数のパーサーに受け入れられるファイルを構築したりできます。完全な構造パースでは、内部の長さ、関係性、終端マーカーをチェックします。パーサーは依然として信頼できない入力を処理するため、最新の状態に保ち、リソースを制限し、隔離しておく必要があります。
フォローアップ 2: オブジェクトストレージへの直接アップロードはバックエンドのセキュリティをバイパスしますか？
バイト転送の経路が変わるだけです。バックエンドは依然としてテナントとオブジェクトキーに紐付けられた有効期間の短いセッションを作成し、その認証情報は隔離領域への書き込みしか行えません。その後、スキャン前にバックエンドが実際のオブジェクト、サイズ、バージョン、ハッシュを検証します。オブジェクトにはAVAILABLEの前に読み取り権限がないため、直接アップロードによって直接公開されることはありません。
フォローアップ 3: スキャナー障害時のユーザー体験はどうあるべきですか？
完了エンドポイントは処理中状態を返し、ステータスエンドポイントはセキュリティチェックが継続中であるか、処理が失敗して再試行可能であることを報告します。システムは上限付きのバックオフで再試行し、キューの滞留時間を監視します。しきい値を超えると、レコードはFAILEDに入り、利用不可のままとなります。復旧処理は制御されたパスを通じて同じイミュータブルバージョンを再試行します。判定をスキップして利用可能になることは決してありません。
フォローアップ 4: なぜダウンロード時に依然としてattachmentとnosniffが必要なのですか？
認可は誰がバイト列を受け取るかを決定します。レスポンスヘッダーはブラウザがそれをどう解釈するかに影響します。attachmentはダウンロードを強制し、nosniffはブラウザがコンテンツスニッフィングによってサーバーが宣言したタイプを上書きするのを防ぎます。隔離されたファイルオリジンは、アクティブコンテンツがメインアプリケーションのクッキーやスクリプトコンテキストにアクセスするのをさらに制限します。
フォローアップ 5: ZIPを許可する場合、どのような制御が必要になりますか？
隔離されたサンドボックス内で各メンバーのパスを検査し、絶対パスと..を拒否し、ネストの深さ、メンバー数、個別のサイズ、合計展開サイズ、圧縮率、CPU、時間を制限します。展開されたすべてのメンバーに対して、タイプチェックと悪意あるコンテンツのチェックを再度実行します。このシナリオにはZIPの要件がないため、拒否する方が攻撃対象領域を小さく抑えられます。
フォローアップ 6: 競合によって判定結果が汚染されなかったことをどのように証明しますか？
スキャンジョブに入力イミュータブルバージョンとSHA-256を記録します。公開処理では、現在のレコードがまさにそのバージョンとハッシュのままSCANNINGであることを要求する条件付きデータベース更新を使用します。テストではスキャン中に論理オブジェクトを上書きして古い結果を配信し、公開が失敗することを確認します。監査イベントによって、入力バージョン、判定結果、最終的に承認されたオブジェクトを紐付けます。