Business Continuity

Pengantar

Business Continuity adalah kemampuan organisasi untuk melanjutkan operasi bisnis pada tingkat yang telah ditentukan sebelumnya setelah terjadi insiden atau gangguan. Dalam konteks keamanan siber, Business Continuity Planning (BCP) memastikan bahwa meskipun sistem sedang dalam proses recovery, layanan bisnis tetap berjalan - mungkin dengan kapasitas terbatas - sehingga kerugian finansial dan reputasi dapat diminimalkan.

Berbeda dengan Disaster Recovery yang berfokus pada pemulihan infrastruktur TI, Business Continuity memiliki cakupan yang lebih luas: mencakup proses bisnis, sumber daya manusia, fasilitas fisik, supply chain, dan komunikasi dengan pemangku kepentingan. Keduanya saling melengkapi dan harus diintegrasikan dalam satu kerangka kerja yang kohesif.

Komponen Utama Business Continuity

BCP (Business Continuity Planning)

BCP adalah dokumen induk yang mendefinisikan:

• Tujuan dan ruang lingkup - Sistem dan proses apa saja yang dicakup.
• Peran dan tanggung jawab - Siapa yang melakukan apa saat krisis.
• Prosedur aktivasi - Kapan BCP diaktifkan dan siapa yang berwenang.
• Strategi kontinuitas - Bagaimana bisnis tetap berjalan saat insiden.
• Rencana komunikasi - Kepada siapa, kapan, dan bagaimana informasi disampaikan.
• Jadwal pengujian - Kapan BCP diuji dan dievaluasi.

Template struktur dokumen BCP:

# BUSINESS CONTINUITY PLAN

## 1.0 Pendahuluan
- 1.1 Tujuan Dokumen
- 1.2 Ruang Lingkup
- 1.3 Asumsi dan Keterbatasan

## 2.0 Informasi Organisasi
- 2.1 Profil Perusahaan
- 2.2 Kontak Darurat
- 2.3 Lokasi dan Fasilitas

## 3.0 Business Impact Analysis (BIA)
- 3.1 Inventaris Proses Bisnis
- 3.2 Prioritas Pemulihan
- 3.3 RTO dan RPO

## 4.0 Strategi Kontinuitas
- 4.1 Strategi TI
- 4.2 Strategi Non-TI (manual workaround)
- 4.3 Strategi Sumber Daya Manusia

## 5.0 Prosedur Aktivasi
- 5.1 Kriteria Aktivasi
- 5.2 Rantai Komando
- 5.3 Prosedur Eskalasi

## 6.0 Rencana Komunikasi
- 6.1 Internal Communication
- 6.2 External Communication
- 6.3 Regulatory Reporting

## 7.0 Pengujian dan Pemeliharaan
- 7.1 Jadwal Pengujian
- 7.2 Prosedur Update
- 7.3 Audit Internal

## 8.0 Lampiran
- A: Daftar Kontak Darurat
- B: Diagram Infrastruktur
- C: SLA Vendor

BIA (Business Impact Analysis)

BIA adalah proses untuk mengidentifikasi dan mengevaluasi dampak potensial dari gangguan terhadap operasi bisnis. Hasil BIA menjadi dasar penentuan prioritas pemulihan.

Langkah-langkah BIA:

1. Identifikasi proses bisnis kritis - Apa yang esensial untuk kelangsungan organisasi?
2. Tentukan dampak finansial - Berapa kerugian per jam jika proses ini berhenti?
3. Tentukan dampak non-finansial - Reputasi, kepatuhan regulasi, keselamatan.
4. Identifikasi dependencies - Sistem, vendor, data, sumber daya manusia apa yang dibutuhkan?
5. Tentukan recovery priorities - RTO, RPO, dan urutan pemulihan.

Contoh kuesioner BIA:

Rumus menghitung potential loss:

Potential Loss = (Revenue per hour x Downtime hours)
               + (Penalty per hour x Downtime hours)
               + (Recovery cost)

RTO, RPO, dan MTD

Tiga metrik utama dalam BCP yang harus ditetapkan berdasarkan hasil BIA:

RTO (Recovery Time Objective)

Waktu maksimal yang dibutuhkan untuk memulihkan sistem/layanan setelah insiden dinyatakan.

• Contoh: RTO = 4 jam berarti sistem harus kembali berfungsi dalam 4 jam setelah insiden.
• Semakin kecil RTO, semakin mahal infrastruktur yang dibutuhkan (misalnya hot standby).
• RTO ditentukan oleh toleransi bisnis terhadap downtime.

RPO (Recovery Point Objective)

Jumlah maksimum data yang dapat hilang yang masih dapat ditoleransi oleh bisnis, diukur dalam satuan waktu.

• Contoh: RPO = 1 jam berarti backup maksimal 1 jam sebelum insiden.
• Semakin kecil RPO, semakin sering backup harus dilakukan.
• RPO = 0 berarti zero data loss (memerlukan synchronous replication).

MTD (Maximum Tolerable Downtime)

Batas maksimum total downtime yang dapat ditoleransi oleh organisasi sebelum mengalami kegagalan bisnis yang fatal.

• MTD selalu lebih besar dari RTO karena mencakup waktu deteksi + respons + recovery.
• Rumus: MTD = Detection Time + Response Time + Recovery Time + Verification Time
• Jika sebuah proses melebihi MTD, dampaknya bisa berupa kebangkrutan atau penutupan bisnis.

Ilustrasi hubungan RTO, RPO, dan MTD:

timeline
    title Timeline Insiden dan Recovery
    t0 : Insiden terjadi
    t1 : Insiden terdeteksi
    t2 : Eradikasi selesai
    t3 : Recovery selesai (RTO)
    t4 : Batas maksimum toleransi (MTD)
    ^RPO^ : Backup terakhir sebelum insiden
    ^Data Loss^ : Data antara backup terakhir dan insiden

Hubungan ketiganya:

Contoh penetapan RTO/RPO berdasarkan jenis sistem:

High Availability Architecture

High Availability (HA) adalah desain infrastruktur yang memastikan sistem tetap berjalan meskipun terjadi kegagalan komponen. HA adalah enabler utama untuk mencapai RTO yang rendah.

Komponen HA:

• Redundansi - Setiap komponen kritis memiliki cadangan (server, network, storage).
• Failover otomatis - Jika komponen utama gagal, cadangan mengambil alih tanpa intervensi manual.
• Load balancing - Distribusi traffic ke multiple server untuk mencegah overload.
• Health checking - Monitoring terus-menerus untuk mendeteksi kegagalan.

Cluster Architecture (Linux HA):

# Contoh konfigurasi Pacemaker + Corosync
pcs cluster setup --name production-cluster node01.example.com node02.example.com
pcs cluster start --all

# Konfigurasi resource
pcs resource create virtual_ip ocf:heartbeat:IPaddr2 \
    ip=192.168.1.100 cidr_netmask=24 \
    op monitor interval=30s

pcs resource create web_server ocf:heartbeat:nginx \
    configfile=/etc/nginx/nginx.conf \
    op monitor interval=10s

# Konfigurasi constraint
pcs constraint colocation add virtual_ip with web_server INFINITY
pcs constraint order web_server then virtual_ip

Database HA:

# Contoh konfigurasi PostgreSQL streaming replication
# Server Primary (node01)
listen_addresses = '*'
wal_level = replica
max_wal_senders = 3
wal_keep_size = 1024
hot_standby = on

# Server Standby (node02)
primary_conninfo = 'host=192.168.1.100 port=5432 user=replicator password=secret'
restore_command = 'cp /var/lib/postgresql/14/archive/%f %p'
recovery_target_timeline = 'latest'

Application Layer HA dengan Load Balancer:

# Contoh konfigurasi Nginx load balancing
upstream app_backend {
    least_conn;  # Least connections algorithm
    server app01.internal:8080 max_fails=3 fail_timeout=30s;
    server app02.internal:8080 max_fails=3 fail_timeout=30s;
    server app03.internal:8080 max_fails=3 fail_timeout=30s backup;
}

server {
    listen 443 ssl;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_connect_timeout 5s;
        proxy_next_upstream error timeout invalid_header http_500;
    }
}

Failover Strategies

Active-Active

Kedua site/sistem aktif secara bersamaan dan berbagi traffic. Jika satu gagal, yang lain langsung menangani semua traffic tanpa downtime.

Keunggulan:

• Zero downtime saat failover.
• Resource utilization maksimal.
• Cocok untuk aplikasi stateless.

Tantangan:

• Kompleksitas tinggi (data consistency, session replication).
• Biaya infrastruktur ganda (×2).
• Memerlukan aplikasi yang dirancang untuk multi-master.

Arsitektur Active-Active:

                         Internet
                            |
                     [Load Balancer]
                    /              \
          [Site A Active]      [Site B Active]
          (app01, app02)       (app03, app04)
                    \              /
               [Database Cluster]
              (Multi-master replication)

Active-Passive

Satu site aktif, yang lain siaga (standby). Jika site aktif gagal, traffic dialihkan ke site pasif.

Keunggulan:

• Lebih sederhana daripada active-active.
• Biaya lebih rendah (infrastruktur standby bisa lebih kecil).
• Cocok untuk aplikasi stateful (database).

Tantangan:

• Ada waktu transisi saat failover (beberapa detik hingga menit).
• Resource standby tidak termanfaatkan (idle).
• Perlu testing failover berkala.

Arsitektur Active-Passive:

                         Internet
                            |
                       [Site A Active]
                     (app + db primary)
                            |
                     [Replication]
                            |
                       [Site B Passive]
                     (app standby + db standby)

Contoh implementasi failover script:

#!/bin/bash
# Failover script - Active to Passive
PRIMARY_IP="10.0.1.100"
STANDBY_IP="10.0.2.100"
VIP="203.0.113.100"

# Deteksi kegagalan primary
if ! ping -c 3 -W 2 "$PRIMARY_IP" &>/dev/null; then
    echo "[!] Primary server unreachable. Initiating failover..."

    # Mount shared storage di standby
    ssh "$STANDBY_IP" "mount /dev/sdb1 /mnt/data"

    # Start database di standby
    ssh "$STANDBY_IP" "systemctl start postgresql"

    # Promote standby database ke primary
    ssh "$STANDBY_IP" "pg_ctl promote -D /var/lib/postgresql/14/main"

    # Pindahkan VIP ke standby
    ssh "$STANDBY_IP" "ip addr add $VIP/32 dev eth0"

    echo "[+] Failover completed. VIP moved to $STANDBY_IP"
else
    echo "[*] Primary server is healthy. No action needed."
fi

Perbandingan Strategi Failover

Redundansi

Redundansi adalah strategi pengadaan komponen cadangan untuk menghilangkan single point of failure.

Jenis Redundansi:

Contoh Implementasi Redundansi:

Network Redundancy (Dual ISPs):

# Load balancing dengan multiple ISPs via policy routing
ip route add default via 10.0.1.1 dev eth0 table 100
ip route add default via 10.0.2.1 dev eth1 table 200
ip rule add from 10.0.1.0/24 table 100 priority 100
ip rule add from 10.0.2.0/24 table 200 priority 200

# Health check dan failover otomatis
ip route replace default scope global \
    nexthop via 10.0.1.1 dev eth0 weight 1 \
    nexthop via 10.0.2.1 dev eth1 weight 1

Storage Redundancy (RAID + Replication):

• RAID 1 - Mirroring, 2 disk, toleransi 1 gagal.
• RAID 5 - Striping + parity, minimal 3 disk, toleransi 1 gagal.
• RAID 6 - Striping + dual parity, minimal 4 disk, toleransi 2 gagal.
• RAID 10 - Stripping + mirroring, performa tinggi.

Contoh Template BCP Sederhana

**BUSINESS CONTINUITY PLAN - PT. TEKNOLOGI NUSANTARA**
=====================================================

Versi: 2.1 | Tanggal: 20 Juli 2026 | Classification: CONFIDENTIAL

## 1. TUJUAN
Dokumen ini mendefinisikan prosedur untuk memastikan kelangsungan
operasi bisnis PT. Teknologi Nusantara dalam menghadapi gangguan
keamanan siber, bencana alam, atau kegagalan infrastruktur TI.

## 2. KRITERIA AKTIVASI
BCP diaktifkan jika salah satu kondisi berikut terpenuhi:
- [ ] Downtime sistem melebihi 30 menit
- [ ] Insiden keamanan Severity 1 atau 2
- [ ] Bencana alam yang mempengaruhi pusat data
- [ ] Gangguan akses ke kantor utama > 24 jam

## 3. RANTAI KOMANDO
| Posisi | Nama | Kontak | Alternatif |
|---|---|---|---|
| Incident Commander | Andi Pratama | [email protected] | Budi Santoso |
| IT Ops Lead | Siti Rahayu | [email protected] | Dian Kurniawan |
| BCP Coordinator | Rina Wijaya | [email protected] | Agus Hermawan |
| Legal & Compliance | Maya Dewi | [email protected] | Yoga Pratama |
| Corporate Communications | Adi Nugroho | [email protected] | Fajar Hidayat |

## 4. PROSEDUR KOMUNIKASI
- Notifikasi awal: < 5 menit - via WhatsApp/Slack group
- Update berkala: setiap 30 menit - via email + Slack
- Laporan eksekutif: setiap 2 jam - via email ke C-level
- Publik: diarahkan ke Crisis Communication Team

## 5. WORKAROUND MANUAL
| Proses | Sistem Normal | Workaround Darurat | Durasi Maks |
|---|---|---|---|
| Order entry | Web app | Form Google Sheets | 4 jam |
| Approval | Approval system | Email + persetujuan manual | 8 jam |
| Reporting | BI Dashboard | Excel manual | 24 jam |
| Customer support | CRM + Ticketing | Spreadsheet + WhatsApp | 8 jam |

## 6. JADWAL PENGUJIAN
| Jenis Uji | Frekuensi | PIC | Target |
|---|---|---|---|
| Tabletop Exercise | Bulanan | BCP Coordinator | Validasi prosedur |
| Technical Failover | Kuartalan | IT Ops Lead | RTO < 4 jam |
| Full Simulation | Semesteran | Incident Commander | End-to-end recovery |
| BIA Review | Tahunan | Risk Management | Update RTO/RPO |

Kesimpulan

Business Continuity adalah investasi strategis yang melindungi organisasi dari kerugian finansial, reputasi, dan kepatuhan akibat gangguan operasional. Kunci keberhasilan BCP terletak pada:

1. BIA yang akurat - Tanpa pemahaman dampak bisnis yang benar, prioritas pemulihan salah.
2. RTO/RPO yang realistis - Terlalu agresif mahal, terlalu longgar berbahaya.
3. High Availability architecture - Infrastruktur yang dirancang untuk toleransi kegagalan.
4. Strategi failover yang tepat - Active-active atau active-passive sesuai kebutuhan.
5. Pengujian berkala - BCP yang tidak diuji hanyalah dokumen yang tidak berguna.

Dengan BCP yang matang, organisasi tidak hanya siap menghadapi insiden, tetapi juga memiliki roadmap untuk meningkatkan ketahanan bisnis secara berkelanjutan.