มีแนวทางปฏิบัติที่ปฏิบัติกันมาในโลกความปลอดภัยทางไซเบอร์นานแล้ว - "การเปลี่ยนแปลงหรือวิวัฒนาการอย่างต่อเนื่องเป็นวิธีเดียวที่จะทำให้แอปพลิเคชันปลอดภัยตลอดไป"
ในอดีต การตรวจสอบสิทธิ์ระหว่างคอมโพเนนต์ (inter-component authentication) เป็นปัญหาสำหรับแอปพลิเคชันมาก แอปต้องตรวจสอบตัวตนเองกับมิดเดิลแวร์และคอมโพเนนต์แบ็กเอนด์ต่างๆ ใน Cloud API เพื่อรับการเข้าถึง อย่างไรก็ตาม การตรวจสอบสิทธิ์แอปพลิเคชันใน Web API เป็นกระบวนการจำเป็น
กลไกการตรวจสอบที่มีอยู่คือ การล็อกอินแอปพลิเคชันแบบคงที่ (static application login) แต่มีปัญหาด้านความปลอดภัยกับวิธีนี้:
- ข้อมูลประจำตัวล็อกอิน (Login credentials) ถูกอัปเดตบ่อยครั้ง
- มันลดความสามารถของบริษัทในการตรวจสอบและบันทึกกิจกรรมของแอปพลิเคชัน
อ่านเพิ่มเติม: DevSecOps: จะช่วยรักษาความปลอดภัยแอปพลิเคชันและซอฟต์แวร์ของเราได้ไหม?
TLS Mutual Authentication
อย่างไรก็ตาม หนึ่งในวิธีที่ดีที่สุดในการช่วยความปลอดภัย Cloud API คือการนำ TLS (Transport Layer Security) mutual authentication มาใช้เมื่อคอมโพเนนต์หรือกระบวนการสื่อสารกัน
สมมติว่าคอมโพเนนต์ RESTful API ใช้เทคนิค TLS mutual authentication อยู่แล้ว มันขอให้แอปพลิเคชันนำเสนอใบรับรองไคลเอนต์ (client certificate) เพื่อตรวจสอบตัวตน ดังนั้น มันสามารถช่วยปรับปรุงกลยุทธ์โครงสร้างพื้นฐานความปลอดภัยแอปพลิเคชันได้
ปัญหากับกระบวนการดั้งเดิม
กิจกรรมในกระบวนการปกติถูกจัดกลุ่มรวมกันภายใต้ User ID เดียวตามคอมโพเนนต์แบ็กเอนด์ การจัดประเภทนี้ทำให้ยากที่จะค้นหาเหตุการณ์ผ่านข้อมูลเหตุการณ์ทั้งหมดที่เกี่ยวข้องกับแอปพลิเคชัน สถานการณ์แย่ลงเมื่อคุณไม่พบเหตุการณ์ระหว่างการโจมตีทางไซเบอร์ ผู้เชี่ยวชาญด้านความปลอดภัยไม่สามารถแยกแยะระหว่างแอปพลิเคชันที่เป็นธรรมดาและอันตรายได้ ปัญหาเฉพาะนี้เกิดขึ้นมามากกว่าทศวรรษและยังไม่ได้รับการแก้ไข
สำหรับ RESTful APIs พวกเขายังคงต้องตรวจสอบตัวตนกัน และพวกเขาแค่ใช้วิธี HTTP-aware เพื่อทำการตรวจสอบสิทธิ์ ตัวอย่างเช่น ค่า hidden ถูกรวมกับ HTTP request headers เพื่อตรวจสอบผู้ร้องขอ กระบวนการนี้เรียกว่า HTTP basic authentication มันถูกนำไปใช้โดยไม่สนใจว่าอยู่บนคลาวด์หรือ on-premises ไม่ว่าคุณจะใช้ PaaS หรือ IaaS การตรวจสอบสิทธิ์ระหว่างคอมโพเนนต์ยังคงเป็นปัญหาที่ยังไม่ได้แก้ไข
TLS ช่วยอย่างไร
พื้นฐานแล้ว คุณต้องนำคุณสมบัติของ TLS มาใช้ประโยชน์เพื่อเพิ่มประสิทธิภาพกลไกการตรวจสอบสิทธิ์ที่คุณนำไปใช้ ในกรณีที่ TLS ไม่ได้ถูกใช้สำหรับการเล่นเว็บ มันรองรับการตรวจสอบสิทธิ์ร่วมกัน (mutual validation) ระหว่างเพียร์ (peers) ที่ทำธุรกรรมกัน
เซิร์ฟเวอร์ตรวจสอบสิทธิ์ผู้ร้องขอเหมือนเบราว์เซอร์ตรวจสอบเว็บไซต์ระยะไกล โปรโตคอล HTTP ถูกใช้เป็นการขนส่งสำหรับ Cloud APIs แต่เรายังสามารถอนุญาตการตรวจสอบสิทธิ์ร่วมกันระหว่างคอมโพเนนต์ได้ ใน TLS mutual authentication เราสามารถจำกัดพารามิเตอร์ของใบรับรองที่ยอมรับได้โดยเฉพาะ หมายความว่าแอปพลิเคชันบนคลาวด์แค่ต้องนำเสนอใบรับรองเฉพาะ หรือหมายเลขซีเรียล และแม้แต่จาก Certificate Authority เฉพาะ นอกจากนี้ คุณสามารถรวมวิธี TLS กับค่า hidden แบบคงที่หรือรหัสผ่านได้ แม้การนำ TLS mutual authentication ไปใช้ในคลาวด์จะมีบาง dependencies โดยหลัก Cloud API ควรปรับแต่งได้เพื่อตั้งค่า TLS mutual authentication หมายความว่าคุณควรมีสภาพแวดล้อม IaaS เพื่อให้คุณสามารถปรับแต่งการกำหนดค่าได้ มิฉะนั้น ควรเป็นสภาพแวดล้อม PaaS ที่คุณได้รับอนุญาตให้เปิดใช้งานฟังก์ชันนี้ คุณสามารถนำตัวอย่างเช่นผู้เชี่ยวชาญคลาวด์อย่าง AWS และ Microsoft Azure มาใช้
ข้อดีของ TLS Mutual Authentication
มีประโยชน์บางอย่างที่น่าทึ่งที่คุณสามารถเพลิดเพลินได้ขณะใช้ TLS mutual authentication ข้อดีที่โดดเด่นที่สุดคือ ลดความกังวลเรื่องการดูแลรักษารหัสผ่านหรือค่า hidden การใช้และจัดการรหัสผ่านหรือค่า hidden แบบคงที่เป็นงานที่ยุ่งยาก เพราะรวมกระบวนการอย่าง การเปลี่ยนรหัสผ่านเป็นประจำ ตรวจสอบการใช้งาน สร้างรหัสผ่านที่ซับซ้อน รับรองการป้องกัน ฯลฯ อย่างไรก็ตาม TLS mutual authentication ลดความยุ่งยากเพิ่มเติมในการดูแลรักษารหัสผ่าน แม้รหัสผ่านจะถูกใช้ไม่กี่ครั้งขณะเปิดใช้งานวิธีการตรวจสอบสิทธิ์ TLS สามารถลดบทบาทของรหัสผ่านในระยะยาว
นอกจากนี้ TLS mutual authentication ใช้ใบรับรองและคีย์ส่วนตัว (private keys) ที่พกพาได้ยากกว่ารหัสผ่าน ดังนั้น แม้ใบรับรองและคีย์ส่วนตัวอาจถูกเจาะได้เหมือนเอนทิตีดิจิทัลอื่นๆ มันก็ยังเพิ่มระดับความยากให้แฮกเกอร์ อย่างน้อยในแง่ของโลจิสติกส์ ขณะที่แฮกเกอร์ต้องการปลอมตัวเป็นผู้เรียก API ระยะไกล
การเฝ้าระวังแอปพลิเคชัน TLS บันทึกคอมโพเนนต์หรือแอปพลิเคชันที่สร้างคำขอ API ด้วยความชัดเจนมากกว่า ด้วยรหัสผ่าน มันเป็นกระบวนการที่ซับซ้อน
อ่านเพิ่มเติม: ความปลอดภัยทางไซเบอร์กำลังดีขึ้นหรือแย่ลง?
ข้อเสียของ TLS Mutual Authentication
มีข้อเสียบางอย่างขณะที่คุณนำ TLS mutual authentication ไปใช้ อย่างไรก็ตาม ไม่มีข้อไหนควรทำให้คุณmutual authentication ไม่ควรทำให้คุณไม่ยินยอมที่จะนำเทคนิคนี้ไปใช้
ข้อเสียต่อไปนี้ควรพิจารณาเพื่อปรับปรุงวิธีการ: –
ข้อแรกและสำคัญที่สุด ใบรับรองหมดอายุ (certificates expire) ดังนั้น ควรจำเสมอว่าต้องออกใบรับรองใหม่ (reissue) ก่อนหมดอายุ ในกรณีที่คุณลืมออกใหม่ ผลลัพธ์อาจเป็นอันตราย เพราะมันยากที่จะ debug ปัญหา ให้แน่ใจว่าคุณติดตามวันหมดอายุของใบรับรองเสมอ เพื่อเปลี่ยนใบรับรองที่หมดอายุล่วงหน้า (proactively)
โดยรวม TLS mutual authentication เป็นวิธีที่สร้างสรรค์ในการปรับปรุงความปลอดภัยสำหรับ Cloud APIs อย่างน้อย TLS mutual authentication สามารถช่วยผู้เชี่ยวชาญด้านความปลอดภัยประเมินความปลอดภัยแอปพลิเคชันบนคลาวด์ได้
