4.9 · Scorecard + comparison

บทสุดท้ายของ Volume 4 สรุป health ของ cu-central-api ตาม dimension เทียบกับ vtrc-api และ outline modernization target

---

Health scorecard

Dimension	Current State	After Wave 0	After Wave 2 (target)
Authentication	🔴 JWT_SECRET empty default, /auth/signinbypass, hardcoded apiKeys	🟡 rotated secrets + hard-fail	🟢 go-ldap + golang-jwt + OIDC
Authorization	🔴 requires commented out, ignoreAuth bypass	🟡 remove bypass + implement RBAC	🟢 Casbin + policy test matrix
Data layer	🟡 6 connections, SourceDB sharding works	🟡 fix dead dbHRMI_test	🟢 shard-per-connection + sqlc
Schema	🟡 31 SDL files, dead payrollSlip_removed.js	🟡 purge dead files	🟢 gqlgen + co-located ops
Integrations	🟡 SSO + Conicle + HIS + HRMI + SMS + SMTP	🟡 add timeout/retry	🟢 outbound port adapters
Security	🔴 4 Critical + 6 High	🟡 Wave 0 ปิดทั้งหมด	🟢 strict types + secret manager
Runtime	🔴 Node 12 + esm shim + Apollo v2	🟡 Node 20 LTS + native ESM	🟢 Go runtime
HA / scaling	🔴 in-process cron, no rate limit	🟡 BullMQ + rate limit	🟢 Asynq + autoscaling

Legend

• 🔴 Critical = active risk
• 🟡 High = impact จริงแต่มีเงื่อนไข
• 🟢 Medium/Good = hygiene ที่ทำได้

---

เปรียบเทียบ cu-central-api vs vtrc-api

Aspect	vtrc-api	cu-central-api
Stack	Node 12 + Apollo v2 + Sequelize + MariaDB	Node 12 + Apollo v2 + Sequelize + MSSQL
DB connections	2 (db + db2)	6 (db + dbHr + dbHrTemp + dbMasDb + dbHRMI_test + dbHRMI_Center_HIS)
Auth source	local DB + forward ไป cu-central-api	LDAP/AD direct bind
apiKey	config.js (7 prod keys)	hardcoded 2 keys
JWT default	'secret'	'' (empty)
Schema size	ใหญ่กว่ามาก	2,629 LOC SDL + 1,826 LOC resolvers
Multi-tenancy	single DB	SourceDB sharding ทุก association
Cron	node-schedule in-process	node-schedule + APP_NO gating
Introspection	🔴 true เสมอ	🟢 gate ด้วย IS_PRODUCTION
CORS	🔴 typo + default *	🟢 ไม่ set CORS (delegated ไป nginx)
REST routes	77 KB routes.js	64 LOC routes.js (5 endpoints)
execSync injection	🔴 5 endpoints	🟢 ไม่มี
SQL injection	🔴 statLog.js	🟢 ไม่พบ
File upload	🔴 multer no filter	🟢 ไม่มี
Rate limit	🔴 ไม่มี	🔴 ไม่มี
Modernization target	decompose เป็นหลาย Go services	decompose เป็น identity + hr-data services

---

cu-central-api ดีกว่า vtrc-api ตรงไหน

1. ไม่มี execSync injection — ไม่มี PDF/qpdf stack จึงไม่มี vector นี้
2. ไม่มี SQL injection — ทุก raw query ใช้ parameterized bindings ถูกต้อง
3. Gate introspection/playground ด้วย IS_PRODUCTION — ไม่ leak schema ใน prod
4. ไม่มี CORS bug — ไม่ set CORS เลย (delegated ไป nginx)
5. Session lookup ดีกว่า — Redis key pattern ตรง ไม่ใช่ LIKE '%jwtid%' JSON scan
6. ไม่มี file upload — ไม่มี multer/path-traversal surface

cu-central-api แย่กว่าตรงไหน

1. JWT_SECRET default empty — แย่กว่า 'secret' ของ vtrc-api เพราะ "" ดูเหมือน "ยังไม่ set" ทำให้มีโอกาสลืม set env
2. /auth/signinbypass passwordless — endpoint ที่ vtrc-api ไม่มี
3. ignoreAuth bypass — pattern ที่ vtrc-api ไม่มี (apiKey อย่างเดียวพอ)
4. LDAP TLS ปิด — rejectUnauthorized: false ใน LDAP connection
5. 6 DB connections — ซับซ้อนกว่า 2 ของ vtrc-api (และมี dead connection)
6. SourceDB sharding complexity — pattern ที่ไม่มีใน vtrc-api และมี boilerplate มหาศาล
7. apiKeys hardcoded — vtrc-api เก็บใน config (แยกไฟล์) แต่ cu-central-api hardcode ใน controller เลย

---

Modernization target

ตาม audit/05-tech-debt-register.md §5.3 ลำดับ Wave 2

Order	Bounded Context	Target
1	document-renderer (จาก vtrc-api)	—
2	identity (รวม cu-central-api auth)	Go + Casbin + Postgres
3	payroll	—
4	time-attendance	—
5	leave	—
6	welfare	—
7	hr-data (cu-central-api HR queries)	Go + per-shard connection

cu-central-api จะถูก decompose เป็น 2 contexts หลัก

identity-service

รับผิดชอบ

• LDAP/AD bind (ผ่าน go-ldap/ldap/v3)
• JWT issuance (ผ่าน golang-jwt/jwt/v5)
• Session store (ผ่าน go-redis)
• RBAC policy (ผ่าน Casbin)

cmd/
└── identity-service/
internal/identity/
├── domain/         (User, Session, Role, Grant)
├── port/           (Authenticator, SessionStore)
├── adapter/
│   ├── ldap/       (go-ldap adapter)
│   ├── redis/      (session store)
│   └── jwt/        (token signer)
└── usecase/        (login, refresh, logout, authorize)

hr-data-service

รับผิดชอบ

• HR data read/write (MSSQL per-shard)
• SourceDB sharding เป็นรายละเอียดภายใน service (ผู้เรียกไม่ต้องรู้)
• HRMI HTTP API integration

cmd/
└── hr-data-service/
internal/hrdata/
├── domain/         (Employee, Organization, Payroll, ...)
├── port/           (EmployeeRepo, OrgRepo)
├── adapter/
│   ├── mssql/      (per-shard connection pool)
│   ├── hrmi/       (HTTP API client)
│   └── his/        (heal-card API client)
└── usecase/        (getEmployee, updateAddress, ...)

---

Cross-reference ไป volume อื่น

Volume	Topic	Relevance
Volume 2	Architecture & Topology	cu-central-api ใน topology
Volume 3	vtrc-api Deep Dive	comparison
Volume 8	Data Model & Persistence	MSSQL schemas
Volume 9.5	Credentials + secrets	.env.develop-test
Volume 15	Modernization	Go target

---

สรุป Volume 4

cu-central-api เป็น satellite service ที่โครงสร้างคล้าย vtrc-api ในหลายด้าน แต่มีจุดเด่นเฉพาะตัว

1. LDAP/AD auth — เป็นเจ้าของ credential verification จริง (vtrc-api forward มา)
2. SourceDB sharding — pattern ที่ไม่มีใน vtrc-api และเป็นแก่นของ repo
3. 6 MSSQL connections — กระจาย 5 schemas + 1 dead
4. External integrations — SSO + Conicle + HIS + HRMI + SMS + SMTP (เป็น service เดียวที่เรียก)
5. Severity — 🔴 4 Critical + 🟡 6 High (น้อยกว่า vtrc-api แต่ก็ยังมีจำนวนมาก)

Security posture โดยรวม ดีกว่า vtrc-api ในหลายด้าน (ไม่มี execSync, ไม่มี SQLi, gate introspection ถูก) แต่มี risk เฉพาะตัว (sign-in bypass, LDAP TLS ปิด, JWT empty default)

Modernization path ชัดเจน — decompose เป็น identity-service + hr-data-service ใน Go (Volume 15)

---

กลับไป ภาพรวม Volume 4 · ไป Volume ถัดไป Volume 5 · centralize-api