Meta & Google AI Selfie & Video Liveness Active/Passive Video Motion • Deepfake Anti-Spoofing • 512-d Face Vector Embeddings NIST IAL2 / eKYC ត្រូវបានប្រើប្រាស់ដោយ Meta (Facebook / Instagram) សម្រាប់ស្តារគណនីឡើងវិញ (Account Recovery) និង Google (Google Wallet / Cloud Identity) សម្រាប់ eKYC។ កម្មវិធីបាញ់បញ្ជូនវីដេអូខ្លី ឬរូបថត real-time ហើយម៉ូឌែល AI វិភាគចលនាទម្រង់មុខ (ងាកឆ្វេងស្ដាំ, បិទបើកភ្នែក) ព្រមទាំងគណនា vector ផ្ទៃមុខ 512-d ដើម្បីផ្ទៀងផ្ទាត់ជាមួយ Vault ទិន្នន័យ។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
ដែនកំណត់ Cloud AI Identity Proofing (NIST IAL2/IAL3)។ ការពារការលួចគណនី នៅពេលដែលអ្នកប្រើប្រាស់បាត់បង់ទូរស័ព្ទ, ឧបករណ៍ Hardware Passkeys ឬ 2FA។
POST /v1/identity/selfie-liveness HTTP/1.1
{
"motionLiveness": { "headYaw": 24.5, "blinkCount": 3, "score": 0.998 },
"embeddingVector": [-0.012, 0.482, ...]
} Strengths: / ចំណុចខ្លាំង៖ ស្ដារគណនីបានដោយសុវត្ថិភាពខ្ពស់ដោយមិនបាច់ប្រើលេខសម្ងាត់ និងការពារ Deepfake និងរូបថតបោកប្រាស់។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ ត្រូវអនុវត្តតាមច្បាប់ឯកជនភាពទិន្នន័យ (GDPR/BIPA) និងត្រូវការប្រព័ន្ធលុបទិន្នន័យវីដេអូស្វ័យប្រវត្តិ។Best for: / សមស្របបំផុតសម្រាប់៖ Account Recovery, eKYC Onboarding, Meta Pay & Google Wallet View wire code / មើលកូដ Request
១. Passkeys & WebAuthn / ជីវមាត្រ W3C Standard • Face ID / Fingerprint / Iris មិនប្រើ Password ប្រើប្រាស់បច្ចេកវិទ្យាជីវមាត្រ hardware (Face ID, Touch ID / ស្នាមម្រាមដៃ, ស្កេនប្រស្រីភ្នែក) នៅក្នុងបន្ទះឈីប Secure Enclave / TPM នៃទូរស័ព្ទ។ ទិន្នន័យជីវមាត្រ មិនដែលចាកចេញពីទូរស័ព្ទឡើយ ។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
ដែនកំណត់ Hardware ជីវមាត្រ។ ការពារការ Phishing ១០០% — រូបភាពជីវមាត្រនៅក្នុងទូរស័ព្ទ ហើយ Server ទទួលបានតែ Cryptographic Signature ប៉ុណ្ណោះ។
navigator.credentials.get({
publicKey: { challenge: new Uint8Array(...),
userVerification: "required" }
}); Strengths: / ចំណុចខ្លាំង៖ ការពារ Credential Phishing ១០០%, គ្មាន Password ត្រូវលេចធ្លាយ, លឿននិងរលូន។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ ត្រូវមានយុទ្ធសាស្ត្រ Account Recovery ពេលអ្នកប្រើប្រាស់បាត់បង់ឧបករណ៍ Hardware។Best for: / សមស្របបំផុតសម្រាប់៖ កម្មវិធីធនាគារ (Mobile Banking), Zero-Trust Authentication View wire code / មើលកូដ Request
២. API Keys Layer 7 • Service Identification Project / Metering ជា String វែងដែលផ្ដល់ឱ្យ Developer ឬប្រព័ន្ធខាងក្រៅ ដើម្បីសម្គាល់ថា តើកម្មវិធីមួយណា កំពុងហៅប្រើប្រាស់ API សម្រាប់កំណត់ Rate Limit, Quotas និងប្រព័ន្ធគិតប្រាក់ (Billing)។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
ការពារ API Gateway ពីការប្រើប្រាស់ហួសកម្រិត (Quota Limit)។ វាមិនមែនជាឧបករណ៍បញ្ជាក់អត្តសញ្ញាណអ្នកប្រើប្រាស់ (User Identity) ឡើយ!
GET /v1/telemetry HTTP/1.1
X-API-Key: api_live_9f823a1b4c7d2e... Strengths: / ចំណុចខ្លាំង៖ ងាយស្រួលរៀបចំ, ផ្ទៀងផ្ទាត់រហ័សនៅ API Gateway level, ងាយស្រួលកំណត់ Rate Limit។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ ងាយស្រួលជ្រុះលេចធ្លាយ ប្រសិនបើសរសេរ Hardcode ក្នុងកូដ Frontend JavaScript។Best for: / សមស្របបំផុតសម្រាប់៖ Public B2B APIs, SDK Integrations View wire code / មើលកូដ Request
៣. Basic Authentication RFC 7617 • HTTP Protocol Level Point-to-Point ផ្ញើឈ្មោះអ្នកប្រើប្រាស់ និងលេខសម្ងាត់ ដោយភ្ជាប់គ្នារវាងសញ្ញាចុចពីរ (user:pass) ហើយធ្វើការ Base64 Encode ជាមួយ គ្រប់ HTTP request ទាំងអស់ ។ ត្រូវតែប្រើប្រាស់ជាមួយ HTTPS/TLS ដាច់ខាត។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
ការពារការចូលប្រើប្រាស់ Server ដោយផ្ទាល់តាមរយៈបណ្តាញចរាចរណ៍ HTTPS ដែលបាន Encrypt។
GET /admin/dashboard HTTP/1.1
Authorization: Basic YWRtaW46c2VjcmV0MTIz Strengths: / ចំណុចខ្លាំង៖ មានស្រាប់នៅក្នុង Web Browser និង Web Server (Nginx / Apache)។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ Base64 មិនមែនជាការ Encryption ទេ! លេខសម្ងាត់ត្រូវផ្ញើគ្រប់ Request។Best for: / សមស្របបំផុតសម្រាប់៖ Internal Dashboards, Internal Webhooks View wire code / មើលកូដ Request
៤. Session Cookies & CSRF Tokens Stateful Cookie • HttpOnly & SameSite Browser First Server រក្សាទុក Session State ក្នុង Redis/DB ហើយផ្ញើ HttpOnly; Secure; SameSite=Strict Cookie ទៅកាន់ Browser។ ប្រើប្រាស់អមដោយ Anti-CSRF header ដើម្បីការពារការវាយប្រហារ Cross-Site Request Forgery។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
ការពារ Web Portal រៀបចំតាមបែបបុរាណ។ ដោត <code class="text-[var(--teal)]">HttpOnly</code> ការពារ JavaScript XSS មិនឱ្យលួចអាន Cookie ឡើយ។
Set-Cookie: sid=s%3A982a1...; HttpOnly; Secure; SameSite=Strict
X-CSRF-Token: d98f312a0f81... Strengths: / ចំណុចខ្លាំង៖ អាច Revoke/លុប Session ភ្លាមៗពី Server DB; JavaScript មិនអាចលួចអាន HttpOnly cookie បានឡើយ។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ ត្រូវស្វែងរកមើល DB គ្រប់ Request (Stateful DB lookup); មានបញ្ហា CORS លើ Mobile Apps។Best for: / សមស្របបំផុតសម្រាប់៖ SSR Web Portals, Web Banking Dashboards View wire code / មើលកូដ Request
៥. Bearer Tokens RFC 6750 • Possession-Based Access Access Token "ផ្ដល់សិទ្ធិឱ្យអ្នកណាដែលកាន់ Token នេះ"។ Server បង្កើត Token String ផ្ញើឱ្យ Client ហើយ Client ផ្ញើវានៅក្នុង Authorization Header ដើម្បីស្នើសុំទិន្នន័យ។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
បំបែក Credential សម្ងាត់ (Password) ចេញពី API Resource Server។ API មិនចាំបាច់មើលឃើញ Password របស់អ្នកប្រើប្រាស់ឡើយ។
POST /api/v1/orders HTTP/1.1
Authorization: Bearer v2.local.8a93b71c... Strengths: / ចំណុចខ្លាំង៖ Password មិនលេចធ្លាយទៅកាន់ 3rd party clients; ងាយស្រួលកំណត់ Scopes និងពេលវេលាផុតកំណត់ (TTL)។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ ងាយរងគ្រោះបើ Token ត្រូវគេលួចបាន; ត្រូវតែរៀបចំការរក្សាទុក Token ឱ្យមានសុវត្ថិភាព។Best for: / សមស្របបំផុតសម្រាប់៖ Web Apps, Mobile APIs, OAuth output View wire code / មើលកូដ Request
៦. JWT (JSON Web Token) RFC 7519 • Self-Contained Claims Stateless Assertion បែងចែកជា ៣ ផ្នែក (Header .Payload .Signature )។ អនុញ្ញាតឱ្យ Microservices ផ្ទៀងផ្ទាត់ Claims ដោយមិនបាច់សួរ DB (Stateless) ដោយប្រើ Public Key។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
ការពារ Microservices ពីការកកស្ទះនៃការស្វែងរកក្នុង DB។ ផ្លាស់ប្តូរការផ្ទៀងផ្ទាត់មកជាការផ្ទៀងផ្ទាត់ Cryptographic Signature។
Authorization: Bearer eyJhbG...eyJzdWI...SflKxw... Strengths: / ចំណុចខ្លាំង៖ មិនបាច់សួរ DB ដើម្បីផ្ទៀងផ្ទាត់ Token; ល្អឥតខ្ចោះសម្រាប់ Microservices Mesh។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ ពិបាក Revoke/លុបចោលភ្លាមៗ; ទិន្នន័យក្នុង Payload គ្រាន់តែធ្វើ Base64 មិនមែន Encrypted ទេ!Best for: / សមស្របបំផុតសម្រាប់៖ Microservice meshes, Distributed Auth View wire code / មើលកូដ Request
៧. OAuth 2.0 RFC 6749 • Delegated Scope Framework Authorization ជា Authorization Framework (មិនមែន Authentication ទេ!) ដែលអនុញ្ញាតឱ្យកម្មវិធីទីបី (3rd Party) ទទួលបានសិទ្ធិប្រើប្រាស់ Resource ដោយមិនចាំបាច់ស្គាល់ Password ដើម។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
ការពារម្ចាស់ទិន្នន័យ មិនឱ្យប្រគល់ Password ទៅឱ្យកម្មវិធី 3rd Party។ កំណត់សិទ្ធិយ៉ាងលម្អិតតាមរយៈ <code class="text-[var(--slate-accent)]">scopes</code>។
POST /oauth/token HTTP/1.1
grant_type=authorization_code&code=SplxlOBe... Strengths: / ចំណុចខ្លាំង៖ កំណត់សិទ្ធិបានលម្អិត (Granular Scopes), មានសុវត្ថិភាពខ្ពស់, គាំទ្រ PKCE សម្រាប់ Mobile Apps។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ ស្ថាបត្យកម្មមានភាពស្មុគស្មាញ; បើប្រើប្រាស់ច្រឡំជា Authentication នឹងបង្កើតចន្លោះប្រហោងសន្តិសុខ។Best for: / សមស្របបំផុតសម្រាប់៖ Third-party API ecosystems, Social Login Grants View wire code / មើលកូដ Request
៨. OpenID Connect (OIDC) Identity Layer លើ OAuth 2.0 Federated Identity បន្ថែម ID Token (JWT) ទៅលើ OAuth 2.0 ដើម្បីធ្វើ Authentication (ផ្ទៀងផ្ទាត់អត្តសញ្ញាណ)។ ផ្ដល់ព័ត៌មានអត្តសញ្ញាណស្តង់ដារ (sub, email, name)។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
បង្កើតដែនកំណត់ Single Sign-On (SSO) រវាង Identity Providers (Okta, Auth0, Keycloak) និង Client Applications។
{ "id_token": "eyJhbG...", "access_token": "v2.local..." } Strengths: / ចំណុចខ្លាំង៖ អត្តសញ្ញាណស្តង់ដាររួមសម្រាប់ Enterprise Apps, មាន Discovery Endpoint (<code class="text-[var(--slate-accent)]">/.well-known</code>)។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ ID tokens ត្រូវតែផ្ទៀងផ្ទាត់យ៉ាងម៉ឺងម៉ាត់ជាមួយ Audience ដែលបានរំពឹងទុក។Best for: / សមស្របបំផុតសម្រាប់៖ Enterprise Single Sign-On (SSO) View wire code / មើលកូដ Request
៩. SAML 2.0 XML Security Standard • B2B Enterprise Enterprise Legacy ប្រើប្រាស់ Signed XML Assertions ផ្លាស់ប្តូរគ្នាតាមរយៈ HTTP POST Redirects រវាង Identity Provider (IdP) និង Service Provider (SP)។ ចាំបាច់សម្រាប់ប្រព័ន្ធ Enterprise IT។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
ការពារដែនកំណត់ក្រមក្រុមហ៊ុនធំៗ (Active Directory / LDAP Federation) តាមរយៈ XML Digital Signatures។
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Assertion ID="_a98213...">...</saml:Assertion>
</samlp:Response> Strengths: / ចំណុចខ្លាំង៖ គាំទ្រយ៉ាងទូលំទូលាយលើប្រព័ន្ធ IT Enterprise ធំៗ និង Active Directory។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ ទំហំ XML ធំខ្លាំង, ការគ្រប់គ្រង Certificate ស្មុគស្មាញ, ពិបាក Parse លើ Mobile Apps។Best for: / សមស្របបំផុតសម្រាប់៖ Enterprise B2B SaaS, Government IT Systems View wire code / មើលកូដ Request
១០. HMAC Signatures RFC 2104 • Hash Message Auth Integrity + Non-Replay Client ចុះហត្ថលេខាលើ Method, URI, Timestamp, និង Body ដោយប្រើប្រាស់ Shared Secret Hash (HMAC-SHA256)។ Server គណនា Hash ឡើងវិញដើម្បីផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវនៃទិន្នន័យ។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
ការពារទិន្នន័យកំពុងធ្វើដំណើរ (Data-in-Transit) ពីការកែបន្លំ (Tampering) និងការវាយប្រហារ Replay Attacks។
X-Signature: t=1720000000,v1=9f8a32b1c4e7... Strengths: / ចំណុចខ្លាំង៖ ធានាថាទិន្នន័យមិនត្រូវគេកែបន្លំ; ការពារ Replay Attack តាមរយៈការពិនិត្យ Timestamp។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ ត្រូវការម៉ោង (Clock Synchronize) ត្រឹមត្រូវរវាង Client និង Server។Best for: / សមស្របបំផុតសម្រាប់៖ Payment Webhooks (Stripe/GitHub), Financial APIs View wire code / មើលកូដ Request
១១. Mutual TLS (mTLS) Layer 4/5 • Cryptographic Handshake Zero-Trust Hardware ទាំង Client និង Server ផ្ទៀងផ្ទាត់ X.509 Digital Certificate របស់គ្នាទៅវិញទៅមក ក្នុងអំឡុងពេល TLS Handshake មុនពេលទិន្នន័យ HTTP ត្រូវបានផ្ញើ ។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
ការពារ Layer បណ្តាញចរាចរណ៍ (Network Transport)។ Request ដែលគ្មានការផ្ទៀងផ្ទាត់ ត្រូវផ្លាច់ចោលនៅត្រឹម Socket Level!
ClientCert: CN=payment-service.prod.internal
Status: 200 TLS_AES_256_GCM_SHA384 Established Strengths: / ចំណុចខ្លាំង៖ កម្រិតសន្តិសុខខ្ពស់បំផុត; ការពារការជ្រុះលេចធ្លាយ Credential នៅកម្រិត Application Layer។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ ស្មុគស្មាញក្នុងការគ្រប់គ្រង និងផ្លាស់ប្តូរ Certificate (PKI Certificate rotation)។Best for: / សមស្របបំផុតសម្រាប់៖ Banking Mesh, Kubernetes Pod-to-Pod Communications View wire code / មើលកូដ Request
១២. Risk-Based Adaptive MFA AI / Behavioral • Context & Geofencing Zero-Trust AI វិភាគសញ្ញាជុំវិញ real time (IP, Geolocation, Device Fingerprint, ល្បឿនធ្វើដំណើរមិនសមហេតុផល) ដើម្បីទាមទារ Step-Up Biometrics នៅពេលកម្រិតហានិភ័យកើនឡើង។
Trust boundary protected / ដែនកំណត់ទំនុកចិត្តដែលត្រូវបានការពារ
ការពារការលួច Session និងការវាយប្រហារ Credential Stuffing ដោយគណនា Trust Score ឡើងវិញគ្រប់ Request។
RiskScore: 0.82 (High - Unknown IP)
Action: Step-Up Prompt WebAuthn Biometric Required Strengths: / ចំណុចខ្លាំង៖ គ្មានការរំខានសម្រាប់អ្នកប្រើប្រាស់ធម្មតា; ទប់ស្កាត់ Session ដែលត្រូវបានគេលួចភ្លាមៗ។Risks: / ហានិភ័យ/ចំណុចកត់សម្គាល់៖ អាចមាន False Positive ទាមទារឱ្យផ្ទៀងផ្ទាត់ពេលអ្នកប្រើប្រាស់ធ្វើដំណើរ។Best for: / សមស្របបំផុតសម្រាប់៖ Fintech, Crypto Exchanges, High Security Apps View wire code / មើលកូដ Request