Cyber Security Academy · บทเรียน

ปัญหาข้อมูลลับกระจัดกระจาย

เหตุใดข้อมูลลับที่ฝังไว้ในโค้ดจึงเป็นอันตราย

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

การแพร่กระจายของข้อมูลลับคืออะไร

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

การแพร่กระจายเกิดขึ้นเมื่อข้อมูลลับเหล่านี้ไปกระจัดกระจายอยู่ในสถานที่ที่ไม่ควรเก็บไว้:

โค้ดต้นฉบับและไฟล์การกำหนดค่า
กระบวนการ CI/CD และตัวแปรสภาพแวดล้อม
อิมเมจคอนเทนเนอร์และโครงสร้างพื้นฐานในรูปโค้ด
ข้อความสนทนา วิกิ และระบบจัดการใบงาน

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

secret ที่เขียนฝังไว้ในโค้ด

สาเหตุรากฐานที่พบบ่อยที่สุดคือ secret ที่เขียนฝังไว้ในโค้ด ซึ่งเป็นข้อมูลรับรองที่เขียนไว้โดยตรงในซอร์สโค้ด วิธีนี้อาจสะดวกในช่วงพัฒนา แต่จะกลายเป็นภาระความเสี่ยงถาวร

นี่คือตัวอย่างลักษณะของรหัสผ่านฐานข้อมูลที่เขียนฝังไว้ในโค้ดแอปพลิเคชัน:

ขณะนี้ทุกคนที่มีสิทธิ์อ่านไฟล์นี้จะเห็นรหัสผ่านของระบบใช้งานจริง ซึ่งรวมถึงนักพัฒนาทุกคน ระบบผสานรวมโค้ดอัตโนมัติทุกตัว และใครก็ตามที่โคลนคลังโค้ดนี้ในภายหลัง

# config.py  (ANTI-PATTERN - do not do this)
DB_HOST = "prod-db.internal"
DB_USER = "app_service"
DB_PASSWORD = "S3cr3t!Pr0d_2024"   # hardcoded - dangerous
API_KEY  = "sk_live_4eC39HqLyjWDarjtT1zdp7dc"

เหตุใดประวัติ Git จึงไม่เคยลืม

อันตรายสำคัญของข้อมูลลับที่เขียนฝังไว้ในโค้ดคือ ประวัติการควบคุมเวอร์ชัน แม้คุณจะลบ secret ในการบันทึกการเปลี่ยนแปลงครั้งถัดไป แต่ secret นั้นก็ยังคงอยู่ถาวรในประวัติ Git ของสำเนาทุกชุด

คุณสามารถกู้คืน secret ที่รั่วไหลจากประวัติได้ทุกเมื่อ:

ด้วยเหตุนี้ การลบ secret จากการบันทึกการเปลี่ยนแปลงล่าสุดจึงไม่ถือว่าแก้ไขการรั่วไหล ต้องถือว่า secret ถูกเปิดเผยแล้วและต้องหมุนเวียนทันที

# A secret deleted in HEAD is still in history
git log -p --all -S 'S3cr3t!Pr0d_2024'

# Searching all branches and tags reveals it
git grep 'API_KEY' $(git rev-list --all)

หายนะจากคลังโค้ดสาธารณะ

เมื่อคลังโค้ดที่มีข้อมูลลับเขียนฝังไว้ถูกส่งขึ้นโฮสต์ สาธารณะ เช่น GitHub บอตอัตโนมัติจะกวาดเก็บข้อมูลภายในเวลาไม่กี่วินาทีถึงไม่กี่นาที

ผลที่เกิดขึ้นจริงอาจรวมถึง:

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

ผู้ให้บริการคลาวด์และ GitHub มี การสแกน secret ที่ตรวจจับและบางครั้งเพิกถอนคีย์ที่รั่วไหลโดยอัตโนมัติแล้ว แต่คุณไม่ควรพึ่งพาสิ่งนี้เป็นตาข่ายนิรภัย

ข้อมูลลับในอิมเมจคอนเทนเนอร์

คอนเทนเนอร์ทำให้เกิดช่องทางการกระจายตัวที่แยบยล ข้อมูลลับที่ฝังลงในอิมเมจระหว่างการสร้างจะถูกเก็บไว้ใน ชั้นของอิมเมจ และถูกส่งไปยังรีจิสทรีและโฮสต์ทุกแห่งที่ดึงอิมเมจนั้น

ข้อผิดพลาดที่พบบ่อยคือคัดลอกไฟล์ secret เข้าไป แล้วลบออกในชั้นถัดไป แต่ secret นั้นยังคงอยู่ในชั้นก่อนหน้า:

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

# Dockerfile ANTI-PATTERN
COPY id_rsa /root/.ssh/id_rsa
RUN git clone git@github.com:org/private.git
RUN rm /root/.ssh/id_rsa   # too late - still in earlier layer

# Inspect layers to recover the deleted secret
docker history --no-trunc myimage:latest
docker save myimage:latest | tar -xf -

ตัวแปรสภาพแวดล้อมไม่ใช่ห้องนิรภัย

การย้ายข้อมูลลับออกจากโค้ดไปไว้ใน ตัวแปรสภาพแวดล้อม ถือเป็นการปรับปรุง แต่ยังไม่ใช่ทางแก้ที่สมบูรณ์ ตัวแปรสภาพแวดล้อมช่วยแก้ปัญหาการเขียนฝังไว้ในโค้ด แต่ก็เปิดช่องทางการเปิดเผยใหม่:

รั่วไหลในดัมป์จากการหยุดทำงานและร่องรอยสแต็กของข้อผิดพลาด
กระบวนการอื่นมองเห็นได้ผ่าน /proc/<pid>/environ บน Linux
เครื่องมือแก้จุดบกพร่องบันทึกไว้โดยพิมพ์สภาพแวดล้อมทั้งหมด
ถูกเก็บเป็นข้อความธรรมดาในไฟล์ .env ซึ่งอาจถูกบันทึกเข้าคลังโค้ดโดยไม่ตั้งใจ

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

ปัญหาขอบเขตความเสียหาย

การกระจายตัวทำให้ การรับมือเหตุการณ์ แทบเป็นไปไม่ได้ เมื่อ secret อยู่ทุกหนแห่ง จะมีคำถามสองข้อที่ตอบไม่ได้:

มันอยู่ที่ไหน? คุณไม่สามารถหมุนเวียนสิ่งที่หาไม่พบได้
ใครเป็นผู้ใช้มัน? หากไม่มีบันทึกการเข้าถึงแบบรวมศูนย์ คุณก็ไม่สามารถประเมินขอบเขตการรั่วไหลได้

ขอบเขตความเสียหายจากข้อมูลรับรองที่รั่วไหลเพียงรายการเดียวจะเพิ่มขึ้นตามการกระจายตัว รหัสผ่านร่วมที่นำกลับมาใช้กับบริการสิบรายการหมายความว่าการรั่วไหลครั้งเดียวทำให้ทั้งสิบรายการถูกเจาะได้ การรวมศูนย์และการใช้ข้อมูลลับที่มีอายุสั้นและไม่ซ้ำกันช่วยลดขอบเขตนี้ได้อย่างมาก

ตรวจจับ secret ก่อนบันทึกการเปลี่ยนแปลง

จุดที่ประหยัดค่าใช้จ่ายที่สุดในการหยุดการรั่วไหลคือ ก่อนที่ข้อมูลจะเข้าสู่ระบบควบคุมเวอร์ชัน เครื่องมือสแกน secret ก่อนบันทึกการเปลี่ยนแปลงจะตรวจสอบการเปลี่ยนแปลงที่เตรียมไว้และบล็อกการบันทึกที่มีรูปแบบข้อมูลรับรอง

เครื่องมือโอเพนซอร์สยอดนิยม ได้แก่ gitleaks, trufflehog และ detect-secrets ฮุกก่อนบันทึกการเปลี่ยนแปลงโดยทั่วไปจะทำงานบนเครื่องของผู้ใช้:

ให้ใช้วิธีนี้ร่วมกับการสแกนฝั่งเซิร์ฟเวอร์ในระบบผสานรวมโค้ดอย่างต่อเนื่อง เพื่อให้ยังตรวจพบกรณีที่นักพัฒนาข้ามฮุกภายในเครื่อง

# Scan a repo for secrets with gitleaks
gitleaks detect --source . --verbose

# Scan only staged changes (pre-commit)
gitleaks protect --staged --redact

# Deep-scan full history including dangling commits
trufflehog git file://. --only-verified

การแก้ไขเมื่อ secret รั่วไหล

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

1. หมุนเวียน เพิกถอน secret ที่รั่วไหลและออก secret ใหม่ทันที
2. ตรวจสอบ ทบทวนบันทึกการเข้าถึงเพื่อค้นหาการใช้งานที่ไม่ได้รับอนุญาตในช่วงเวลาที่ข้อมูลถูกเปิดเผย
3. ล้าง ลบ secret ออกจากประวัติ (เช่น git filter-repo) และบังคับส่งการเปลี่ยนแปลงขึ้นคลัง
4. ป้องกัน เพิ่มการสแกนและย้าย secret ไปไว้ในระบบจัดการ เพื่อไม่ให้เกิดซ้ำ

อย่าข้ามขั้นตอนที่ 1 เด็ดขาด secret ที่เคยปรากฏบนพื้นที่สาธารณะถือว่าถูกเปิดเผยแล้ว จบประเด็น

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

การกระจายตัวจะยิ่งรุนแรงขึ้นเมื่อข้อมูลลับ ได้รับสิทธิ์มากเกินไป และ ถูกแบ่งปันกว้างเกินไป การใช้หลักสิทธิ์น้อยที่สุดช่วยจำกัดความเสียหายเมื่อเกิดการรั่วไหล:

ให้ข้อมูลรับรองแต่ละบริการมี ของตัวเอง และอย่าใช้ข้อมูลรับรองร่วมกัน
จำกัดขอบเขตของ secret แต่ละรายการให้มีเพียงสิทธิ์ขั้นต่ำที่จำเป็น (อ่านอย่างเดียวเทียบกับผู้ดูแลระบบ)
เลือกใช้ข้อมูลรับรอง อายุสั้น ที่หมดอายุโดยอัตโนมัติ
แยกข้อมูลลับตามสภาพแวดล้อม คีย์สำหรับการพัฒนาต้องไม่มีสิทธิ์เข้าถึงระบบใช้งานจริง

แนวปฏิบัติเหล่านี้เปลี่ยนเหตุการณ์รั่วไหลครั้งใหญ่ให้เป็นเหตุการณ์ที่จำกัดขอบเขตและกู้คืนได้

การสร้างวัฒนธรรมการดูแล secret

เครื่องมืออย่างเดียวแก้ปัญหาการกระจายตัวไม่ได้ วัฒนธรรมต่างหากที่ช่วยแก้ปัญหา องค์กรที่มีวุฒิภาวะจะมองว่าการจัดการข้อมูลลับเป็นวินัยที่ต้องทำอย่างต่อเนื่อง:

จุดยืนเริ่มต้น: ไม่ให้มี secret อยู่ในซอร์สโค้ดเด็ดขาด
จัดเก็บแบบรวมศูนย์ในห้องนิรภัยที่มีการจัดการ พร้อมการควบคุมสิทธิ์และบันทึกการตรวจสอบ
ทำการสแกนอัตโนมัติในทุกขั้นตอน: ก่อนบันทึกการเปลี่ยนแปลง ระบบผสานรวมโค้ดอย่างต่อเนื่อง และรีจิสทรี
ทำให้การหมุนเวียนเป็นกิจวัตร ไม่ใช่สิ่งที่ทำเฉพาะเมื่อเกิดเหตุฉุกเฉิน
ฝึกอบรมวิศวกรทุกคนให้รู้จักและรายงานการเปิดเผยข้อมูลโดยไม่กล่าวโทษกัน

เป้าหมายคือระบบที่ทำให้การทำ secret รั่วไหลเป็นเรื่องยาก และทำให้การกู้คืนเป็นเรื่องง่าย

แบบทดสอบสั้น ๆ

ทดสอบความเข้าใจของคุณว่าทำไมการลบ secret ที่รั่วไหลจึงยังไม่เพียงพอ

สรุปทบทวน: ปัญหาข้อมูลลับกระจัดกระจาย

คุณได้เรียนรู้แล้วว่าทำไมข้อมูลลับที่กระจัดกระจายและเขียนฝังไว้ในโค้ดจึงเป็นจุดอ่อนด้านความปลอดภัยที่พบบ่อยและสร้างความเสียหายมากที่สุดอย่างหนึ่ง

ข้อมูลลับกระจัดกระจาย หมายถึงการแพร่กระจายของข้อมูลรับรองไปทั่วโค้ด กระบวนการทำงานต่อเนื่อง อิมเมจ และการสนทนาโดยไม่มีการควบคุม
ข้อมูลลับที่เขียนฝังไว้ในโค้ด จะคงอยู่ตลอดไปในประวัติ Git การลบออกไม่ได้แก้ไขการรั่วไหล
คลังโค้ดสาธารณะจะถูกกวาดเก็บภายในไม่กี่นาที นำไปสู่ค่าใช้คลาวด์พุ่งกระฉูดและการรั่วไหล
ตัวแปรสภาพแวดล้อมและชั้นของอิมเมจเป็นช่องทางรั่วไหล ไม่ใช่พื้นที่จัดเก็บที่ปลอดภัย
การกระจายตัวทำให้ ขอบเขตความเสียหายเพิ่มขึ้น และทำให้การหมุนเวียนกับการรับมือเหตุการณ์เป็นไปไม่ได้
วิธีแก้ไข: สแกนก่อนบันทึกการเปลี่ยนแปลง หมุนเวียนก่อนเมื่อเกิดการรั่วไหล จัดเก็บแบบรวมศูนย์ในห้องนิรภัย และใช้หลักสิทธิ์น้อยที่สุด

ต่อไป เราจะรวมศูนย์ข้อมูลลับอย่างถูกต้องโดยใช้ห้องนิรภัยและแหล่งเก็บ secret

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

บทเรียน “ปัญหาข้อมูลลับกระจัดกระจาย” ฟรีหรือไม่

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

คุณจะเรียนรู้อะไรในบทเรียน “ปัญหาข้อมูลลับกระจัดกระจาย”

เหตุใดข้อมูลลับที่ฝังไว้ในโค้ดจึงเป็นอันตราย คุณปฏิบัติ Cyber Security Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

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

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

บทเรียน “ปัญหาข้อมูลลับกระจัดกระจาย” ใช้เวลานานแค่ไหน

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

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

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

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

← กลับไปที่ Cyber Security Academy