Keamanan Informasi & Kerahasiaan

8.1 Ikhtisar & Tujuan

Bab ini menetapkan kewajiban keamanan informasi dan kerahasiaan yang mengatur penyediaan Platform ProjectVIEW ERP oleh Provider. Bab ini menetapkan arsitektur keamanan, kontrol autentikasi, standar enkripsi, pertahanan jaringan, prosedur pengelolaan kerentanan, serta ketentuan kerahasiaan yang melindungi Data Customer, integritas Platform, dan kekayaan intelektual milik Provider sepanjang Masa Langganan.

Sistem Manajemen Keamanan Informasi (Information Security Management System/ISMS) milik Provider dikelola oleh Departemen TI dan selaras dengan ISO/IEC 27001:2022. Bab ini membahas kontrol keamanan teknis yang melengkapi langkah-langkah khusus privasi yang dijelaskan dalam Bab 7 (Perlindungan Data & Privasi) dan langkah-langkah keamanan dukungan operasional yang dijelaskan dalam Bab 4 (Dukungan & Operasi Layanan).

DANAOS Web Enterprise menggabungkan mekanisme keamanan di setiap lapisan tumpukan aplikasi, dari lapisan presentasi (peramban web) melalui lapisan aplikasi (application server) hingga lapisan data (database server), sehingga kerahasiaan, integritas, dan ketersediaan (trias C.I.A.) diterapkan menyeluruh dari ujung ke ujung dalam lingkungan sovereign privat khusus milik setiap Customer.

8.2 Ruang Lingkup

Bab ini mencakup:

• (a) Keamanan aplikasi platform: Autentikasi, otorisasi, manajemen sesi, validasi input, dan praktik pengkodean aman yang tertanam dalam DANAOS Web Framework.
• (b) Keamanan infrastruktur: Segmentasi jaringan, konfigurasi firewall, deteksi intrusi, perlindungan DDoS, dan kontrol Web Application Firewall (WAF) yang diterapkan pada lingkungan sovereign milik setiap Customer yang di-host di Azure.
• (c) Keamanan database: Kontrol akses, enkripsi saat tersimpan dan saat transit, logging audit, manajemen hak istimewa, dan pemantauan koneksi untuk instansi database SQL Server.
• (d) Keamanan operasional: Pengelolaan kerentanan, pengujian penetrasi, manajemen patch, pelacakan perubahan, dan respons insiden keamanan (insiden yang tidak melibatkan data pribadi; pelanggaran Data Pribadi diatur oleh §7.15).
• (e) Keamanan kode sumber: Perlindungan kekayaan intelektual, siklus hidup pengembangan aman, kontrol versi berbasis Git, dan praktik code review yang mengatur codebase milik Provider yang bersifat proprietari.
• (f) Kewajiban kerahasiaan: Komitmen kerahasiaan timbal balik, klasifikasi informasi, pembatasan pengungkapan, dan ketentuan keberlakuan yang tetap berlaku setelah berakhirnya perjanjian.

8.3 Standar & Kerangka Keamanan

Program keamanan Provider dibangun berdasarkan standar, kerangka kerja, dan panduan berikut:

ISO/IEC 27001:2022 NIST CSF 2.0 OWASP Top 10 (2021) CIS Azure Foundations Benchmark NIST SP 800-63B-4 Azure Well-Architected Framework

8.4 Keamanan Aplikasi

Platform DANAOS ProjectVIEW ERP menggabungkan mekanisme keamanan berikut pada lapisan aplikasi untuk memastikan kerahasiaan dan integritas sistem. Kontrol ini diberlakukan untuk setiap instance Customer dan dapat dikonfigurasi oleh administrator sistem Customer melalui modul STY (Users & Roles Management).

8.4.1 Kontrol Autentikasi

8.4.2 Otorisasi & Kontrol Akses

Modul Users & Roles Management (STY) pada Platform memberlakukan kontrol akses berbasis peran yang granular (RBAC) pada beberapa tingkat:

• (a) Tingkat modul: Pengguna diberikan atau ditolak akses ke seluruh modul (misalnya, PV_07 HRMS– Payroll, PV_08 Accounting) berdasarkan penetapan perannya.
• (b) Tingkat fungsi: Di dalam suatu modul, fungsi-fungsi individual (misalnya, membuat purchase order, menyetujui invoice, melihat gaji) diberi otorisasi secara terpisah.
• (c) Tingkat field: Field sensitif dalam sebuah record (misalnya, jumlah gaji, rekening bank, ID nasional) dapat disembunyikan atau dibuat hanya-baca untuk peran tertentu.
• (d) Tingkat record: Keamanan tingkat baris membatasi visibilitas berdasarkan hierarki organisasi (misalnya, project manager hanya melihat proyek yang ditugaskan kepadanya; regional manager melihat wilayahnya).
• (e) Pemisahan tugas: Deteksi peran yang saling bertentangan mencegah satu pengguna memegang peran yang menimbulkan konflik pemisahan tugas (misalnya, pembuat requisition dan pihak yang berwenang menyetujui). Modul STY memberi peringatan kepada administrator atas konflik yang terdeteksi dan menerapkan pembatasan berbasis kebijakan.
• (f) ID pengguna unik: Setiap akun pengguna diberikan pengenal unik. Akun bersama/generik dilarang. Seluruh tindakan dapat ditelusuri ke pengguna individual melalui jejak audit.
• (g) Akses jarak jauh yang dibatasi: Administrator sistem mengendalikan akses jarak jauh per pengguna melalui konsol administrator; akses dapat diizinkan atau dicabut kapan saja.

8.4.3 Keamanan Sesi

• (a) Token sesi: Token sesi acak secara kriptografis dihasilkan saat autentikasi. Token diikat pada alamat IP dan string user-agent pengguna untuk mencegah pembajakan sesi.
• (b) Pembatalan sesi: Sesi dibatalkan saat: perubahan kata sandi, penangguhan akun, logout eksplisit, atau berakhirnya idle-timeout.
• (c) Kontrol sesi serentak: Batas yang dapat dikonfigurasi untuk sesi aktif serentak per akun pengguna. Default: satu sesi aktif per pengguna (kebijakan last-login-wins).

8.4.4 Validasi Input & Pengkodean Output

• (a) Validasi sisi server: Semua input yang diberikan pengguna divalidasi di sisi server menggunakan validasi berbasis whitelist. Validasi sisi klien hanya diperlakukan sebagai peningkatan kegunaan, bukan sebagai kontrol keamanan.
• (b) Query terparameter: Seluruh interaksi basis data menggunakan query terparameter (prepared statement) untuk mencegah SQL injection. Pembuatan SQL dinamis dari input pengguna dilarang oleh standar pengkodean aman Provider.
• (c) Pengkodean output: Seluruh data yang dirender ke browser dienkode secara kontekstual (pengkodean HTML, JavaScript, URL, CSS sesuai kebutuhan) untuk mencegah cross-site scripting (XSS).
• (d) Content Security Policy (CSP): Header respons HTTP mencakup Content Security Policy yang ketat untuk memitigasi XSS dan serangan injeksi data.

8.5 Keamanan Infrastruktur

Setiap instance ProjectVIEW ERP milik Customer diterapkan dalam lingkungan sovereign privat khusus di Microsoft Azure. Kontrol keamanan infrastruktur yang dijelaskan di bawah ini diterapkan per tenant dan selaras dengan CIS Azure Foundations Benchmark serta Azure Well-Architected Security Pillar.

8.5.1 Keamanan Jaringan

• (a) Network Security Groups (NSG): Setiap virtual machine dilindungi oleh NSG yang menyediakan fungsi firewall stateful dengan aturan allow/deny yang eksplisit. Kebijakan default: inbound ditolak semua; hanya port layanan yang diperlukan yang diizinkan.
• (b) Web Application Firewall (WAF): Azure WAF diterapkan di depan lapisan aplikasi untuk melindungi dari ancaman OWASP Top 10, termasuk SQL injection, XSS, CSRF, dan serangan request-smuggling.
• (c) Perlindungan DDoS: Azure DDoS Protection Standard diaktifkan untuk semua lingkungan Customer, menyediakan mitigasi serangan volumetrik, protokol, dan lapisan aplikasi dengan deteksi otomatis serta remediasi inline.
• (d) Segmentasi jaringan: Lapisan data, lapisan aplikasi, dan lapisan manajemen diterapkan dalam subnet terpisah dengan lalu lintas antar-lapisan dikendalikan oleh aturan NSG. Subnet database tidak dapat diakses langsung dari internet.
• (e) VPN & konektivitas privat: Apabila Customer memerlukan konektivitas site-to-site (misalnya integrasi dengan Active Directory on-premises), Azure VPN Gateway atau ExpressRoute disediakan dengan enkripsi IPSec/IKEv2.
• (f) Keamanan DNS: Zona Azure Private DNS digunakan untuk mencegah eksfiltrasi data berbasis DNS. Rekaman DNS publik dilindungi dengan DNSSEC jika didukung oleh registrar.

8.5.2 Keamanan Komputasi

• (a) Hardening sistem operasi: Seluruh virtual machine menjalankan Microsoft Windows Server 2022, di-hardening sesuai CIS Windows Server 2022 Benchmark. Layanan, port, dan fitur yang tidak diperlukan dinonaktifkan.
• (b) Manajemen patch: Patch keamanan diterapkan dalam: (i) tujuh puluh dua (72) jam untuk CVE Kritis/Tinggi; (ii) tiga puluh (30) hari kalender untuk CVE Menengah; (iii) jendela pemeliharaan berikutnya untuk CVE Rendah. Patch diuji di Staging Environment sebelum diterapkan ke produksi.
• (c) Anti-malware: Perlindungan endpoint native cloud (Microsoft Defender for Cloud) diaktifkan pada semua virtual machine dengan pemindaian real-time, analisis perilaku, dan remediasi otomatis.
• (d) Deteksi intrusi berbasis host: Azure Security Centre memantau integritas file, eksekusi proses yang mencurigakan, dan system call yang tidak lazim pada semua VM.

8.5.3 Manajemen Identitas & Rahasia

• (a) Azure Key Vault: Semua kunci kriptografis, sertifikat, connection string, dan kredensial layanan disimpan di Azure Key Vault dengan akses yang dikendalikan oleh Azure RBAC dan kebijakan akses Key Vault.
• (b) Identitas terkelola: Azure Managed Identities digunakan untuk autentikasi service-to-service apabila memungkinkan, sehingga menghilangkan kebutuhan akan kredensial yang disimpan dalam konfigurasi aplikasi.
• (c) Rotasi rahasia: Kebijakan rotasi rahasia otomatis diberlakukan untuk seluruh kredensial service account dan API key. Periode rotasi maksimum: sembilan puluh (90) hari kalender.

8.6 Keamanan Database

Lapisan data Platform berjalan pada Microsoft SQL Server 2022 (Standard atau Enterprise Edition) yang diterapkan pada Microsoft Windows Server 2022. Kontrol keamanan khusus database berikut diberlakukan, selaras dengan CIS SQL Server 2022 Benchmark:

8.6.1 Akses & Autentikasi

• (a) Autentikasi database: SQL Server menggunakan mode Windows Authentication (terintegrasi dengan Active Directory) sebagai metode autentikasi utama. Mixed-mode authentication dinonaktifkan kecuali secara tegas diperlukan dan disetujui oleh Customer.
• (b) Kata sandi aplikasi: Kredensial database di tingkat aplikasi menggunakan kata sandi kuat yang sesuai dengan kebijakan komposisi kata sandi dan dirotasi sesuai jadwal rotasi rahasia (§8.5.3).
• (c) Akun default: Semua akun sistem default (misalnya, ‘sa’) diamankan dengan benar oleh DBA: kata sandi default diubah segera setelah provisioning; akun default yang tidak diperlukan dinonaktifkan atau dihapus.
• (d) Kontrol koneksi: Koneksi ke instansi database dikendalikan dan dipantau. Hanya layanan lapisan aplikasi yang berwenang dan personel DBA yang ditunjuk yang dapat membangun koneksi. Connection string disimpan di Azure Key Vault (§8.5.3).
• (e) Kemampuan untuk terhubung: Kontrol di tingkat jaringan membatasi konektivitas database hanya ke subnet lapisan aplikasi dan endpoint manajemen yang berwenang. Konektivitas langsung dari internet ke database dilarang.

8.6.2 Manajemen Hak Istimewa

• (a) Hak minimum & peran: Akun pengguna database diprovisioning dengan hak minimum dan peran yang diperlukan untuk fungsinya. Prinsip least privilege ditegakkan dan ditinjau secara berkala.
• (b) Hak sistem: Semua hak istimewa ‘system’ dihapus dari akun pengguna kecuali secara tegas diperlukan dan disetujui. Operasi istimewa memerlukan akun DBA terpisah yang khusus dengan MFA.
• (c) Pemisahan tugas: Hak administratif database dipisahkan dari hak pengembangan aplikasi. Developer tidak memiliki akses database produksi.
• (d) Peninjauan hak istimewa: Peninjauan triwulanan atas penetapan hak istimewa database; hak yang tidak digunakan atau berlebihan dicabut. Hasil peninjauan didokumentasikan dan tersedia untuk audit (§7.11).

8.6.3 Enkripsi

• (a) Transparent Data Encryption (TDE): TDE diaktifkan pada semua instansi database produksi dan staging, mengenkripsi file data, file log, dan tempdb menggunakan enkripsi AES-256. Sertifikat TDE dicadangkan dan disimpan di Azure Key Vault.
• (b) Enkripsi cadangan: Semua cadangan database (full, differential, dan transaction-log) dienkripsi menggunakan AES-256 dengan kunci enkripsi khusus Customer yang dikelola melalui Azure Key Vault.
• (c) Enkripsi tingkat kolom: Apabila diwajibkan oleh kebijakan klasifikasi data Customer, enkripsi tingkat kolom (Always Encrypted) tersedia untuk field yang sangat sensitif (misalnya, ID nasional, nomor rekening bank).

8.6.4 Audit & Logging

• (a) Audit logging: SQL Server Audit menangkap: (i) semua operasi DDL (perubahan skema); (ii) aktivitas pengguna istimewa; (iii) percobaan autentikasi gagal; (iv) operasi ekspor data dan bulk-copy; (v) perubahan izin. Log audit ditulis ke penyimpanan yang tahan terhadap manipulasi.
• (b) Retensi logging: Log audit database disimpan minimal dua belas (12) bulan secara online dan dua puluh empat (24) bulan dalam penyimpanan arsip. Retensi memenuhi persyaratan regulasi berdasarkan GDPR, UAE PDPL, dan standar industri yang berlaku.
• (c) Pelacakan perubahan: SQL Server Change Tracking dan Change Data Capture (CDC) diaktifkan untuk menyediakan inventaris lengkap atas modifikasi data untuk tujuan kepatuhan dan audit.
• (d) Akses jarak jauh DBA: Administrasi database jarak jauh dibatasi hanya untuk individu yang namanya tercantum, melalui saluran terenkripsi dengan autentikasi multi-faktor. Semua sesi DBA dicatat dengan jejak audit lengkap hingga tingkat perintah (§7.8.3).

8.7 Manajemen Kerentanan

Provider menjalankan program manajemen kerentanan berkelanjutan yang selaras dengan fungsi NIST CSF Identify (ID.RA) dan Protect (PR.IP):

8.7.1 Jadwal Penilaian

8.7.2 Jangka Waktu Remediasi

Kerentanan zero-day: Untuk kerentanan zero-day yang sedang dieksploitasi secara aktif dan berdampak pada tumpukan teknologi Platform, Provider wajib menerapkan langkah mitigasi darurat (misalnya aturan WAF, isolasi jaringan, virtual patching) dalam waktu dua puluh empat (24) jam, dengan patch permanen mengikuti SLA remediasi Critical.

8.8 Pemantauan Keamanan & Respons Insiden

8.8.1 Pemantauan

Provider menjalankan kapabilitas pemantauan keamanan 24/7 menggunakan komponen berikut:

• (a) SIEM: Security Information and Event Management native cloud (Microsoft Sentinel) mengonsolidasikan log dari seluruh lapisan infrastruktur, aplikasi, dan database. Aturan korelasi dan deteksi machine-learning mengidentifikasi pola yang tidak lazim.
• (b) AIOps: Perangkat operasional berbasis AI menyediakan deteksi anomali prediktif pada metrik performa, pola autentikasi, dan volume akses data, sehingga memungkinkan identifikasi dini penyimpangan yang relevan terhadap keamanan sebelum berkembang menjadi insiden.
• (c) Intelijen ancaman: SIEM terintegrasi dengan feed intelijen ancaman real-time (Microsoft Threat Intelligence, IOCs spesifik industri) untuk mendeteksi signature serangan yang telah dikenal dan indikator kompromi.
• (d) User and Entity Behaviour Analytics (UEBA): Profil perilaku dasar ditetapkan untuk pengguna dan service account. Penyimpangan (misalnya lokasi login yang tidak biasa, pola akses data yang tidak lazim, upaya eskalasi hak istimewa) memicu peringatan otomatis.

8.8.2 Respons Insiden Keamanan

Insiden keamanan yang tidak melibatkan Data Pribadi dikelola berdasarkan bagian ini. Pelanggaran Data Pribadi diatur oleh §7.15. Apabila suatu insiden kemudian diklasifikasikan melibatkan Data Pribadi, prosedur pemberitahuan pelanggaran pada §7.15 berlaku sebagai tambahan atas langkah-langkah di bawah ini.

8.8.3 Pemberitahuan kepada Customer

Provider wajib memberi tahu Customer atas insiden keamanan yang: (i) mengakibatkan akses tanpa izin yang aktual atau diduga terhadap Data Customer; (ii) secara material memengaruhi ketersediaan atau integritas Platform; atau

• (iii) melibatkan keterlibatan penegak hukum terkait lingkungan Customer. Pemberitahuan harus dilakukan dalam jangka waktu yang selaras dengan tingkat keparahan insiden dan SLA pemberitahuan pelanggaran yang didefinisikan dalam §7.15.1.

8.9 Siklus Hidup Pengembangan Aman (SDLC)

Provider menjalankan SDLC yang aman selaras dengan OWASP Software Assurance Maturity Model (SAMM) dan Microsoft Security Development Lifecycle (SDL):

• (a) Pemodelan ancaman: Fitur baru dan perubahan signifikan menjalani pemodelan ancaman pada tahap desain. Metodologi STRIDE digunakan untuk mengidentifikasi ancaman; DREAD digunakan untuk memprioritaskan risiko.
• (b) Standar pengodean aman: Pengembang mengikuti standar pengodean aman milik Provider (berdasarkan OWASP Secure Coding Practices) yang mencakup validasi input, encoding output, autentikasi, manajemen sesi, penanganan error, dan kriptografi.
• (c) Static Application Security Testing (SAST): SAST otomatis dijalankan pada setiap commit kode. Temuan dengan tingkat keparahan High/Critical akan memblokir build hingga diselesaikan.
• (d) Dynamic Application Security Testing (DAST): DAST dijalankan terhadap Staging Environment sebelum setiap deployment ke produksi. Pemindaian menargetkan OWASP Top 10 dan kontrol ASVS Level 2.
• (e) Software Composition Analysis (SCA): Seluruh dependensi pihak ketiga dipindai untuk kerentanan yang diketahui (CVE) dan kepatuhan lisensi pada setiap build. Komponen dengan CVE Critical/High yang belum ditambal akan diblokir.
• (f) Tinjauan kode: Semua perubahan kode produksi memerlukan tinjauan sejawat dan persetujuan sebelum digabungkan ke cabang Master. Perubahan yang sensitif terhadap keamanan (autentikasi, kriptografi, logika kontrol akses) memerlukan tinjauan oleh security champion yang ditunjuk.
• (g) Kontrol versi: Kontrol versi berbasis Git dengan model cabang Master/Client/Working (§4.7). Semua commit ditandatangani dan dapat ditelusuri ke pengembang individu. Force-push ke Master dilarang.

8.10 Perlindungan Kode Sumber

Kode sumber Provider merupakan kekayaan intelektual milik eksklusif dan tunduk pada perlindungan berikut:

• (a) Pembatasan akses: Repositori kode sumber hanya dapat diakses oleh personel pengembangan Provider yang berwenang. Personel Customer tidak memiliki akses ke kode sumber kecuali perjanjian escrow kode sumber terpisah telah ditandatangani.
• (b) Escrow kode sumber: Atas permintaan Customer, Provider wajib mengadakan perjanjian escrow kode sumber dengan agen escrow pihak ketiga yang bereputasi baik. Kondisi pelepasan biasanya mencakup: insolvensi Provider, pelanggaran material atas Framework ini, atau penghentian Platform tanpa produk penerus yang memadai.
• (c) Arsitektur thin-client: Platform beroperasi sebagai aplikasi web thin-client. Tidak ada kode sumber milik eksklusif, binary terkompilasi, atau logika aplikasi yang didistribusikan ke perangkat Client. Seluruh pemrosesan aplikasi terjadi di sisi server dalam lingkungan berdaulat Customer.
• (d) Obfuskasi: JavaScript dan CSS sisi klien yang dikirim ke browser diminifikasi dan diobfuskasi. Source map tidak diekspos dalam deployment produksi.
• (e) Tidak ada kewajiban open source: Provider memastikan bahwa penggunaan komponen open-source tidak menimbulkan kewajiban untuk mengungkap kode sumber milik eksklusif (misalnya kontaminasi lisensi copyleft). Semua komponen open-source ditelaah kesesuaian lisensinya sebelum diadopsi.

8.11 Kewajiban Kerahasiaan

8.11.1 Klasifikasi Informasi

Semua informasi yang dipertukarkan antara Para Pihak diklasifikasikan sesuai kategori berikut:

8.11.2 Kewajiban Kerahasiaan Bersama

Masing-masing Pihak berjanji kepada pihak lainnya bahwa pihaknya akan:

• (a) Menjaga kerahasiaan seluruh Informasi Rahasia milik Pihak yang mengungkapkan dan tidak mengungkapkannya kepada pihak ketiga mana pun tanpa persetujuan tertulis sebelumnya dari Pihak yang mengungkapkan.
• (b) Menggunakan Informasi Rahasia semata-mata untuk tujuan melaksanakan kewajibannya atau menjalankan haknya berdasarkan Framework ini.
• (c) Membatasi pengungkapan Informasi Rahasia hanya kepada karyawan, agen, atau subprosesor yang perlu mengetahui informasi tersebut untuk tujuan Framework ini dan yang terikat oleh kewajiban kerahasiaan yang tidak kurang ketat daripada yang tercantum di sini.
• (d) Menerapkan tingkat kehati-hatian yang sama untuk melindungi Informasi Rahasia milik Pihak yang mengungkapkan sebagaimana yang diterapkannya pada informasi rahasianya sendiri, namun dalam keadaan apa pun tidak kurang dari kehati-hatian yang wajar.
• (e) Segera memberi tahu Pihak yang mengungkapkan tentang setiap pengungkapan atau penggunaan Informasi Rahasia yang aktual atau diduga tidak sah.

8.11.3 Pengecualian

Kewajiban kerahasiaan tidak berlaku untuk informasi yang:

• (a) Telah atau menjadi tersedia untuk umum tanpa kesalahan dari Pihak penerima.
• (b) Sudah diketahui oleh Pihak penerima pada saat pengungkapan, sebagaimana dibuktikan oleh catatan tertulis.
• (c) Dikembangkan secara independen oleh Pihak penerima tanpa mengacu pada Informasi Rahasia.
• (d) Diperoleh secara sah dari pihak ketiga tanpa pembatasan pengungkapan.
• (e) Wajib diungkapkan berdasarkan hukum, peraturan, atau perintah pengadilan yang berlaku, dengan ketentuan bahwa Pihak penerima memberikan pemberitahuan tertulis segera kepada Pihak yang mengungkapkan (sepanjang secara hukum diperbolehkan) dan bekerja sama dalam setiap upaya untuk memperoleh perlakuan perlindungan.

8.11.4 Kelangsungan

Kewajiban kerahasiaan yang ditetapkan dalam bagian ini akan tetap berlaku setelah pengakhiran atau berakhirnya Framework ini selama periode lima (5) tahun, kecuali untuk rahasia dagang, yang akan dilindungi selama rahasia dagang tersebut masih diakui sebagai rahasia dagang menurut hukum yang berlaku.

8.12 Penghapusan Akses

8.12.1 Penghapusan Akses Sistem

Ketika peran karyawan Provider berubah atau hubungan kerjanya berakhir, seluruh akses sistem dihapus dalam:

• (a) Pemutusan hubungan kerja tidak sukarela atau kekhawatiran keamanan: Pencabutan segera (dalam 1 jam) atas seluruh kredensial sistem, akses VPN, izin Key Vault, dan akses fasilitas fisik.
• (b) Keberangkatan yang direncanakan: Akses dicabut pada hari kerja terakhir. Semua perangkat milik Provider dikembalikan dan dihapus isinya.
• (c) Perubahan peran: Akses disesuaikan dalam satu (1) hari kerja untuk mencerminkan persyaratan hak akses pada peran yang baru. Hak akses berlebih dari peran sebelumnya dihapus.

8.12.2 Penghapusan Akses Aplikasi

Ketika peran pengguna akhir Customer berubah atau mereka meninggalkan organisasi Customer:

• (a) Tanggung jawab Customer: Administrator sistem Customer (atau Champion) bertanggung jawab untuk menonaktifkan atau mengubah akun pengguna di dalam modul STY.
• (b) Dukungan Provider: Apabila Customer memerlukan bantuan Provider (misalnya, penonaktifan massal, penguncian darurat), permintaan layanan P2 (§4.3) harus diajukan dan diproses sesuai SLA yang berlaku.
• (c) Deteksi akun dorman: Platform menandai akun yang tidak memiliki aktivitas login selama lebih dari sembilan puluh (90) hari kalender. Akun yang ditandai dilaporkan kepada administrator Customer untuk ditinjau dan kemungkinan dinonaktifkan.

8.13 Register Proses

Tabel berikut mencantumkan proses kontraktual dan operasional yang diatur oleh bab ini. Setiap proses diberi identifikasi unik, kondisi pemicu, penanggung jawab, pemberi persetujuan, hasil yang diharapkan, dan rujukan silang ke bagian yang mengaturnya.

8.14 Skema Alur Proses

Diagram berikut menggambarkan siklus hidup keamanan informasi dari penilaian risiko hingga pemantauan berkelanjutan dan respons insiden.

① Penilaian Risiko ISMS → ② Arsitektur & Kontrol Keamanan → ③ Pengembangan & Deployment Aman

▼

④ Manajemen Kerentanan → ⑤ Pemantauan Berkelanjutan (SIEM / AIOps) → ⑥ Kontrol Akses & Tinjauan

▼

⑦ Deteksi & Respons Insiden → ⑧ Tinjauan Pasca Insiden & Perbaikan → ⑨ Audit & Sertifikasi Kepatuhan

Siklus berkelanjutan: Tahap ⑨ (Audit & Sertifikasi) memberi umpan balik ke Tahap ① (Penilaian Risiko) melalui siklus perbaikan berkelanjutan ISMS (Plan–Do–Check–Act). Tahap ④–⑦ berjalan secara berkelanjutan dengan pemindaian otomatis mingguan dan pemantauan SIEM real-time. Uji penetrasi tahunan dan audit sertifikasi memberikan jaminan independen.