Security team dapat menutup vulnerable port, memasang firewall, memperbarui application, dan membatasi internet-facing services. Namun attacker tidak selalu membutuhkan vulnerability software untuk masuk lebih jauh ke environment perusahaan. Jika mereka memperoleh credential yang valid, mengambil session token, menguasai service account, atau menemukan administrator account dengan privilege terlalu luas, mereka dapat menggunakan jalur yang memang dirancang untuk legitimate access.<\/p>\n\n\n\n
Inilah yang membuat identity menjadi bagian penting dari attack surface enterprise<\/strong>.<\/p>\n\n\n\n Employee account, administrator account, service account, API credential, machine identity, vendor access, cloud role, integration token, dan federated identity semuanya dapat menjadi jalur menuju business resources. Risiko menjadi lebih besar ketika identity tersebut mempunyai permission yang lebih luas daripada yang dibutuhkan, tidak lagi mempunyai owner, jarang ditinjau, atau dapat mengakses banyak system sekaligus.<\/p>\n\n\n\n NIST SP 800-207 Zero Trust Architecture<\/a> menjelaskan bahwa security modern tidak lagi seharusnya memberikan implicit trust hanya karena user atau asset berada di dalam corporate network. Authentication dan authorization perlu dilakukan sebelum access ke enterprise resource diberikan, dengan protection yang berfokus pada resource, user, dan asset daripada sekadar network perimeter. Prinsip ini menjadi semakin relevan ketika application, employee, cloud, vendor, dan system enterprise tersebar di banyak environment.<\/p>\n\n\n\n Dalam artikel ini, Crocodic menggunakan istilah Identity Attack Surface<\/strong> sebagai working concept untuk menggambarkan seluruh identity, credential, privilege, trust relationship, dan access path yang secara potensial dapat digunakan untuk mencapai system atau data perusahaan.<\/p>\n\n\n\n Pertanyaannya bukan hanya:<\/p>\n\n\n\n \u201cSiapa yang mempunyai account?\u201d<\/strong><\/p>\n\n\n\n Tetapi:<\/p>\n\n\n\n \u201cIdentity mana yang dapat mencapai asset kritis, privilege apa yang dimilikinya, dan seberapa jauh attacker dapat bergerak jika identity tersebut compromised?\u201d<\/strong><\/p>\n\n\n\n Traditional security mudah membayangkan attack surface sebagai website, server, IP address, VPN, atau application endpoint yang dapat ditemukan attacker. Itu masih penting, tetapi modern enterprise mempunyai layer access lain yang tidak selalu terlihat dari network map.<\/p>\n\n\n\n Seorang employee dapat login dari internet ke SaaS menggunakan corporate identity. Administrator dapat mengelola cloud environment tanpa pernah terhubung ke traditional corporate network. API menggunakan service identity untuk berkomunikasi dengan application lain. Automation menggunakan token untuk menjalankan process. Vendor memperoleh remote access untuk maintenance. AI agent dapat mempunyai permission terhadap tools, application, dan data.<\/p>\n\n\n\n Dalam semua scenario tersebut, identity menjadi control plane untuk menentukan siapa atau apa yang boleh melakukan action terhadap resource<\/strong>.<\/p>\n\n\n\n NIST memperkuat pergeseran ini dalam SP 800-207A<\/a>, yang menjelaskan bahwa pada cloud-native dan multi-cloud architecture, access control perlu memperhitungkan bukan hanya user identity tetapi juga application dan service identities. Fokus security bergeser dari network parameters seperti IP address dan subnet menuju granular identity-based authentication dan authorization.<\/p>\n\n\n\n Artinya, ketika enterprise membangun lebih banyak APIs, cloud workloads, automation, microservices, dan AI-enabled process, jumlah identity juga bertambah.<\/p>\n\n\n\n Attack surface ikut berkembang meskipun jumlah employee tidak berubah.<\/p>\n\n\n\n Ketika membahas IAM, diskusi sering langsung mengarah ke employee username dan password.<\/p>\n\n\n\n Padahal identity landscape enterprise jauh lebih luas.<\/p>\n\n\n\n Ada human identities seperti employee, contractor, administrator, customer, supplier, dan vendor. Ada non-human identities seperti service account, application account, API key, machine identity, automation credential, integration token, certificate, dan workload identity.<\/p>\n\n\n\n Semua identity tersebut dapat mempunyai access.<\/p>\n\n\n\n Problemnya, non-human identity sering tidak mempunyai lifecycle sejelas employee.<\/p>\n\n\n\n Employee masuk perusahaan melalui onboarding dan keluar melalui offboarding. Service account dapat dibuat untuk integration beberapa tahun lalu, kemudian tetap aktif meskipun application owner sudah pindah. API token dapat diberikan saat project development, kemudian lupa direvoke. Vendor credential dapat bertahan setelah contract selesai karena tidak ada system owner yang merasa bertanggung jawab.<\/p>\n\n\n\n Microsoft dalam panduan security posture untuk account menyoroti bahwa stale accounts dan stale service accounts dapat menjadi target yang menarik karena tidak lagi aktif digunakan tetapi masih mempertahankan permission. Service account juga dapat mempunyai elevated privileges dan, karena tidak terkait dengan aktivitas interactive user yang normal, misuse dapat lebih sulit terlihat. Microsoft Defender for Identity<\/a> merekomendasikan review terhadap stale accounts, privileged service accounts, serta permission yang sudah tidak diperlukan.<\/p>\n\n\n\n Karena itu, identity inventory seharusnya tidak hanya bertanya siapa employeenya.<\/p>\n\n\n\n Enterprise perlu mengetahui:<\/p>\n\n\n\n Human Identity \u2192 Service Identity \u2192 Machine Identity \u2192 API Credential \u2192 Vendor Identity \u2192 Privilege \u2192 Resource Dependency<\/strong><\/p>\n\n\n\n Dalam working framework Crocodic, Identity Attack Surface dapat dianalisis melalui chain berikut:<\/p>\n\n\n\n Identity \u2192 Credential \u2192 Authentication Path \u2192 Privilege \u2192 Reachable Resources \u2192 Business Criticality \u2192 Lateral Movement Potential \u2192 Blast Radius \u2192 Existing Control \u2192 Remediation Priority<\/strong><\/p>\n\n\n\n Framework dimulai dari Identity<\/strong>. Siapa atau apa yang memperoleh access?<\/p>\n\n\n\n Kemudian lihat Credential<\/strong> yang digunakan: password, cryptographic key, token, certificate, API secret, authenticator, atau federated assertion. Berikutnya adalah Authentication Path<\/strong>: melalui SSO, VPN, cloud console, API, application login, service-to-service communication, atau remote access.<\/p>\n\n\n\n Setelah authentication berhasil, pertanyaan yang lebih penting adalah Privilege<\/strong>. Apa yang identity tersebut boleh lakukan? Hanya membaca data? Mengubah configuration? Membuat user baru? Mengakses database? Men-deploy code? Menjalankan transaction? Mengubah permission?<\/p>\n\n\n\n Privilege kemudian dipetakan ke Reachable Resources<\/strong> dan Business Criticality<\/strong>.<\/p>\n\n\n\n Setelah itu enterprise mengevaluasi Lateral Movement Potential<\/strong>. Apakah satu identity hanya dapat mengakses satu system, atau dapat digunakan untuk berpindah menuju banyak application lain?<\/p>\n\n\n\n Hasil akhirnya adalah Blast Radius<\/strong>.<\/p>\n\n\n\n Dengan perspektif ini:<\/p>\n\n\n\n Identity Risk \u2260 hanya kemungkinan credential dicuri.<\/strong><\/p>\n\n\n\n Identity risk ditentukan juga oleh seberapa besar power yang diberikan kepada credential tersebut setelah berhasil digunakan<\/strong>.<\/p>\n\n\n\n Salah satu karakteristik identity-based attack adalah activity dapat menggunakan authentication mechanism yang legitimate.<\/p>\n\n\n\n Attacker tidak harus selalu mengeksploitasi code.<\/p>\n\n\n\n Mereka dapat melakukan phishing, credential stuffing, session theft, token theft, password spraying, social engineering, atau memperoleh credential dari compromised endpoint. Setelah berhasil login, banyak downstream systems hanya melihat bahwa authentication berhasil.<\/p>\n\n\n\n CISA dalam #StopRansomware Guide<\/a> memasukkan compromised credentials sebagai salah satu initial access vector dan merekomendasikan phishing-resistant MFA, IAM, serta Zero Trust access control untuk membatasi user-to-resource dan resource-to-resource access.<\/p>\n\n\n\n Ini mengubah security question.<\/p>\n\n\n\n Perusahaan tidak dapat hanya bertanya:<\/p>\n\n\n\n \u201cBagaimana kita mencegah credential dicuri?\u201d<\/strong><\/p>\n\n\n\n Tetapi juga:<\/p>\n\n\n\n \u201cJika satu credential berhasil dicuri, seberapa besar damage yang masih dapat dilakukan?\u201d<\/strong><\/p>\n\n\n\n Security yang matang mengasumsikan prevention dapat gagal.<\/p>\n\n\n\n Control berikutnya harus membatasi impact.<\/p>\n\n\n\n Bayangkan dua employee account mengalami compromise.<\/p>\n\n\n\n Account pertama hanya dapat membuka application tertentu dan membaca data yang relevan dengan pekerjaannya.<\/p>\n\n\n\n Account kedua mempunyai administrator privilege pada beberapa system karena dahulu membantu project migration, tetapi privilege tersebut tidak pernah diturunkan setelah project selesai.<\/p>\n\n\n\n Credential compromise-nya sama.<\/p>\n\n\n\n Business consequence-nya berbeda.<\/p>\n\n\n\n NIST Cybersecurity Framework 2.0<\/a> pada kategori identity management, authentication, dan access control menekankan bahwa permission, entitlement, dan authorization perlu dikelola, ditegakkan, serta ditinjau dengan prinsip least privilege dan separation of duties. NIST juga memberikan contoh periodic access review ketika employee berganti role atau meninggalkan organisasi.<\/p>\n\n\n\n Prinsip least privilege pada dasarnya menjawab:<\/p>\n\n\n\n \u201cApa minimum access yang diperlukan identity ini untuk menjalankan function-nya?\u201d<\/strong><\/p>\n\n\n\n Setiap permission di luar kebutuhan tersebut menjadi additional exposure.<\/p>\n\n\n\n Karena itu, dalam Identity Attack Surface:<\/p>\n\n\n\n Privilege yang tidak digunakan tetap merupakan privilege yang dapat disalahgunakan.<\/strong><\/p>\n\n\n\n Tidak semua identity mempunyai risk profile yang sama.<\/p>\n\n\n\n Administrator account, cloud administrator, database administrator, domain administrator, security administrator, dan system owner mempunyai capability yang dapat mengubah environment secara fundamental.<\/p>\n\n\n\n Jika privileged identity compromised, attacker dapat mempunyai kemampuan membuat account baru, mengubah permission, men-disable security control, mengakses sensitive information, atau mempertahankan persistence.<\/p>\n\n\n\n CISA dalam guidance tentang common enterprise misconfigurations menyoroti excessive account privileges, elevated service-account permissions, dan penggunaan privileged account yang tidak perlu<\/strong> sebagai weakness yang dapat membuka unauthorized access maupun privilege escalation. CISA merekomendasikan least privilege, routine account audit, pemisahan user dan administrative privilege, serta pembatasan penggunaan elevated account. NSA and CISA Top Ten Cybersecurity Misconfigurations<\/a> membahas problem ini secara khusus.<\/p>\n\n\n\n Ini berarti privileged account sebaiknya bukan sekadar standard employee account yang kebetulan memiliki role lebih tinggi.<\/p>\n\n\n\n Ia perlu memiliki security posture yang berbeda: stronger authentication, limited usage, logging, periodic review, approval, dan dalam environment tertentu just-in-time privilege.<\/p>\n\n\n\n Salah satu pertanyaan penting bukan hanya berapa besar privilege<\/strong>, tetapi berapa lama privilege tersebut aktif<\/strong>.<\/p>\n\n\n\n Administrator mungkin hanya membutuhkan elevated permission dua jam untuk melakukan maintenance. Namun jika privilege diberikan permanen, attacker yang memperoleh account tersebut bulan depan masih mempunyai power yang sama.<\/p>\n\n\n\n Inilah problem standing privilege.<\/p>\n\n\n\n Salah satu prinsip yang digunakan dalam Privileged Access Management adalah mengubah access dari selalu tersedia menjadi just-in-time<\/strong> atau time-bound privilege ketika task memang membutuhkan.<\/p>\n\n\n\n Tujuannya bukan mempersulit administrator.<\/p>\n\n\n\n Tujuannya mengurangi attack window<\/strong>.<\/p>\n\n\n\n CISA dalam IAM guidance merekomendasikan privileged accounts dikelola dengan additional monitoring dan control, serta menjelaskan bahwa modern PAM dapat menggunakan just-in-time provisioning agar elevated privilege hanya tersedia ketika dibutuhkan. Dengan demikian jumlah account yang selalu mempunyai high privilege dapat dikurangi.<\/p>\n\n\n\n Secara konseptual:<\/p>\n\n\n\n Privilege Exposure = Privilege Level \u00d7 Scope \u00d7 Duration<\/strong><\/p>\n\n\n\n Ini bukan formula security standard, tetapi diagnostic lens.<\/p>\n\n\n\n Privilege tinggi yang hanya berlaku pada narrow scope dan short duration mempunyai exposure berbeda dari privilege tinggi yang aktif secara permanen terhadap banyak system.<\/p>\n\n\n\n Salah satu bentuk exposure yang paling mudah dipahami adalah account yang masih aktif tetapi sudah tidak mempunyai business purpose.<\/p>\n\n\n\n Former employee account belum dinonaktifkan. Contractor project sudah selesai tetapi access tetap ada. Vendor tidak lagi digunakan tetapi VPN credential masih aktif. Employee pindah department tetapi privilege lama belum dicabut.<\/p>\n\n\n\n Account tersebut tidak lagi menghasilkan business value.<\/p>\n\n\n\n Namun tetap menghasilkan security exposure.<\/p>\n\n\n\n Microsoft secara eksplisit memperingatkan bahwa stale user account dapat menjadi target karena tidak aktif dipantau, sementara compromised stale accounts dapat digunakan untuk unauthorized access, lateral movement, atau privilege escalation. Guidance tersebut juga menyarankan menghapus atau men-disable account yang sudah tidak diperlukan. Microsoft Defender for Identity security posture assessments<\/a> memberikan contoh operational control untuk masalah ini.<\/p>\n\n\n\n Dari perspective attack-surface reduction, stale account mempunyai decision yang relatif sederhana:<\/p>\n\n\n\n No Business Purpose \u2192 No Required Access \u2192 Remove the Identity<\/strong><\/p>\n\n\n\n Menghilangkan access yang tidak diperlukan sering lebih efektif daripada menambahkan control baru di atasnya.<\/p>\n\n\n\n Identity risk tidak hanya muncul ketika employee keluar.<\/p>\n\n\n\n Employee yang tetap berada di perusahaan juga dapat mengakumulasi access seiring berpindah role.<\/p>\n\n\n\n Seseorang dahulu bekerja di Finance, kemudian pindah ke Operations, lalu masuk ke project implementation. Setiap perpindahan menambahkan permission baru, tetapi permission lama tidak selalu direview.<\/p>\n\n\n\n Beberapa tahun kemudian, employee tersebut memiliki access ke banyak application yang sebenarnya tidak lagi relevan dengan current role.<\/p>\n\n\n\n Problem ini disebut secara umum sebagai privilege accumulation<\/strong> atau permission creep.<\/p>\n\n\n\n Dari business perspective, access review bukan sekadar compliance activity. Ia menjaga hubungan antara:<\/p>\n\n\n\n Current Responsibility \u2192 Required Capability \u2192 Current Permission<\/strong><\/p>\n\n\n\n Jika ketiganya tidak lagi aligned, Identity Attack Surface tumbuh tanpa alasan business.<\/p>\n\n\n\n NIST CSF 2.0 merekomendasikan periodic review terhadap access privilege serta pencabutan permission yang tidak lagi diperlukan ketika role seseorang berubah.<\/p>\n\n\n\n Service account sering mempunyai karakter yang berbeda dari human account.<\/p>\n\n\n\n Ia mungkin digunakan application untuk mengakses database, automation untuk menjalankan scheduled task, integration untuk memindahkan data, atau infrastructure system untuk melakukan deployment.<\/p>\n\n\n\n Karena harus berjalan tanpa human interaction, service account sering memiliki long-lived credentials dan permission yang relatif luas.<\/p>\n\n\n\n CISA menyoroti elevated service-account permissions sebagai salah satu enterprise misconfiguration. Jika attacker mengambil alih application atau service yang menggunakan account tersebut, attacker dapat memperoleh privilege yang sama dengan service account.<\/p>\n\n\n\n Risiko lain adalah ownership.<\/p>\n\n\n\n Employee account biasanya jelas milik siapa.<\/p>\n\n\n\n Service account bernama seperti svc_integration01 mungkin dibuat empat tahun lalu oleh engineer yang sudah tidak bekerja di perusahaan.<\/p>\n\n\n\n Siapa yang menentukan apakah account tersebut masih dibutuhkan? System apa yang akan gagal jika permission dikurangi? Kapan password atau key terakhir dirotasi?<\/p>\n\n\n\n Karena itu, service identity perlu mempunyai lifecycle:<\/p>\n\n\n\n Owner \u2192 Purpose \u2192 Required Resource \u2192 Required Privilege \u2192 Credential Rotation \u2192 Monitoring \u2192 Expiration \/ Review<\/strong><\/p>\n\n\n\n Non-human identity tanpa owner adalah attack surface yang sulit dikelola.<\/p>\n\n\n\n Ketika two applications berkomunikasi, access sering menggunakan API key, access token, client secret, certificate, atau service identity.<\/p>\n\n\n\n Security team mungkin tidak menyebutnya \u201caccount\u201d, tetapi secara functional credential tersebut mewakili identity dan authorization.<\/p>\n\n\n\n Jika API token mempunyai permission untuk membaca customer information, siapa pun yang memegang token tersebut dapat memperoleh capability serupa.<\/p>\n\n\n\n Masalahnya, secret seperti ini mudah tersebar di configuration files, CI\/CD pipelines, developer environment, scripts, documentation, atau third-party integration.<\/p>\n\n\n\n Karena itu, API security tidak hanya berkaitan dengan endpoint.<\/p>\n\n\n\n Ia juga berkaitan dengan siapa yang boleh memanggil endpoint dan menggunakan capability apa<\/strong>.<\/p>\n\n\n\n Artikel Crocodic mengenai API Gateway dalam Arsitektur Enterprise<\/a> relevan karena gateway dapat menjadi enforcement point untuk authentication, authorization, rate limiting, dan policy pada API traffic. Namun gateway tidak menggantikan kebutuhan untuk mengelola credential lifecycle dan application identities di belakangnya.<\/p>\n\n\n\n Semakin banyak integration, semakin banyak pula identity relationship yang harus dipelihara.<\/p>\n\n\n\n Enterprise architecture bergerak dari model di mana mayoritas identities adalah manusia menuju environment dengan semakin banyak non-human entities.<\/p>\n\n\n\n Microservices berkomunikasi dengan microservices lain. CI\/CD pipeline melakukan deployment. Cloud workload mengakses storage. Automation memanggil ERP. AI agent mengakses CRM, database, dan business tools.<\/p>\n\n\n\n NIST SP 800-207A menekankan authentication dan authorization berdasarkan application dan service identities<\/strong> pada cloud-native environment, bukan hanya user identities.<\/p>\n\n\n\n Perubahan ini mempunyai implikasi besar.<\/p>\n\n\n\n Jika satu employee memiliki lima system accounts, IAM mungkin memiliki puluhan ribu human identities.<\/p>\n\n\n\n Namun cloud-native environment dapat menghasilkan jauh lebih banyak machine identities karena setiap workload, API, service, automation, dan agent membutuhkan trust relationship tersendiri.<\/p>\n\n\n\n Crocodic juga membahas problem serupa pada konteks agentic system dalam AI Agent Security: Risiko Akses di Sistem Enterprise<\/a>. Ketika AI agent memperoleh capability menjalankan action, permission model menjadi bagian langsung dari business risk.<\/p>\n\n\n\n Pertanyaannya tidak lagi hanya:<\/p>\n\n\n\n \u201cApa yang boleh dibaca AI?\u201d<\/strong><\/p>\n\n\n\n Tetapi:<\/p>\n\n\n\n \u201cAction apa yang boleh dilakukan identity AI tersebut terhadap business system?\u201d<\/strong><\/p>\n\n\n\n Enterprise sering membutuhkan external vendor untuk implementation, infrastructure support, maintenance, audit, atau integration.<\/p>\n\n\n\n Vendor mungkin mendapatkan VPN account, administrator access, remote support account, cloud role, atau application credential.<\/p>\n\n\n\n Access tersebut legitimate.<\/p>\n\n\n\n Tetapi lifecycle-nya sering lebih sulit dikendalikan karena owner relationship tersebar antara procurement, IT, business owner, dan vendor.<\/p>\n\n\n\n Siapa memastikan access dicabut ketika engineer vendor berganti? Siapa mengetahui apakah shared account digunakan oleh lima atau lima puluh orang? Apakah vendor access aktif permanen walaupun maintenance hanya dilakukan sebulan sekali?<\/p>\n\n\n\n Identity Attack Surface karena itu perlu mencakup third-party identity.<\/p>\n\n\n\n Prinsipnya sama:<\/p>\n\n\n\n External Trust tidak boleh otomatis menjadi Permanent Privilege.<\/strong><\/p>\n\n\n\n Vendor access sebaiknya mengikuti identifiable user, required task, defined scope, limited duration, stronger authentication, logging, dan revocation process.<\/p>\n\n\n\n Multifactor authentication merupakan salah satu control terpenting terhadap account takeover.<\/p>\n\n\n\n NIST SP 800-63B-4<\/a> memberikan current technical guidance tentang authentication dan authenticator management, sementara CISA mendorong penggunaan phishing-resistant MFA terutama untuk critical access.<\/p>\n\n\n\n Namun MFA menjawab satu pertanyaan:<\/p>\n\n\n\n \u201cSeberapa yakin kita bahwa orang yang login memang pemegang identity?\u201d<\/strong><\/p>\n\n\n\n MFA tidak menjawab:<\/p>\n\n\n\n \u201cApakah identity tersebut seharusnya mempunyai seluruh permission yang sekarang dimilikinya?\u201d<\/strong><\/p>\n\n\n\n Account dengan phishing-resistant MFA tetapi administrator privilege terhadap sepuluh system masih mempunyai blast radius tinggi jika session atau endpoint-nya compromised.<\/p>\n\n\n\n Karena itu:<\/p>\n\n\n\n Strong Authentication \u2260 Safe Authorization<\/strong><\/p>\n\n\n\n Enterprise membutuhkan keduanya.<\/p>\n\n\n\n Single Sign-On dan identity federation mempunyai manfaat besar. User tidak perlu mengelola credential terpisah untuk setiap system, onboarding dan offboarding lebih mudah, policy dapat dikelola secara centralized, dan authentication control dapat dibuat lebih konsisten.<\/p>\n\n\n\n NIST SP 800-63C-4<\/a> membahas identity federation di mana credential service provider dapat memberikan authentication dan identity assertions kepada separately administered relying parties.<\/p>\n\n\n\n Namun centralization juga menciptakan concentration risk.<\/p>\n\n\n\n Jika satu identity provider menjadi gateway menuju banyak applications, compromise pada identity control plane dapat mempunyai broad consequence.<\/p>\n\n\n\n Hal ini bukan alasan menghindari SSO.<\/p>\n\n\n\n Sebaliknya, central identity architecture memungkinkan stronger governance jika dirancang dengan benar.<\/p>\n\n\n\n Tetapi critical identity infrastructure perlu diperlakukan sebagai tier-zero security asset<\/strong>, karena banyak system menggantungkan trust kepadanya.<\/p>\n\n\n\n Security review sering menilai account berdasarkan role label.<\/p>\n\n\n\n \u201cAdministrator.\u201d<\/p>\n\n\n\n \u201cFinance user.\u201d<\/p>\n\n\n\n \u201cVendor.\u201d<\/p>\n\n\n\n Namun role name tidak selalu menunjukkan actual exposure.<\/p>\n\n\n\n Dua administrator dapat mempunyai permission berbeda. Satu vendor account dapat hanya membuka ticketing portal, sementara vendor lain dapat login ke production server.<\/p>\n\n\n\n Karena itu, Crocodic menggunakan Identity Blast Radius<\/strong> untuk melihat consequence jika identity compromised.<\/p>\n\n\n\n Framework sederhananya:<\/p>\n\n\n\n Identity \u2192 Privilege \u2192 Reachable Systems \u2192 Reachable Data \u2192 Available Actions \u2192 Downstream Dependencies \u2192 Business Impact<\/strong><\/p>\n\n\n\n Identity dengan broad access terhadap low-criticality resources mungkin mempunyai risk lebih rendah daripada identity yang hanya mempunyai satu access tetapi langsung menuju payment system.<\/p>\n\n\n\n Business criticality harus tetap menjadi layer utama.<\/p>\n\n\n\n Enterprise dapat memulai assessment menggunakan model berikut:<\/p>\n\n\n\nIdentity Mengubah Cara Kita Melihat Attack Surface<\/strong><\/h2>\n\n\n\n
Identity Attack Surface Lebih Luas daripada User Account<\/strong><\/h2>\n\n\n\n
Crocodic Identity Attack Surface Framework<\/strong><\/h2>\n\n\n\n
Compromised Credential Menjadi Berbahaya karena Sistem Menganggap Attacker sebagai User yang Sah<\/strong><\/h2>\n\n\n\n
Excessive Privilege Memperbesar Blast Radius<\/strong><\/h2>\n\n\n\n
Privileged Account Membutuhkan Treatment yang Berbeda<\/strong><\/h2>\n\n\n\n
Standing Privilege Membuat Attack Window Lebih Panjang<\/strong><\/h2>\n\n\n\n
Stale Account adalah Attack Surface yang Tidak Menghasilkan Business Value<\/strong><\/h2>\n\n\n\n
Role Change Dapat Menciptakan Privilege Accumulation<\/strong><\/h2>\n\n\n\n
Service Account Dapat Menjadi Jalur dengan Privilege Sangat Besar<\/strong><\/h2>\n\n\n\n
API Key dan Integration Token Adalah Identity dalam Bentuk Lain<\/strong><\/h2>\n\n\n\n
Machine Identity Akan Semakin Penting pada Cloud, Automation, dan AI<\/strong><\/h2>\n\n\n\n
Vendor Access Membawa Identity dari Luar Boundary Organisasi<\/strong><\/h2>\n\n\n\n
MFA Penting, tetapi MFA Tidak Menyelesaikan Excessive Privilege<\/strong><\/h2>\n\n\n\n
Federation dan SSO Mengurangi Friction tetapi Meningkatkan Concentration of Trust<\/strong><\/h2>\n\n\n\n
Identity Blast Radius Perlu Diukur dari Resource yang Dapat Dicapai<\/strong><\/h2>\n\n\n\n
Crocodic Identity Exposure Map<\/strong><\/h2>\n\n\n\n