0Pricing
Security+ Academy · บทเรียน

การจัดการความลับอย่างปลอดภัยและตัวแปรสภาพแวดล้อม

หลีกเลี่ยงการฝังความลับไว้ตายตัวในซอร์สโค้ด โดยใช้ตัวจัดการความลับ (Vault, AWS Secrets Manager) และแทรกค่าตัวแปรสภาพแวดล้อมขณะทำงาน

การจัดการความลับอย่างปลอดภัยและตัวแปรสภาพแวดล้อม เป็นบทเรียน Security+ Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Security+ Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน

ปัญหาข้อมูลลับที่ฝังในโค้ด

ข้อมูลลับที่ฝังในโค้ด — คีย์ API รหัสผ่านฐานข้อมูล คีย์ส่วนตัว TLS และโทเค็น OAuth ที่ฝังไว้โดยตรงในซอร์สโค้ด — เป็นช่องโหว่ด้านความปลอดภัยที่พบได้บ่อยและป้องกันได้มากที่สุดประเภทหนึ่ง ข้อมูลลับในซอร์สโค้ดจะถูกเปิดเผยในประวัติการควบคุมเวอร์ชัน (แม้จะลบไปแล้ว) นักพัฒนาทุกคนที่เข้าถึงคลังเก็บข้อมูลจะมองเห็นได้ และมักรั่วไหลเมื่อคลังเก็บข้อมูลถูกทำให้เป็นสาธารณะโดยไม่ตั้งใจ เครื่องมืออย่าง GitGuardian และ truffleHog จะสแกนหาข้อมูลลับที่รั่วไหลบนแพลตฟอร์มอย่าง GitHub อย่างต่อเนื่อง

# DANGEROUS: hardcoded secret in source code
# db_password = 'P@ssw0rd#2026'
# api_key = 'sk-live-abc123xyz789'
# aws_secret = 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'

# These secrets are now:
# - In git history (even if later deleted)
# - Visible to all repo contributors
# - Potentially in CI/CD logs
# - Often leaked when repos go public accidentally

ตัวแปรสภาพแวดล้อม: ดีกว่าแต่ยังไม่เพียงพอ

ตัวแปรสภาพแวดล้อม นำข้อมูลลับออกจากซอร์สโค้ดด้วยการส่งข้อมูลเข้ามาขณะเรียกใช้ผ่าน OS ของโฮสต์หรือเครื่องมือจัดการคอนเทนเนอร์ application จะอ่าน os.environ['DB_PASSWORD'] แทนค่าที่ฝังไว้โดยตรง วิธีนี้ดีกว่าการฝังข้อมูลลับในโค้ด แต่ตัวแปรสภาพแวดล้อมมีจุดอ่อน ได้แก่ ปรากฏในรายการกระบวนการ ถูกสืบทอดโดยกระบวนการลูก มักไปอยู่ในข้อมูลดัมป์จากการหยุดทำงานและบันทึกการแก้ไขข้อบกพร่อง และต้องหมุนเวียนด้วยตนเอง ตัวแปรเหล่านี้เหมาะสำหรับการพัฒนา แต่ไม่เพียงพอหากใช้เพียงอย่างเดียวในการจัดการข้อมูลลับสำหรับระบบจริง

# Environment variable pattern:
# In .env file (NEVER commit to git):
# DB_PASSWORD=P@ssw0rd#2026
# API_KEY=sk-live-abc123xyz789

# In .gitignore:
# .env
# *.env
# .env.*

# In application code:
# db_password = os.environ.get('DB_PASSWORD')
# api_key = os.environ.get('API_KEY')

# Risk: env vars visible in 'ps aux' output,
# inherited by child processes, appear in /proc/<pid>/environ

เครื่องมือจัดการข้อมูลลับโดยเฉพาะ

เครื่องมือจัดการข้อมูลลับ คือระบบที่สร้างขึ้นโดยเฉพาะสำหรับจัดเก็บ หมุนเวียน และตรวจสอบการเข้าถึงข้อมูลลับ โซลูชันชั้นนำ ได้แก่ HashiCorp Vault (โอเพนซอร์สและระดับองค์กร), AWS Secrets Manager, Azure Key Vault และ Google Cloud Secret Manager application จะยืนยันตัวตนกับเครื่องมือจัดการข้อมูลลับขณะทำงาน ดึงข้อมูลลับมาใช้ และนำไปใช้งาน โดยจะไม่มีการจัดเก็บข้อมูลลับไว้บนดิสก์หรือในตัวแปรสภาพแวดล้อมเลย การเข้าถึงทั้งหมดจะถูกบันทึก ทำให้ตรวจสอบได้ว่าใครเข้าถึงข้อมูลลับใดและเมื่อใด

# HashiCorp Vault secret retrieval (conceptual):
# Application authenticates to Vault using:
#   - AWS IAM role (in cloud environments)
#   - Kubernetes service account token
#   - AppRole credentials

# After authentication, retrieve secret:
# vault kv get -field=password secret/prod/database

# In application (Python SDK):
# client = hvac.Client(url='https://vault.company.com')
# client.auth.aws.iam_login(role='prod-app')
# secret = client.secrets.kv.read_secret('prod/database')
# db_password = secret['data']['password']

การหมุนเวียนข้อมูลลับโดยอัตโนมัติ

ข้อได้เปรียบสำคัญของเครื่องมือจัดการข้อมูลลับเมื่อเทียบกับตัวแปรสภาพแวดล้อมคือ การหมุนเวียนโดยอัตโนมัติ AWS Secrets Manager สามารถหมุนเวียนรหัสผ่านฐานข้อมูล RDS ตามกำหนดเวลาโดยอัตโนมัติ (เช่น ทุก 30 วัน) โดยไม่ต้องติดตั้ง application ใหม่ เครื่องมือจัดการข้อมูลลับจะอัปเดตรหัสผ่านในฐานข้อมูลและอัปเดตข้อมูลลับที่จัดเก็บไว้พร้อมกัน application ที่ดึงข้อมูลลับทุกครั้งที่เชื่อมต่อจะได้รับข้อมูลรับรองใหม่โดยอัตโนมัติ วิธีนี้ช่วยยกเลิกแนวปฏิบัติทั่วไปในการใช้รหัสผ่านบัญชีบริการแบบ “ถาวร” ที่ไม่เคยหมุนเวียน

# AWS Secrets Manager rotation configuration:
# Secret:         prod/app-database-credentials
# Rotation:       enabled
# Frequency:      every 30 days
# Lambda function: SecretsManager-MyRDSRotation

# Rotation process:
# 1. Lambda creates new DB password
# 2. Updates secret in Secrets Manager
# 3. Updates password on RDS instance
# 4. Tests new credentials work
# 5. Deprecates old credentials
# Application: always calls GetSecretValue at runtime -> gets fresh value

การป้องกันด้วย .gitignore

แนวป้องกันด่านแรกจากการส่งความลับเข้าไปในคลังโค้ดคือ ไฟล์ .gitignore ที่ดูแลรักษาอย่างเหมาะสม ซึ่งไม่รวมไฟล์ทั้งหมดที่อาจมีความลับอยู่ อย่างไรก็ตาม .gitignore จะป้องกันได้เฉพาะการส่งไฟล์ในอนาคตเท่านั้น ความลับที่ส่งเข้าไปใน git แล้วจะยังคงอยู่ในประวัติของ git หากส่งความลับเข้าไปโดยไม่ตั้งใจ ต้องถือว่าความลับนั้นถูกเปิดเผยทันที: เปลี่ยนความลับใหม่ จากนั้นอาจใช้เครื่องมืออย่าง git filter-repo เพื่อเขียนประวัติใหม่ (จำเป็นต่อการปฏิบัติตามข้อกำหนด แต่เพียงอย่างเดียวไม่เพียงพอ เนื่องจากความลับอาจถูกดึงออกไปแล้ว)

# Recommended .gitignore entries for secret files:
# .env
# .env.*
# *.pem
# *.key
# *.p12
# *.pfx
# credentials.json
# service_account*.json
# secrets.yaml
# config/secrets.yml
# terraform.tfvars  (may contain cloud credentials)
# .aws/credentials

# Pre-commit hook to scan for secrets before commit:
# pre-commit install
# hook: detect-secrets / gitleaks / truffleHog

ความลับในโครงสร้างพื้นฐานในรูปแบบโค้ด

ไฟล์โครงสร้างพื้นฐานในรูปแบบโค้ด (IaC) (Terraform, CloudFormation, ไฟล์กำหนดค่า Kubernetes) มักมีความลับอยู่ เช่น สตริงการเชื่อมต่อฐานข้อมูล คีย์สำหรับเรียกใช้บริการในส่วนประกาศตัวแปรสภาพแวดล้อม และใบรับรอง TLS ไฟล์เหล่านี้มักถูกส่งเข้าไปในระบบควบคุมเวอร์ชัน จึงเพิ่มความเสี่ยงที่ความลับจะถูกเปิดเผย แนวทางแก้ไขได้แก่ ความลับแบบไดนามิกของ Vault (Vault จะสร้างข้อมูลรับรองอายุสั้นโดยเฉพาะสำหรับการทำงานของ Terraform แต่ละครั้ง) ความลับของ Kubernetes (จัดเก็บใน etcd และต้องเข้ารหัสขณะจัดเก็บ) และ external-secrets-operator ซึ่งซิงค์ข้อมูลจากตัวจัดการความลับเข้าสู่ Kubernetes ขณะทำงาน

หลักสิทธิ์น้อยที่สุดสำหรับความลับ

แต่ละแอปพลิเคชันหรือบริการควรเข้าถึงเฉพาะความลับที่จำเป็นโดยเฉพาะเท่านั้น ซึ่งคือ หลักสิทธิ์น้อยที่สุดที่นำมาใช้กับความลับ แอปพลิเคชันเว็บต้องใช้รหัสผ่านฐานข้อมูล แต่ไม่ต้องใช้คีย์ส่วนตัวของ CA งานสร้างรายงานต้องใช้ข้อมูลรับรองฐานข้อมูลแบบอ่านอย่างเดียว ไม่ใช่สิทธิ์เขียน ตัวจัดการความลับบังคับใช้หลักการนี้ผ่าน นโยบายการเข้าถึง ซึ่งระบุว่าอัตลักษณ์ใด (บทบาท IAM บัญชีบริการ AppRoles) สามารถอ่านความลับใดได้บ้าง พร้อมบันทึกการเข้าถึงทั้งหมดไว้เพื่อการตรวจสอบ

# Vault policy: web application can read DB password only
# policy name: web-app-policy
# path 'secret/prod/database' {
#   capabilities = ['read']
# }
# path 'secret/prod/tls-certs/*' {
#   capabilities = []  # DENY - app does not need TLS keys
# }

# This policy is assigned to the web app's AppRole.
# The reporting service gets a separate policy with
# only 'secret/prod/reporting-db-readonly' access.

ความลับแบบไดนามิก

ความลับแบบไดนามิก จะถูกสร้างขึ้นเมื่อมีการร้องขอสำหรับผู้ร้องขอรายใดรายหนึ่ง และหมดอายุโดยอัตโนมัติ Vault สามารถสร้าง ข้อมูลรับรองฐานข้อมูลชั่วคราว ที่ใช้งานได้ 1 ชั่วโมงและผูกกับบริการเฉพาะที่ร้องขอ หลังหมดอายุ ฐานข้อมูลจะเพิกถอนข้อมูลรับรองดังกล่าวโดยอัตโนมัติ แนวทางนี้ทำให้ไม่มีข้อมูลรับรองแบบคงที่ที่มีอายุยาวนานให้ขโมย แม้ผู้โจมตีจะดักจับข้อมูลรับรองแบบไดนามิกได้ ข้อมูลรับรองนั้นก็จะหมดอายุอย่างรวดเร็วและผูกกับอัตลักษณ์ของผู้ร้องขอในบันทึกการตรวจสอบ

# Vault dynamic secrets: temporary DB credentials
# Application calls Vault to get a DB credential:
# vault read database/creds/web-app-role
#
# Vault response:
# username: v-web-app-x7k2m-1234567890  (unique, temporary)
# password: A1b2C3d4E5f6G7h8            (randomly generated)
# lease_duration: 1h                     (auto-expires)
#
# After 1 hour, Vault instructs DB to revoke this user.
# No static password ever exists for the attacker to steal.

ความลับในไปป์ไลน์ CI/CD

ไปป์ไลน์ CI/CD มักจำเป็นต้องใช้ความลับ เช่น ข้อมูลรับรองผู้ให้บริการคลาวด์สำหรับการนำไปใช้งาน โทเค็นรีจิสทรี Docker และคีย์สำหรับการลงลายมือชื่อ Never จัดเก็บความลับไว้ในสคริปต์หรือไฟล์การกำหนดค่าของไปป์ไลน์ แต่ให้ใช้ที่จัดเก็บความลับในตัวของแพลตฟอร์มไปป์ไลน์ (GitHub Actions Secrets, GitLab CI Variables, ที่จัดเก็บข้อมูลรับรองของ Jenkins) หรือดึงความลับจากคลังกลางขณะทำงานโดยใช้อัตลักษณ์ของเครื่อง ทำเครื่องหมายตัวแปรความลับให้ถูกปิดบังในบันทึก เพื่อป้องกันการเปิดเผยโดยไม่ตั้งใจในผลลัพธ์การสร้าง

# GitHub Actions: using secrets in pipeline
# secrets.yml in GitHub Settings -> Secrets (encrypted storage)
# Secret: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY

# In .github/workflows/deploy.yml:
# env:
#   AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
#   AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

# Best practice: use OIDC federation instead
# GitHub -> AWS trust relationship via OIDC token
# -> No static AWS keys needed at all

การตรวจสอบการเข้าถึงความลับ

ตัวจัดการความลับมี บันทึกการตรวจสอบที่ครอบคลุมเหตุการณ์การเข้าถึงความลับทุกครั้ง ได้แก่ อัตลักษณ์ใดเข้าถึงความลับใด จาก IP ใด เมื่อใด และการเข้าถึงสำเร็จหรือถูกปฏิเสธ บันทึกเหล่านี้มีความสำคัญอย่างยิ่งต่อการปฏิบัติตามข้อกำหนด (SOC 2, PCI-DSS) และการตอบสนองต่อเหตุการณ์ เมื่อสงสัยว่าข้อมูลรับรองถูกบุกรุก บันทึกการตรวจสอบจะแสดงว่าระบบใดเข้าถึงข้อมูลนั้นและเมื่อใด ทำให้ระบุระบบที่อาจได้รับผลกระทบและตัดสินใจควบคุมเหตุการณ์ได้อย่างรวดเร็ว

ฮุกก่อนการส่งเพื่อป้องกันความลับ

ฮุกก่อนการส่ง คือสคริปต์ที่ทำงานโดยอัตโนมัติก่อนที่การส่งแต่ละครั้งไปยัง git จะเสร็จสมบูรณ์ จึงสามารถตรวจจับความลับก่อนที่ความลับจะเข้าสู่ประวัติการควบคุมเวอร์ชัน เครื่องมืออย่าง detect-secrets (Yelp), GitLeaks และ git-secrets (AWS) ทำงานร่วมกับฮุกก่อนการส่งและสแกนไฟล์ที่จัดเตรียมไว้เพื่อหารูปแบบที่ตรงกับคีย์สำหรับเรียกใช้บริการ สตริงการเชื่อมต่อ คีย์ส่วนตัว และโทเค็น JWT หากตรวจพบความลับ การส่งจะถูกปฏิเสธและระบบจะแจ้งให้นักพัฒนานำข้อมูลรับรองออก เฟรมเวิร์กก่อนการส่ง ช่วยให้เพิ่มและแชร์การกำหนดค่าฮุกระหว่างทีมได้ง่าย

# Installing detect-secrets as pre-commit hook:
# 1. Install: pip install detect-secrets
# 2. Create baseline: detect-secrets scan > .secrets.baseline
# 3. Add to .pre-commit-config.yaml:
#    repos:
#      - repo: https://github.com/Yelp/detect-secrets
#        rev: v1.4.0
#        hooks:
#          - id: detect-secrets
#            args: ['--baseline', '.secrets.baseline']
# 4. Install hooks: pre-commit install

# Now every commit attempt is scanned:
# git commit -m 'add config'
# -> detect-secrets runs
# -> if AWS key pattern found: COMMIT BLOCKED
# -> developer must remove secret and use secrets manager

ตรวจสอบอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า ต้องกำจัดความลับที่ฝังตายอยู่ในซอร์สโค้ด และแทนที่ด้วยตัวจัดการความลับอย่าง Vault หรือ AWS Secrets Manager, การเปลี่ยนความลับโดยอัตโนมัติจะกำจัดข้อมูลรับรองที่มีอายุยาวนานซึ่งผู้โจมตีอาจนำไปใช้ในทางที่ผิดได้แม้หลังการบุกรุกครั้งแรก และ ความลับแบบไดนามิกกับนโยบายการเข้าถึงตามสิทธิ์น้อยที่สุด จะลดคุณค่าของความลับแต่ละรายการที่ถูกเปิดเผย ต่อไปเราจะเรียนรู้เรื่องความปลอดภัยของ dependencies และการวิเคราะห์องค์ประกอบซอฟต์แวร์

คำถามที่พบบ่อย

บทเรียน “การจัดการความลับอย่างปลอดภัยและตัวแปรสภาพแวดล้อม” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การจัดการความลับอย่างปลอดภัยและตัวแปรสภาพแวดล้อม” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Security+ Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การจัดการความลับอย่างปลอดภัยและตัวแปรสภาพแวดล้อม”

หลีกเลี่ยงการฝังความลับไว้ตายตัวในซอร์สโค้ด โดยใช้ตัวจัดการความลับ (Vault, AWS Secrets Manager) และแทรกค่าตัวแปรสภาพแวดล้อมขณะทำงาน คุณปฏิบัติ Security+ Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Security+ Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Security+ Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน

บทเรียน “การจัดการความลับอย่างปลอดภัยและตัวแปรสภาพแวดล้อม” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Security+ Academy นี้ได้ไหม

ได้ บทเรียน Security+ Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การตรวจสอบข้อมูลนำเข้าและการเข้ารหัสข้อมูลส่งออก
  2. การจัดการความลับอย่างปลอดภัยและตัวแปรสภาพแวดล้อม
  3. ความปลอดภัยของการพึ่งพาและการวิเคราะห์องค์ประกอบซอฟต์แวร์
  4. DevSecOps: ย้ายการรักษาความปลอดภัยไปไว้ตั้งแต่ต้นในไปป์ไลน์
← กลับไปที่ Security+ Academy