Dilema Egress Cloud: Throughput Lokal vs Otorisasi Sentral

Memindahkan volume data besar antar-perangkat—seperti migrasi profil pengguna, basis data lokal, atau backup media—menghadapi benturan antara efisiensi biaya dan integritas sistem. Pendekatan konvensional Centralized Cloud Relay mengalirkan seluruh muatan data (payload) dari perangkat sumber ke penyimpanan awan, lalu mengunduhnya kembali ke perangkat target. Pola ini menjamin kendali penuh pada lapisan otorisasi dan auditabilitas, tetapi memicu beban operasional berupa pembengkakan biaya data egress dan latensi transfer yang dibatasi bandwidth WAN.

Pendekatan alternatif menggunakan transmisi langsung Device-to-Device (P2P/LAN via Wi-Fi Direct atau Gigabit Ethernet) melenyapkan biaya egress cloud dan memaksimalkan throughput pada kecepatan jaringan lokal. Namun, pengalihan jalur data ke P2P murni membuka kerentanan pada trust boundary. Tanpa server pusat yang memvalidasi setiap tahapan transaksi, integritas migrasi rawan dirusak oleh manipulasi klien lokal, seperti insiden bypass lisensi atau bypass activation lock pada restorasi data luring.

Komparasi Arsitektur: Cloud Relay vs P2P Murni vs Hybrid Split

Tiga pola arsitektur utama untuk menangani migrasi data berskala besar:

  • Centralized Cloud Relay: Data plane dan control plane berada di cloud. Klien mengunggah data ke object storage (misalnya S3), lalu target mengunduhnya. Aman dan mudah diaudit, tetapi biaya egress berbanding lurus dengan ukuran data (O(N)), serta transfer dibatasi kapasitas uplink internet klien.
  • Pure P2P (Ad-hoc Local): Data plane dan control plane berjalan langsung antar-klien tanpa melibatkan infrastruktur backend. Menghasilkan throughput maksimal dan biaya nol, tetapi tidak memiliki single source of truth. Status entitas rentan dimanipulasi melalui modifikasi runtime pada perangkat target.
  • Hybrid Control-Data Plane Split: Data plane dialihkan sepenuhnya ke jaringan lokal (P2P), sedangkan control plane (inisiasi, pertukaran kunci, audit manifest data, dan atomic commit) tetap dikendalikan oleh auth server sentral.

Pola Arsitektur: Hybrid Control-Data Plane Split

Solusi optimal memisahkan jalur data bervolume tinggi dari jalur validasi status. Data plane mentransmisikan chunk biner terenkripsi langsung antar-perangkat, sedangkan control plane bertugas menerbitkan tantangan kriptografi (cryptographic challenge) dan memverifikasi integritas sebelum status baru dinyatakan sah di database pusat.

Diagram Alur Transaksi

Source Device               Target Device               Central Auth Server
      |                           |                              |
      |--- 1. Request Session --->|                              |
      |                           |--- 2. Init Migration ------->|
      |                           |<-- 3. Session Nonce + Key ---|
      |<-- 4. Handshake (mTLS) -->|                              |
      |                           |                              |
      |=== 5. P2P Data Stream ===>|                              |
      |    (Encrypted Chunks)     |                              |
      |                           |                              |
      |                           |--- 6. Attestation + Root --->|
      |                           |       Merkle Hash Payload    |
      |                           |                              |
      |                           |<-- 7. Signed Commit Token ---|
      |                           |       (Atomic Finalization)  |
      |                           |                              |
      |                           |--- 8. Ack Complete --------->|

Tahapan eksekusi pada diagram di atas:

  1. Inisiasi Sesi: Perangkat target meminta otorisasi migrasi ke server sentral dengan menyertakan identitas unik perangkat keras (hardware attestation) kedua perangkat.
  2. Penerbitan Kunci Efemeral: Server mengeluarkan pasangan token sesi, nonce unik berbatas waktu, dan shared secret untuk enkripsi transport P2P (mTLS/Noise Protocol).
  3. Transfer Data Lokal: Data payload dipecah menjadi blok-blok kecil, dienkripsi, dan ditransfer via TCP/QUIC lokal. Target menyusun Merkle Tree dari seluruh chunk yang diterima.
  4. Validasi dan Cryptographic Attestation: Setelah transfer selesai, target mengirimkan root hash Merkle Tree beserta bukti kriptografi ke server sentral. Server memvalidasi hash tersebut terhadap status sumber dan memastikan perangkat target tidak sedang dalam status terkunci atau terblokir.
  5. Atomic Commit: Server menerbitkan Signed Commit Token (berbasis asymmetric key backend). Klien target hanya dapat membuka kunci penyimpanan lokal dan memperbarui status aplikasi jika token tersebut terverifikasi secara valid.

Implementasi: Validasi Attestation dan Atomic Commit

Contoh berikut mengilustrasikan logika verifikasi pada backend (Go) untuk memvalidasi token attestation migrasi sebelum mengizinkan pembaruan status sistem:

package main

import (
	"crypto"
	"crypto/rsa"
	"crypto/sha256"
	"crypto/x509"
	"encoding/hex"
	"encoding/pem"
	"errors"
	"fmt"
	"time"
)

type MigrationCommitRequest struct {
	SessionID        string `json:"session_id"`
	TargetDeviceID   string `json:"target_device_id"`
	MerkleRootHash   string `json:"merkle_root_hash"`
	ClientTimestamp  int64  `json:"client_timestamp"`
	ClientSignature  []byte `json:"client_signature"`
}

type CentralAuthorizer struct {
	serverPrivateKey *rsa.PrivateKey
}

func (ca *CentralAuthorizer) AuthorizeCommit(
	req MigrationCommitRequest,
	targetPubKeyPEM []byte,
	expectedMerkleRoot string,
) (string, error) {
	// 1. Validasi batas waktu (mencegah replay attack)
	now := time.Now().Unix()
	if now-req.ClientTimestamp > 300 || req.ClientTimestamp > now+60 {
		return "", errors.New("timestamp out of acceptable tolerance window")
	}

	// 2. Validasi integritas data plane via Merkle Root
	if req.MerkleRootHash != expectedMerkleRoot {
		return "", errors.New("merkle root mismatch: data corrupted or tampered")
	}

	// 3. Verifikasi signature perangkat target
	block, _ := pem.Decode(targetPubKeyPEM)
	if block == nil {
		return "", errors.New("invalid target public key pem")
	}
	pubInterface, err := x509.ParsePKIXPublicKey(block.Bytes)
	if err != nil {
		return "", err
	}
	targetPubKey := pubInterface.(*rsa.PublicKey)

	payloadMessage := fmt.Sprintf("%s:%s:%s:%d",
		req.SessionID, req.TargetDeviceID, req.MerkleRootHash, req.ClientTimestamp)
	hashedPayload := sha256.Sum256([]byte(payloadMessage))

	err = rsa.VerifyPKCS1v15(targetPubKey, crypto.SHA256, hashedPayload[:], req.ClientSignature)
	if err != nil {
		return "", fmt.Errorf("invalid device signature: %w", err)
	}

	// 4. Terbitkan signed finalize token (hanya backend yang bisa membuat ini)
	commitPayload := fmt.Sprintf("COMMIT:%s:%s:%d", req.SessionID, req.TargetDeviceID, now)
	hashedCommit := sha256.Sum256([]byte(commitPayload))
	signedToken, err := rsa.SignPKCS1v15(nil, ca.serverPrivateKey, crypto.SHA256, hashedCommit[:])
	if err != nil {
		return "", fmt.Errorf("failed to sign commit token: %w", err)
	}

	return hex.EncodeToString(signedToken), nil
}

Kalkulasi Finansial: Egress Cloud vs Latensi Verifikasi

Evaluasi trade-off berikut memperlihatkan dampak efisiensi biaya terhadap latensi sistem saat memindahkan data 100.000 pengguna dengan rata-rata ukuran payload 25 GB per sesi migrasi:

  • Total Volume Data: 100.000 × 25 GB = 2.500.000 GB (2,5 PB).
  • Biaya Cloud Relay: Dengan asumsi tarif transfer data keluar (egress) standar industri rata-rata $0,085 per GB, total biaya bandwidth awan: 2.500.000 GB × $0,085 = $212.500.
  • Biaya Hybrid P2P: Payload 25 GB ditransfer lokal tanpa menyentuh WAN. Backend hanya bertukar metadata sesi, payload tantangan kriptografi, dan token komit (rata-rata ~8 KB per sesi). Total egress ke cloud: 100.000 × 8 KB ≈ 800 MB. Biaya egress backend kurang dari $0,10.
  • Overhead Latensi: Pola hybrid membutuhkan pertukaran kontrol tambahan (handshake awal dan verifikasi akhir). Latensi kontrol plane sentral menambahkan overhead sekitar 120 ms - 300 ms (tergantung round-trip time ke server auth), namun kecepatan transmisi data lokal meningkat dari rata-rata WAN (20-50 Mbps) ke LAN (500-1.000 Mbps).

Rekomendasi Maintainability dan Penanganan Kegagalan

Menerapkan arsitektur hybrid membutuhkan pertimbangan operasional berikut:

  1. Idempotensi dan Chunk Resumption: Jaringan P2P nirkabel rentan terhadap gangguan sinyal lokal. Format penyimpanan sementara di perangkat target wajib mendukung penulisan berbasis offset chunk yang terindeks (sparse file) dan memiliki state mesin lokal untuk melanjutkan transfer tanpa memulai dari awal.
  2. Pencegahan Split-Brain State: Jangan pernah mengizinkan perangkat sumber menghapus data lokalnya sebelum backend sentral menerima konfirmasi Ack Complete dari perangkat target beserta validasi token commit.
  3. Fallback Graceful ke Relay: Pada kondisi jaringan tertentu (seperti isolasi subnet LAN atau konfigurasi router yang memblokir direct client isolation), sediakan mekanisme fallback otomatis ke cloud relay terenkripsi, dengan batas kuota khusus untuk mencegah kebocoran biaya tidak terduga.