Skip to main content

ความปลอดภัยและคุณภาพ

ความปลอดภัยในรีโพนี้เป็นการผสมกันของการควบคุมในรันไทม์ guardrail ของโครงสร้างพื้นฐาน และวินัยในเวิร์กโฟลว์การพัฒนา

ประเด็นสำคัญสำหรับผู้มีส่วนร่วมคือ:

คุณภาพไม่ใช่เครื่องมือชิ้นเดียว แต่มันคือห่วงโซ่ของการควบคุมที่ครอบคลุมโค้ดแอป identity การปรับใช้ และการรีวิว

โมเดลความปลอดภัยในปัจจุบัน​

ขอบเขต identity​

ทิศทางสถาปัตยกรรมในปัจจุบันคือ:

  • Authentik เป็นผู้ให้บริการ identity
  • Supabase ยังคงเป็นชั้นข้อมูลและการอนุญาต
  • ไคลเอนต์ของแอปและแอดมินไม่ได้กลายเป็นแหล่งความจริงด้าน identity ของตัวเอง

นี่เป็นการแยกที่ดี เพราะทำให้ ownership ของการยืนยันตัวตนชัดเจน

การจัดการ input ของ API​

NestJS API เปิดใช้ค่า validation ที่สำคัญไว้แล้ว:

  • ValidationPipe
  • whitelist: true
  • transform: true
  • forbidNonWhitelisted: true

ค่าเริ่มต้นเหล่านี้ช่วยลดข้อผิดพลาดเรื่องรูปทรงของ input และการ over-post โดยไม่ตั้งใจ

การจัดการ secret และ environment​

รีโพนี้ยังมีแนวทางจัดการ environment ที่ให้ infra มาก่อน:

  • สคริปต์ deploy ที่ยึด environment เป็นหลัก
  • การเชื่อมต่อกับ Secrets Manager ใน identity stack
  • configuration ที่รับรู้ stage
  • guard ของการ deploy รอบประเภท stack และการ reconcile pipeline

การควบคุมคุณภาพในรีโพ​

การควบคุมคุณภาพแบบ static​

  • TypeScript ในทุกแอปและแพ็กเกจ
  • ESLint
  • Prettier
  • lint-staged
  • Husky hook สำหรับ pre-commit และ pre-push
  • eslint-plugin-security

การควบคุมการตรวจสอบและรีลีส​

  • สคริปต์ตรวจสอบเวอร์ชัน
  • hook สำหรับสแกน secret
  • orchestration ของ build, lint, type-check และ test ด้วย Turbo
  • สคริปต์ความปลอดภัยของ branch และ pipeline ใน packages/infra/scripts

คุณภาพของเอกสารและ API​

  • เอกสาร Docusaurus ถูก build จาก monorepo เดียวกัน
  • API เปิดเผยเอกสาร Swagger / OpenAPI
  • มีเอกสารด้านปฏิบัติการในรีโพแล้วสำหรับการตัดสินใจเรื่อง identity และ infra

เช็กลิสต์สำหรับผู้มีส่วนร่วม​

เมื่อเปลี่ยนโค้ดในรีโพนี้ ควรตรวจเช็กอย่างตั้งใจว่า:

  1. การตรวจสอบ input: endpoint หรือฟังก์ชันตรวจสอบรูปแบบและชนิดอย่างเข้มงวดหรือไม่?
  2. การจัดการ secret: มี secret ใดหลุดไปยังโค้ดฝั่งไคลเอนต์ log หรือไฟล์ที่ commit ไหม?
  3. ขอบเขต auth: การเปลี่ยนแปลงนี้เคารพโมเดล identity เดิม แทนที่จะเลี่ยงมันหรือไม่?
  4. การรับรู้ stage: การเปลี่ยนแปลงนี้ทำงานถูกต้องใน dev, production และ preview/testnet หรือไม่?
  5. ความปลอดภัยของ infra: การเปลี่ยนแปลงนี้อาจทำให้เกิดผลกระทบแบบทำลายล้างในการ deploy หรือไม่?
  6. ผลกระทบต่อ docs: พฤติกรรมสาธารณะหรือเชิงปฏิบัติการต้องอัปเดตเอกสารหรือไม่?

จุดแข็งในปัจจุบัน​

สิ่งเหล่านี้เป็นสัญญาณเชิงบวกที่มีอยู่แล้วในรีโพ:

  • การแยกแอปสาธารณะ แอดมิน เอกสาร API และ infra อย่างชัดเจน
  • มอง identity เป็น subsystem โดยเฉพาะ
  • จัดการโครงสร้างพื้นฐานด้วยโค้ด
  • มีระบบอัตโนมัติของการรีลีสใน monorepo แล้ว
  • ใช้แพ็กเกจร่วมแทนการคัดลอกแบบไร้การควบคุม
  • เว็บไซต์ docs สาธารณะเป็นส่วนหนึ่งของแพลตฟอร์มอยู่แล้ว

ช่องว่างและความเสี่ยงที่ทราบอยู่แล้ว​

สถาปัตยกรรมปัจจุบันแข็งแรงพอจะเติบโตต่อได้ แต่ยังมีช่องว่างหลายจุดที่มองเห็นได้

1. ระดับความปลอดภัยของ API ยังต้องเข้มขึ้น​

ตัวอย่าง:

  • CORS ใน Nest bootstrap ยังเปิดกว้างเกินไป
  • พื้นผิวของ API แบบกำหนดเองยังอยู่ช่วงต้นและต้องการ policy hardening เพิ่ม
  • เมื่อ API โตขึ้น จะต้องมี auth และ authorization ระดับ endpoint ที่ครอบคลุมกว่านี้

2. ความครอบคลุมของการทดสอบยังไม่สม่ำเสมอ​

บางส่วนของรีโพมีรูปแบบการทดสอบแล้ว แต่ความครอบคลุมยังไม่โตเท่ากันในทุกแอปและบริการ

3. Observability ยังเบาอยู่​

รันไทม์บน AWS มี log แล้ว แต่แพลตฟอร์มยังต้องการเรื่องปฏิบัติการที่เข้มขึ้นในด้าน:

  • tracing แบบมีโครงสร้าง
  • dashboard ระดับบริการ
  • การแจ้งเตือน
  • การมองเห็นสุขภาพระดับ deployment

4. ระบบอัตโนมัติด้านความปลอดภัยยังไปได้ไกลกว่านี้​

มีฐานที่ดีอยู่แล้ว แต่รีโพนี้จะได้ประโยชน์จากสิ่งที่เป็นทางการมากขึ้น เช่น:

  • การรีวิว dependency
  • การสร้าง SBOM
  • provenance ของ artifact
  • การสแกน container และ image เมื่อเกี่ยวข้อง
  • threat modeling สำหรับบริการใหม่

5. คำอธิบายสถาปัตยกรรมสาธารณะยังตามงาน implementation อยู่​

ส่วนใหม่นี้ช่วยให้ดีขึ้น แต่บันทึกสถาปัตยกรรมยังต้องเดินให้ทันการพัฒนา

เวิร์กโฟลว์ด้าน Linting และความปลอดภัย​

สำหรับงานวิศวกรรมประจำวัน baseline ที่ใช้งานได้จริงคือ:

pnpm lint
pnpm type-check
pnpm test
pnpm --filter @alternun/api run build
pnpm --filter alternun-docs run build

ถ้าการเปลี่ยนแปลงแตะโครงสร้างพื้นฐานหรือ identity ผู้มีส่วนร่วมควรตรวจดูสคริปต์และการตั้งค่าที่เกี่ยวข้องใน packages/infra เพิ่มเติมก่อนจะสรุปว่าการ deploy นั้นปลอดภัย

คำประกาศสาธารณะด้านความปลอดภัย​

Alternun กำลังสร้างแบบเปิดเผย แต่ไม่ควรสับสนระหว่างความโปร่งใสกับการควบคุมที่หละหลวม

ท่าทีเป้าหมายคือ:

  • การมองเห็นสถาปัตยกรรมแบบสาธารณะ
  • การจัดการ secret แบบเป็นส่วนตัว
  • ขอบเขตความไว้วางใจที่ชัดเจน
  • deployment ที่ทำซ้ำได้
  • ค่าเริ่มต้นด้านปฏิบัติการที่ระมัดระวัง

นี่คือมาตรฐานที่ผู้มีส่วนร่วมควรรักษาไว้