# Tahapan Security by Design di Sistem SDM Puskesmas

Dokumen ini menjelaskan **tahapan (fase)** metodologi Security by Design dan **apa saja** yang diterapkan di dalam sistem ini pada setiap tahap.

---

## Daftar Isi

1. [Pengertian Tahapan Security by Design](#1-pengertian-tahapan-security-by-design)
2. [Tahap 1: Perancangan (Design)](#2-tahap-1-perancangan-design)
3. [Tahap 2: Pengembangan (Development)](#3-tahap-2-pengembangan-development)
4. [Tahap 3: Implementasi Runtime (Request/Response)](#4-tahap-3-implementasi-runtime-requestresponse)
5. [Tahap 4: Operasi & Pemantauan (Operations)](#5-tahap-4-operasi--pemantauan-operations)
6. [Ringkasan Tahapan dan Penerapan](#6-ringkasan-tahapan-dan-penerapan)

---

## 1. Pengertian Tahapan Security by Design

**Security by Design** tidak hanya “fitur keamanan”, tetapi **cara membangun sistem** dengan keamanan terintegrasi di setiap fase. Tahapannya:

| Tahap | Nama | Fokus |
|-------|------|--------|
| **1** | **Perancangan (Design)** | Requirement keamanan, arsitektur akses, kebijakan data. |
| **2** | **Pengembangan (Development)** | Kode aman: validasi, sanitasi, ORM, tidak hardcode rahasia. |
| **3** | **Implementasi Runtime** | Middleware, autentikasi, autorisasi, transport (HTTPS), header. |
| **4** | **Operasi & Pemantauan** | Audit log, monitoring, respons insiden. |

Di bawah ini dijelaskan **apa saja** yang sistem ini lakukan pada setiap tahap.

---

## 2. Tahap 1: Perancangan (Design)

Pada tahap ini keamanan **dirancang** sebelum kode ditulis: siapa boleh akses apa, data apa yang sensitif, dan ancaman apa yang harus diantisipasi.

### Yang Diterapkan di Sistem Ini

| Penerapan | Penjelasan |
|-----------|------------|
| **Role-based access (RBAC)** | Tiga role dirancang: **pegawai**, **kepala_tata_usaha**, **pimpinan**. Setiap fitur (pegawai, absensi, cuti, gaji) punya aturan siapa boleh create/edit/delete dan siapa hanya baca. |
| **Least privilege** | Pegawai hanya mengakses data diri sendiri; Kepala TU mengelola data; Pimpinan hanya baca laporan dan approve cuti. Tidak ada akses “super user” tanpa batas. |
| **Klasifikasi data sensitif** | Data seperti password, NIP, email, nomor STR/SIP, nomor SK ditetapkan sebagai sensitif — tidak disimpan plain di log, dan di audit log boleh direduksi (redaksi). |
| **Kebijakan session & cookie** | Session lifetime, http_only, secure, same_site dirancang di konfigurasi (`config/session.php`) agar cookie tidak bocor ke JavaScript atau situs lain. |
| **Kebijakan login** | Maksimal percobaan login, durasi lockout, dan rate limit dirancang di `config/security.php` (misalnya 5 percobaan / 15 menit, lockout 30 menit). |

### Referensi di Kode

- Konfigurasi: `config/security.php`, `config/session.php`
- Middleware role: `app/Http/Middleware/RoleMiddleware.php`
- Route yang dilindungi per role: `routes/web.php`

---

## 3. Tahap 2: Pengembangan (Development)

Pada tahap ini keamanan **dibangun ke dalam kode**: validasi input, pencegahan injeksi, dan penyimpanan data yang aman.

### Yang Diterapkan di Sistem Ini

| Penerapan | Penjelasan |
|-----------|------------|
| **Validasi input (Form Request)** | Setiap form (login, pegawai, absensi, cuti, gaji) punya Form Request (`LoginRequest`, `StorePegawaiRequest`, `StoreAbsensiRequest`, dll.) dengan rule wajib, format, panjang, dan unique. Hanya data yang lolos validasi yang diproses (`$request->validated()`). |
| **Sanitasi input** | Method `sanitizeInput()` di `Controller.php` menghapus null byte (`\0`) dan trim. Dipakai untuk input teks (misalnya username saat login); password tidak di-sanitize agar karakter khusus tetap valid. |
| **Pencegahan SQL injection** | Seluruh query memakai **Eloquent ORM** atau **Query Builder** Laravel (binding parameter). Tidak ada penggabungan string SQL dengan input user. |
| **Pencegahan XSS** | Di view, output ke HTML memakai `{{ $var }}` (escape otomatis Blade). Di controller, untuk output ke user dipakai `e()`. Tidak memakai `{!! ... !!}` untuk input user. |
| **Password hashing** | Password disimpan dengan **bcrypt** (Hash::make) di model User; pengecekan dengan Hash::check(). Tidak ada penyimpanan plain text. |
| **Pesan error generik** | Pesan login gagal selalu generik (“Username atau password salah”) agar tidak mengungkapkan apakah username ada atau password salah. |

### Referensi di Kode

- Form Request: `app/Http/Requests/` (LoginRequest, StorePegawaiRequest, StoreAbsensiRequest, StoreCutiRequest, StoreGajiRequest, dll.)
- Sanitasi: `app/Http/Controllers/Controller.php` → `sanitizeInput()`
- Password: `app/Models/User.php` (setPasswordAttribute, Hash::check)
- View: penggunaan `{{ }}` di `resources/views/`

---

## 4. Tahap 3: Implementasi Runtime (Request/Response)

Pada tahap ini setiap **request** yang masuk dan **response** yang keluar melewati lapisan keamanan (middleware, auth, transport, header).

### Yang Diterapkan di Sistem Ini

| Penerapan | Penjelasan |
|-----------|------------|
| **Transport aman (HTTPS)** | Di production, middleware ForceHttps mengalihkan HTTP ke HTTPS agar data tidak dikirim plain. |
| **Cookie aman** | EncryptCookies mengenkripsi cookie; konfigurasi session: http_only (tidak bisa diakses JS), secure (hanya HTTPS di production), same_site=strict (anti CSRF). |
| **CSRF protection** | Middleware VerifyCsrfToken memvalidasi token CSRF pada request POST/PUT/DELETE. Form memakai `@csrf` di Blade. |
| **Security headers** | Middleware SecurityHeaders menambahkan: Content-Security-Policy, X-Frame-Options (DENY), X-Content-Type-Options (nosniff), X-XSS-Protection, Referrer-Policy, Permissions-Policy, Strict-Transport-Security (HSTS). |
| **Rate limiting login** | Route POST login memakai throttle (misalnya 5 percobaan per 15 menit per IP) untuk membatasi brute force. |
| **Autentikasi** | Route yang butuh login memakai middleware `auth`. Yang belum login diarahkan ke halaman login. |
| **Autorisasi per role** | Route dilindungi dengan middleware `role:pegawai`, `role:kepala_tata_usaha`, atau `role:pimpinan`. Controller juga mengecek role sebelum aksi sensitif (abort(403) jika tidak berhak). |
| **Session regeneration** | Setelah login sukses, session di-regenerate; saat logout, session di-invalidate dan CSRF token di-regenerate (mencegah session fixation). |

### Urutan Lapisan (Request Flow)

```
Request → EncryptCookies → StartSession → VerifyCsrfToken → SecurityHeaders
         → (Route) throttle (untuk login)
         → auth → role
         → Controller (Form Request + sanitize + bisnis)
         → AuditLog (jika aksi tercatat)
         → Response
```

### Referensi di Kode

- Middleware: `app/Http/Kernel.php` (web group: EncryptCookies, VerifyCsrfToken, SecurityHeaders)
- Auth & role: `app/Http/Controllers/AuthController.php`, `app/Services/AuthService.php`, `app/Http/Middleware/RoleMiddleware.php`
- Route: `routes/web.php` (throttle, middleware auth, role)
- Session: `config/session.php`; login/logout di AuthController

---

## 5. Tahap 4: Operasi & Pemantauan (Operations)

Pada tahap ini sistem **mencatat** aksi penting dan **melindungi** data sensitif di log, agar bisa diaudit dan direspons jika ada insiden.

### Yang Diterapkan di Sistem Ini

| Penerapan | Penjelasan |
|-----------|------------|
| **Audit log** | Service AuditLogService mencatat: CREATE, UPDATE, DELETE pada entitas (pegawai, absensi, cuti, gaji); LOGIN/LOGOUT (sukses/gagal); akses sensitif (misalnya export PDF). Data yang disimpan: user_id, action, table_name, record_id, old/new values (yang sudah direduksi), IP, user_agent, waktu. |
| **Redaksi data sensitif** | Sebelum menyimpan ke audit log, field sensitif (password_hash, nip, email, nomor_str, nomor_sip, dll.) direduksi (misalnya 2 karakter awal + *** + 2 akhir) agar log tidak memuat data lengkap. |
| **Log percobaan login gagal** | Setiap percobaan login gagal dicatat (user, IP, waktu) dan dihubungkan dengan mekanisme lockout (increment failed attempts, lock account setelah N gagal). |
| **Fail secure** | Jika terjadi akses tidak sah, sistem mengembalikan 403 dengan pesan umum (“Anda tidak memiliki izin…”), tanpa membocorkan detail sistem. |

### Referensi di Kode

- `app/Services/AuditLogService.php` (log, logCreate, logUpdate, logDelete, logLogin, logLogout, logSensitiveAccess, redactSensitiveData)
- `app/Models/AuditLog.php`
- Pemanggilan audit di controller dan AuthService

---

## 6. Ringkasan Tahapan dan Penerapan

| Tahap | Fokus | Apa Saja yang Diterapkan di Sistem Ini |
|-------|--------|----------------------------------------|
| **1. Perancangan** | Requirement & arsitektur keamanan | RBAC (pegawai, kepala_tata_usaha, pimpinan), least privilege, klasifikasi data sensitif, kebijakan session/cookie/login di config. |
| **2. Pengembangan** | Kode aman | Form Request validasi, sanitasi input, ORM (anti SQL injection), escape output (anti XSS), password hashing, pesan error generik. |
| **3. Runtime** | Setiap request/response | HTTPS, cookie encrypt + http_only + secure + same_site, CSRF, security headers, throttle login, auth, role middleware, session regeneration. |
| **4. Operasi** | Audit & respons | Audit log create/update/delete/login/akses sensitif, redaksi data sensitif di log, log login gagal + lockout, fail secure (403). |

Dengan keempat tahap ini, sistem menerapkan **Security by Design** dari perancangan sampai operasi. Detail teknis tiap aspek dapat dilihat di dokumen **PENERAPAN_SECURITY_BY_DESIGN.md** di root proyek.