The Five Functions of Cybersecurity (ห้าฟังก์ชันหลักของ Cybersecurity)

เมื่อ เรามีหลักการพื้นฐานเหล่านั้นอยู่ในใจแล้ว ลองมาพิจารณากิจกรรมที่เกี่ยวข้องกับ security ในวงกว้างที่เราต้องทำกันดูบ้าง จากนั้นเราจะไปทำความเข้าใจว่ากิจกรรมเหล่านี้เปลี่ยนแปลงไปอย่างไรในบริบทของสถาปัตยกรรม microservice โมเดลที่ผมชอบใช้อธิบายภาพรวมของ application security มาจาก US National Institute of Standards and Technology (NIST) ซึ่งได้วางกรอบ โมเดลห้าส่วนที่มีประโยชน์ สำหรับกิจกรรมต่างๆ ที่เกี่ยวข้องกับ cybersecurity:

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

• Protect ปกป้องทรัพย์สินสำคัญของคุณจากผู้ไม่หวังดี

• Detect ตรวจจับว่ามีการโจมตีเกิดขึ้นหรือไม่ แม้ว่าคุณจะพยายามอย่างเต็มที่แล้วก็ตาม

• Respond ตอบสนองเมื่อคุณพบว่ามีบางอย่างเลวร้ายเกิดขึ้น

• Recover กู้คืนระบบหลังเกิดเหตุการณ์

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

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

Identify (ระบุตัวตน)

ก่อนที่เราจะสามารถระบุได้ว่าเราควรปกป้องอะไร เราต้องรู้ก่อนว่าใครกำลังตามล่าสิ่งของของเรา และพวกเขากำลังมองหาอะไรกันแน่ มันมักจะยากที่จะทำให้ตัวเราเองคิดแบบผู้โจมตี แต่นั่นคือสิ่งที่เราต้องทำจริงๆ เพื่อให้แน่ใจว่าเรามุ่งความพยายามไปในจุดที่ถูกต้อง Threat modeling คือสิ่งแรกที่คุณควรพิจารณาเมื่อจัดการกับด้านนี้ของ application security

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

เวลาที่ผมคุยกับนักพัฒนาเกี่ยวกับความเสี่ยงด้าน security ในบริบทของสถาปัตยกรรม microservice พวกเขามักจะเริ่มพูดถึง JWT และ mutual TLS ทันที พวกเขามองหาทางออกเชิงเทคนิคสำหรับปัญหาเชิงเทคนิคที่พวกเขาเห็นได้ชัดเจน ผมไม่ได้หมายความว่าจะโทษแค่นักพัฒนาเท่านั้น—พวกเราทุกคนต่างก็มีมุมมองที่จำกัดต่อโลก ย้อนกลับไปที่การเปรียบเทียบก่อนหน้านี้ นี่คือวิธีที่เราลงเอยด้วยประตูหน้าที่ปลอดภัยสุดๆ แต่ประตูหลังกลับเปิดโล่ง

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

เงาของการสอดแนมในองค์กรได้ปลุกกระแสความไม่พอใจในบริษัทเกี่ยวกับความกังวลแบบ “big brother” ขึ้นมา ขึ้นอยู่กับว่าคุณอยู่ฝั่งไหนของข้อถกเถียงนี้ เรื่องนี้อาจเป็นเรื่องของการสอดแนมพนักงาน (ถ้าคุณอยู่ฝั่ง “สนับสนุน” กล้อง) หรือเป็นเรื่องของการยอมให้ผู้บุกรุกเข้าถึงอาคารได้ (ถ้าคุณอยู่ฝั่ง “คัดค้าน” กล้อง) หากไม่พูดถึงปัญหาของการถกเถียงที่แบ่งขั้วแบบนี้ 4 พนักงานคนหนึ่งได้ออกมาพูดอย่างค่อนข้างเขินอายว่า บางทีการถกเถียงนี้อาจจะพลาดประเด็นไปนิดหน่อย เพราะเรากำลังมองข้ามปัญหาที่ใหญ่กว่า—นั่นคือ ดูเหมือนไม่มีใครสนใจว่าประตูหน้าของสำนักงานหลักแห่งหนึ่งมีตัวล็อกที่เสีย และตลอดหลายปีที่ผ่านมา ผู้คนก็มาถึงในตอนเช้าแล้วพบว่าประตูไม่ได้ล็อกอยู่

เรื่องราวสุดโต่ง (แต่เป็นเรื่องจริง) นี้เป็นตัวอย่างที่ดีของปัญหาทั่วไปที่เราเจอเมื่อพยายามรักษาความปลอดภัยระบบของเรา หากไม่มีเวลาพิจารณาปัจจัยทั้งหมดและทำความเข้าใจว่าความเสี่ยงที่ใหญ่ที่สุดของคุณอยู่ตรงไหนจริงๆ คุณอาจลงเอยด้วยการมองข้ามจุดที่ควรใช้เวลาให้คุ้มค่าที่สุดไป เป้าหมายของ threat modeling คือการช่วยให้คุณเข้าใจว่าผู้โจมตีต้องการอะไรจากระบบของคุณ พวกเขาตามล่าอะไรกันแน่? ผู้ไม่หวังดีประเภทต่างๆ จะต้องการเข้าถึงทรัพย์สินที่แตกต่างกันหรือไม่? Threat modeling เมื่อทำอย่างถูกต้อง ส่วนใหญ่แล้วคือการทำให้ตัวเองสวมบทบาทเป็นผู้โจมตี คิดจากมุมมองภายนอกเข้ามาข้างใน มุมมองจากคนนอกนี้สำคัญมาก และเป็นเหตุผลหนึ่งว่าทำไมการให้ฝ่ายภายนอกช่วยขับเคลื่อนกิจกรรม threat modeling จึงมีประโยชน์อย่างมาก

แนวคิดหลักของ threat modeling ไม่ได้เปลี่ยนไปมากนักเมื่อเรามองสถาปัตยกรรม microservice ยกเว้นในแง่ที่ว่าสถาปัตยกรรมที่กำลังถูกวิเคราะห์อาจซับซ้อนขึ้น สิ่งที่เปลี่ยนไปคือวิธีที่เรานำผลลัพธ์จาก threat model ไปปฏิบัติจริง หนึ่งในผลลัพธ์ของกิจกรรม threat modeling คือรายการคำแนะนำว่าควรมี security control อะไรบ้างที่ต้องนำมาใช้—control เหล่านี้อาจรวมถึงการเปลี่ยนแปลงกระบวนการทำงาน การเปลี่ยนเทคโนโลยี หรือการปรับเปลี่ยนสถาปัตยกรรมของระบบ การเปลี่ยนแปลงบางอย่างอาจเป็นแบบ cross-cutting และอาจส่งผลกระทบต่อหลายทีมและ microservice ที่เกี่ยวข้อง ในขณะที่บางอย่างอาจส่งผลให้เกิดงานที่เจาะจงมากขึ้น แต่โดยพื้นฐานแล้ว เมื่อทำ threat modeling คุณจำเป็นต้องมองแบบองค์รวม การจำกัดการวิเคราะห์นี้ไว้เฉพาะส่วนเล็กๆ ของระบบของคุณมากเกินไป เช่น microservice หนึ่งหรือสองตัว อาจทำให้เกิดความรู้สึกปลอดภัยที่ผิดพลาด คุณอาจลงเอยด้วยการใช้เวลาสร้างประตูหน้าที่ปลอดภัยสุดยอดเยี่ยม แต่กลับปล่อยหน้าต่างเปิดทิ้งไว้

สำหรับใครที่อยากศึกษาหัวข้อนี้ให้ลึกขึ้น ผมขอแนะนำหนังสือ Threat Modeling: Designing for Security 5 โดย Adam Shostack

Protect (ปกป้อง)

เมื่อเราระบุทรัพย์สินที่มีค่าที่สุด—และเปราะบางที่สุด—ของเราได้แล้ว เราต้องมั่นใจว่าทรัพย์สินเหล่านั้นได้รับการปกป้องอย่างเหมาะสม อย่างที่ผมได้กล่าวไปแล้ว สถาปัตยกรรม microservice ให้พื้นที่ผิวสำหรับการโจมตีที่กว้างขึ้นมากอย่างปฏิเสธไม่ได้ และเราจึงมีสิ่งต่างๆ ที่อาจต้องการการปกป้องมากขึ้น แต่ในขณะเดียวกันก็ให้ทางเลือกในการทำ defense in depth มากขึ้นด้วย เราจะใช้เวลาส่วนใหญ่ของบทนี้โฟกัสกับแง่มุมต่างๆ ของการปกป้อง เป็นหลักเพราะนี่คือพื้นที่ที่สถาปัตยกรรม microservice สร้างความท้าทายมากที่สุด

Detect (ตรวจจับ)

ในสถาปัตยกรรม microservice การตรวจจับเหตุการณ์ไม่พึงประสงค์อาจซับซ้อนขึ้น เรามีเครือข่ายให้ต้องเฝ้าติดตามมากขึ้น และมีเครื่องจักรให้ต้องคอยจับตามองมากขึ้น แหล่งข้อมูลต่างๆ เพิ่มขึ้นอย่างมาก ซึ่งอาจทำให้การตรวจจับปัญหายากขึ้นไปอีก เทคนิคหลายอย่างที่เราสำรวจไว้ใน Chapter 10 เช่น log aggregation สามารถช่วยเรารวบรวมข้อมูลที่จะช่วยให้เราตรวจจับได้ว่าอาจมีบางอย่างเลวร้ายเกิดขึ้น นอกจากนั้นยังมีเครื่องมือพิเศษ เช่น intrusion detection system ที่คุณอาจรันเพื่อจับพฤติกรรมที่ไม่ดี ซอฟต์แวร์สำหรับจัดการกับความซับซ้อนที่เพิ่มขึ้นของระบบเรากำลังพัฒนาขึ้นเรื่อยๆ โดยเฉพาะในพื้นที่ของ container workload ด้วยเครื่องมืออย่าง Aqua .

Respond (ตอบสนอง)

ถ้าสิ่งที่แย่ที่สุดเกิดขึ้นแล้วและคุณรู้เรื่องแล้ว คุณควรทำอะไรต่อ? การวางแผนตอบสนองเหตุการณ์ (incident response) ที่มีประสิทธิภาพเป็นสิ่งสำคัญมากในการจำกัดความเสียหายที่เกิดจากการถูกโจมตี โดยทั่วไปจะเริ่มจากการทำความเข้าใจขอบเขตของการโจมตีและข้อมูลที่ถูกเปิดเผยออกไป หากข้อมูลที่ถูกเปิดเผยรวมถึง personally identifiable information (PII) คุณจำเป็นต้องปฏิบัติตามทั้งกระบวนการตอบสนองและแจ้งเตือนด้าน security และ privacy ซึ่งอาจหมายความว่าคุณต้องพูดคุยกับหลายส่วนงานในองค์กรของคุณ และในบางสถานการณ์คุณอาจมีข้อผูกพันทางกฎหมายที่ต้องแจ้ง data protection officer ที่ได้รับการแต่งตั้งเมื่อเกิดการละเมิดข้อมูลประเภทที่กำหนด

หลายองค์กรได้ทำให้ผลกระทบจากการถูกโจมตีรุนแรงขึ้นด้วยการจัดการที่ผิดพลาดในช่วงหลังเกิดเหตุ ซึ่งมักนำไปสู่บทลงโทษทางการเงินที่เพิ่มขึ้น นอกเหนือจากความเสียหายต่อแบรนด์และความสัมพันธ์กับลูกค้า ดังนั้นจึงสำคัญมากที่จะต้องเข้าใจไม่แค่สิ่งที่คุณต้องทำเพราะเหตุผลทางกฎหมายหรือ compliance แต่ยังรวมถึงสิ่งที่คุณควรทำเพื่อดูแลผู้ใช้งานซอฟต์แวร์ของคุณด้วย ยกตัวอย่างเช่น GDPR กำหนดให้ต้องรายงานการละเมิดข้อมูลส่วนบุคคลต่อหน่วยงานที่เกี่ยวข้องภายใน 72 ชั่วโมง—ซึ่งเป็นกรอบเวลาที่ดูไม่หนักหนาเกินไป แต่นั่นไม่ได้แปลว่าคุณไม่ควรพยายามแจ้งให้ผู้คนทราบเร็วกว่านั้นหากข้อมูลของพวกเขาถูกละเมิด

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

Recover (กู้คืน)

Recovery หมายถึงความสามารถของเราในการทำให้ระบบกลับมาทำงานได้อีกครั้งหลังเกิดการโจมตี และยังรวมถึงความสามารถของเราในการนำสิ่งที่เราได้เรียนรู้ไปปรับใช้ เพื่อให้แน่ใจว่าปัญหามีโอกาสเกิดขึ้นซ้ำน้อยลง ในสถาปัตยกรรม microservice เรามีชิ้นส่วนที่เคลื่อนไหวได้มากขึ้นมากมาย ซึ่งอาจทำให้การกู้คืนซับซ้อนขึ้นหากปัญหามีผลกระทบเป็นวงกว้าง ดังนั้นต่อไปในบทนี้เราจะดูว่าสิ่งง่ายๆ อย่าง automation และ backup สามารถช่วยให้คุณ rebuild ระบบ microservice และทำให้ระบบกลับมาทำงานได้เร็วที่สุดเท่าที่จะเป็นไปได้ได้อย่างไร