Desain Keamanan Portal Operasional B2B: Enkripsi Sesi, RBAC Terperinci, dan Audit Trail Imutabel

Vektor Ancaman dan Karakteristik Portal Operasional B2B

Portal operasional Business-to-Business (B2B) untuk manajemen armada logistik dan personel mengelola telemetri real-time, rute distribusi, jadwal kerja pengemudi, serta kontrol operasional aset fisik. Ancaman keamanan pada sistem ini berbeda dengan aplikasi konsumen biasa. Serangan tidak hanya menargetkan pencurian kredensial individu, melainkan infiltrasi sesi operasional untuk melakukan manipulasi data rute, eskalasi hak akses horizontal antar-penyewa (multi-tenant cross-tenant access), serta sabotase logistik.

Vektor serangan utama mencakup:

1. Pembajakan Sesi (Session Hijacking): Pencurian token otentikasi melalui serangan Cross-Site Scripting (XSS), inspeksi paket jaringan tidak terenkripsi, atau eksfiltrasi dari local storage peramban.
2. Injeksi Parameter Otorisasi: Manipulasi identifier tenant atau parameter peran pada level Application Programming Interface (API) akibat ketiadaan validasi hak akses berbasis konteks (contextual access control).
3. Manipulasi Jejak Transaksi: Penghapusan atau perubahan catatan modifikasi rute berbahaya tanpa jejak identitas operator yang dapat diverifikasi secara forensik.

Keamanan portal operasional B2B menuntut pendekatan defense-in-depth. Pendekatan ini memisahkan lapisan otorisasi, mengenkripsi pertukaran status sesi dengan protokol kriptografi modern, dan menegakkan pencatatan mutlak (append-only transactional logging).

+-----------------------------------------------------------------------------+
|                        PORTAL OPERASIONAL B2B                               |
+-----------------------------------------------------------------------------+
       |                                                     |
       v                                                     v
[ Client Browser ]                                  [ Operational API ]
       |                                                     |
       |-- 1. TLS 1.3 / DPoP Proof Token ------------------->|
       |-- 2. HttpOnly, Secure, SameSite=Strict Cookie ----->|
       |                                                     |-- Enforce RBAC/ABAC
       |                                                     |-- Dynamic PDP/PEP Check
       |                                                     v
+-----------------------------------------------------------------------------+
|                        BACKEND INFRASTRUCTURE                               |
+-----------------------------------------------------------------------------+
|  [ API Gateway / PEP ] <---> [ Identity Provider (OAuth 2.0 / OIDC) ]        |
|            |                                                                |
|            v                                                                |
|  [ Core Fleet Service ] ---> [ Redis (Token Blacklist / Sliding Session) ]  |
|            |                                                                |
|            v                                                                |
|  [ PostgreSQL DB ] --------> [ Audit Trail (HMAC Hash Chaining / WORM S3) ] |
+-----------------------------------------------------------------------------+

Pemisahan Hak Akses: Desain Hierarki RBAC dan Dynamic Policy Enforcement

Sistem manajemen armada melibatkan struktur peran hierarkis: Super Administrator, Fleet Dispatcher, Safety Officer, Maintenance Technician, hingga Third-Party Driver. Model Role-Based Access Control (RBAC) konvensional yang memetakan pengguna langsung ke satu peran statis tidak memadai untuk sistem B2B multi-tenant.

Skema Relasional Hierarchical Role-Based Access Control (HRBAC)

Pemisahan hak akses memerlukan pemisahan eksplisit antara identitas (Subject), entitas izin (Permission), peran operasional (Role), dan batasan penyewa (Tenant Scope). Skema basis data relasional di bawah memastikan integritas batasan multi-tenant:

-- Definisi izin granular
CREATE TABLE permissions (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    action VARCHAR(64) NOT NULL,       -- Contoh: 'fleet:dispatch', 'driver:telemetry:read'
    resource VARCHAR(64) NOT NULL,
    description TEXT
);

-- Definisi peran organisasi
CREATE TABLE roles (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id UUID NOT NULL,
    name VARCHAR(32) NOT NULL,
    parent_role_id UUID REFERENCES roles(id),
    created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
    UNIQUE(tenant_id, name)
);

-- Pemetaan relasi peran dan izin
CREATE TABLE role_permissions (
    role_id UUID REFERENCES roles(id) ON DELETE CASCADE,
    permission_id UUID REFERENCES permissions(id) ON DELETE CASCADE,
    PRIMARY KEY (role_id, permission_id)
);

-- Asosiasi pengguna terhadap peran dengan batasan geofence/unit
CREATE TABLE user_roles (
    user_id UUID NOT NULL,
    role_id UUID REFERENCES roles(id) ON DELETE CASCADE,
    tenant_id UUID NOT NULL,
    scope_constraints JSONB DEFAULT '{}'::jsonb, -- Contoh: {"assigned_depot": ["JKT-01", "BDG-02"]}
    PRIMARY KEY (user_id, role_id, tenant_id)
);

Arsitektur Evaluasi Otorisasi (PDP dan PEP)

Dalam portal operasional terdistribusi, evaluasi izin menggunakan arsitektur Policy Enforcement Point (PEP) pada API Gateway dan Policy Decision Point (PDP) berbasis engine kebijakan deklaratif seperti Open Policy Agent (OPA).

1. Policy Enforcement Point (PEP): Mencegat setiap request HTTP/gRPC. PEP mengekstrak JWT (JSON Web Token) dari klien, memvalidasi tanda tangan kriptografi via kunci publik IDP (OAuth 2.0 / OIDC), dan mengisolasi metadata penyewa (tenant_id).
2. Policy Decision Point (PDP): Menerima payload kontekstual dari PEP yang berisi: {user_id, tenant_id, action, resource, target_depot, client_ip}. PDP mencocokkan parameter tersebut terhadap aturan kebijakan deklaratif. Jika Fleet Dispatcher mencoba mengubah status kendaraan di luar depo yang terdaftar pada scope_constraints, PDP mengembalikan keputusan DENY secara independen dari logika bisnis servis.

Format token akses harus membatasi ukuran klaim (claims bloating). Alih-alih menyematkan seluruh daftar izin ke dalam token JWT, token hanya membawa identifikasi peran dan hak akses global. Izin granular dievaluasi melalui sinkronisasi cache terdistribusi (Redis) pada sisi server dengan waktu latensi p99 di bawah 2 milidetik.

Mitigasi Session Hijacking: Kriptografi Sesi dan Demonstrating Proof-of-Possession

Model otentikasi berbasis bearer token standar rentan terhadap session hijacking. Siapa pun yang mendapatkan token tersebut dapat bertindak atas nama pengguna tanpa validasi kepemilikan fisik kunci.

Implementasi Demonstrating Proof-of-Possession (DPoP - RFC 9449)

Portal operasional menerapkan DPoP untuk mengikat token akses dengan pasangan kunci asimetris privat-publik yang dibuat langsung di peramban klien via Web Cryptography API.

[ Client Browser ]                         [ Auth Server / Gateway ]
        |                                              |
        | 1. Generate Ephemeral Keypair (ES256)        |
        | 2. Create DPoP Proof Header (Signed by PrivKey) 
        |    Payload: { htm: 'POST', htu: '/api/v1/dispatch', jti: '...' }
        |--------------------------------------------->|
        |                                              | 3. Verify DPoP Proof Sig
        |                                              | 4. Validate Binding: 
        |                                              |    Hash(PubKey) == Token.jkt
        |                                              | 5. Process Request
        |<---------------------------------------------|

Alur kerja pengikatan sesi:

1. Inisialisasi Kunci: Saat inisialisasi sesi, klien menghasilkan pasangan kunci elliptic curve (ECDSA P-256) yang bersifat non-exportable di memori peramban.
2. Pembuatan DPoP Proof: Setiap request ke API Gateway harus menyertakan header HTTP DPoP. Header ini berupa JWT mini yang ditandatangani oleh kunci privat klien, berisi thumbprint waktu (iat), URI tujuan (htu), metode HTTP (htm), dan nonce acak (jti).
3. Validasi Gateway: API Gateway memverifikasi kecocokan antara kunci publik pada header DPoP dengan klaim JSON Web Key Thumbprint (jkt) yang tertanam secara permanen di dalam Access Token.

Jika penyerang menyadap bearer token dari lalu lintas jaringan, token tersebut tidak dapat digunakan dari mesin lain tanpa kunci privat milik klien yang sah.

Strategi Penyimpanan Token dan Rotasi Refresh Token

Untuk memitigasi ekstraksi token melalui kerentanan Cross-Site Scripting (XSS):

• Refresh Token: Disimpan secara eksklusif dalam cookie HTTP dengan atribut HttpOnly; Secure; SameSite=Strict; Path=/auth/v1/refresh. Cookie ini tidak dapat diakses melalui skrip document.cookie di sisi klien.
• Access Token: Disimpan secara volatil di memori aplikasi peramban (JavaScript closure state) tanpa menyentuh localStorage atau sessionStorage.
• Refresh Token Family & Sliding Expiration: Setiap kali klien meminta penyegaran token akses, refresh token lama langsung dicabut (invalidated), dan refresh token baru diterbitkan dalam sebuah rantai asosiasi (token family). Jika sebuah refresh token lama digunakan kembali (menandakan adanya duplikasi token oleh penyerang), sistem secara otomatis mencabut seluruh sesi operasional milik pengguna tersebut dalam basis data sesi terdistribusi:

// Verifikasi rotasi token pada server otentikasi
async function handleTokenRotation(providedRefreshToken: string): Promise<TokenPair> {
    const tokenRecord = await db.tokens.findUnique({ where: { token: hash(providedRefreshToken) } });
    
    if (!tokenRecord) {
        throw new SecurityException('Invalid session token');
    }

    if (tokenRecord.isRevoked) {
        // Deteksi penggunaan berulang: Hapus seluruh token dalam family ini
        await db.tokens.updateMany({
            where: { familyId: tokenRecord.familyId },
            data: { isRevoked: true }
        });
        await redisCluster.del(`session:${tokenRecord.userId}`);
        throw new SecurityException('Compromised session detected. All sessions revoked.');
    }

    // Terbitkan pasangan token baru dan nonaktifkan token saat ini
    await db.tokens.update({
        where: { id: tokenRecord.id },
        data: { isRevoked: true }
    });

    return generateNewTokenPair(tokenRecord.userId, tokenRecord.familyId);
}

Audit Logging Transaksional dan Integritas Jejak Data Mutlak

Keamanan portal B2B memerlukan akuntabilitas hukum dan operasional (non-repudiation). Modifikasi terhadap data armada—seperti penonaktifan sensor keselamatan, modifikasi koordinat geofence, pengalihan pengemudi, atau persetujuan dokumen logistik—harus dicatat secara presisi tanpa toleransi kehilangan data.

Struktur Skema Audit Log Kontekstual

Log audit tidak boleh dicampur dengan log aplikasi generik (stdout/stderr). Pencatatan dilakukan secara terstruktur menggunakan skema berikut:

{
  "event_id": "d3b07384-d113-4965-b1a7-0e620577da3b",
  "timestamp": "2023-10-24T08:14:22.104Z",
  "tenant_id": "a9c4033b-826d-4d22-8051-789a74c7dbb1",
  "actor": {
    "user_id": "f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
    "role": "Fleet_Supervisor",
    "ip_address": "103.111.201.4",
    "user_agent": "Mozilla/5.0 ... EnterprisePortal/2.4"
  },
  "action": "ROUTE_OVERRIDE",
  "resource": {
    "type": "VehicleRoute",
    "id": "TRK-8821-EXP"
  },
  "state_change": {
    "before": { "destination": "DEPOT_SURABAYA", "max_speed_limit": 80 },
    "after": { "destination": "DEPOT_SEMARANG", "max_speed_limit": 100 }
  },
  "context": {
    "reason": "Jalur logistik utama tertutup tanah longsor",
    "authorization_ticket": "TCK-99021"
  },
  "crypto_signature": "MEQCICvGZ...d3F="
}

Mekanisme Kriptografis Immutability (Hash Chaining)

Untuk menjamin bahwa data log audit tidak dimanipulasi secara internal oleh administrator basis data yang korup, tabel audit diimplementasikan menggunakan arsitektur hash chaining linear (mirip prinsip Merkle DAG).

Setiap baris audit log memuat nilai hash dari rekaman sebelumnya:

$$\text{Hash}{n} = \text{HMAC-SHA256}(\text{Payload}{n} + \text{Hash}{n-1}, K{\text{audit}})$$

Di mana $K_{\text{audit}}$ adalah kunci rahasia yang disimpan secara terisolasi pada Hardware Security Module (HSM) atau Key Management Service (KMS). Setiap upaya modifikasi rekaman historis $\text{Payload}_{n-1}$ akan merusak validitas verifikasi rantai hash hingga ke baris audit terbaru.

Secara terjadwal (setiap 60 menit), snapshot blok rantai log ini diekspor ke penyimpanan Write-Once-Read-Many (WORM) seperti Amazon S3 Object Lock dalam mode COMPLIANCE. Dengan konfigurasi ini, log audit terlindungi secara fisik dari operasi perubahan atau penghapusan oleh pengguna mana pun, termasuk akun root cloud provider, hingga batas retensi retensi legal berakhir.

Kesimpulan Rekayasa Sistem

Desain keamanan portal operasional B2B menolak kompromi antara kenyamanan pengguna dan ketahanan sistem. Perlindungan sistem armada dan logistik memerlukan implementasi tiga pilar arsitektur:

1. Otorisasi hierarkis granular (HRBAC) yang dievaluasi secara dinamis pada batas gateway API dengan pemisahan tenant yang ketat.
2. Proteksi sesi mutakhir melalui DPoP (RFC 9449) dan manajemen cookie HttpOnly dengan rotasi refresh token, menghilangkan ancaman pembajakan sesi akibat eksfiltrasi bearer token.
3. Audit trail terstruktur yang diikat secara kriptografis menggunakan hash chaining dan proteksi penyimpanan WORM untuk memastikan akuntabilitas forensik penuh.

Ketiga mekanisme ini membentuk fondasi pertahanan berlapis yang memastikan integritas operasional, kerahasiaan data armada, dan kepatuhan terhadap standar keamanan enterprise.