Quantcast
Channel: cc :: somkiat
Viewing all articles
Browse latest Browse all 1997

DevSecOps ของมันต้องมี มันจึงมา

$
0
0

หลังจากที่ดู VDO จากงาน DevSecOps พบว่า มีหลาย ๆ เรื่องที่น่าสนใจ หนึ่งในนั้นคือ Effective DevSecOps ทำการอธิบายเรื่องของ Security ในบริบทของ Development และ Operation ไว้อย่างน่าสนใจ เลยนำมาสรุปไว้หน่อย

เรื่องของ Security นั้น

ไม่ควรแบ่งแยกให้ใครดูแลไปเลย หรือแบ่งเป็นทีมหรือแผนก ไม่ควรมีแต่เอกสาร มีแต่กฏและนโยบายออกมา เพื่อให้ทุก ๆ คนทำตาม ยกเว้นคนสร้างกฏ ไม่ควรมาเถียงกันว่าใครทำผิด ว่าใครไม่ทำตามกฏ แต่ทุกคนคือทีม หรือ cyber-security team ไม่รอที่จะมายิง มาเจาะหรือมา hack ระบบอย่างเดียว ดังนั้นเรื่องของ Security มันเป็นเรื่องของทุกคน ขึ้นอยู่กับว่า ใครรับผิดชอบในส่วนไหนบ้าง แต่โดยรวมต้องทำงานกันเป็นทีม ที่สำคัญเรื่องของ Security มันต้องเข้ามาเป็นส่วนหนึ่ง ในการ Development และ Operation ด้วยเสมอ
คำถามที่น่าสนใจจาก VDO เรามาสนใจเรื่อง security กันตอนไหน ตอนที่โดนโจมตีแล้วใช่ไหม ?
ดังนั้น Security all the time, everywhere by anyone นะครับ

มาดูกันว่า จะทำอย่างไรให้มันมีประสิทธิภาพมากขึ้น

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

ขั้นตอนที่ 1 กำหนดเป้าหมายให้ชัดเจน

ตัวอย่างเช่น
  • ข้อมูลที่เป็นความลับต้องไม่รั่วไหลออกไป เช่น password, certificate หรือ private key เป็นต้น
  • พวก certificate ต่าง ๆ ต้องไม่หมดอายุ
  • พวก library ต่าง ๆ ต้องไม่ล้าสมัย
  • พวก source code ต้องไม่มีช่องโหว่ให้โจมตี
  • ต้อง compliance ไปกับ OWASP TOP 10 เสมอ

ขั้นตอนที่ 2 สร้างกรอบและขั้นตอนการทำงาน

เป็นส่วนที่ยากมาก ๆ ซึ่งต้องทำการสร้างแบบแผนการทำงานทั้งฝั่ง Development และ Operation ทำอย่างไรให้ทั้งสองฝ่ายรู้และเข้าใจเกี่ยวกับเรื่องของ Security ยกตัวอย่างเช่น เรื่องของความลับต้องไม่รั่วไหล ต้องทำการสรุปกฏและนโยบายออกมาที่จับต้องได้ เช่น
  • ต้องไม่เก็บไว้ใน repository
  • ต้องไม่อยู่ในรูปแบบของ plain text
ต้องสรุปการบังคับใช้งานให้ชัดเจน เช่น
  • ทำการ scan repository อยู่เสมอ
  • ทุก ๆ ข้อมูลที่เป็นความลับต้องมีเครื่องมือจัดการเสมอ
ยังไม่พอ ต้องสรุปเครื่องมือที่จะใช้งานแบบชัดเจนไปเลยอีกด้วย เช่น จากนั้นทำการสร้าง process หรือ pipeline ของการทำงาน ว่า Security จะเข้ามาอยู่ในตรงไหนอย่างไร เช่น
  • Code
  • Build
  • Test
  • Deploy
  • Operate

ขั้นตอนที่ 3 ประกาศหรือแจ้งออกไป ให้รับทราบทั้งองค์กร

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

ขั้นตอนที่ 4 การบังคับให้ใช้งานตามกฏและนโยบาย

ซึ่งต้องบอกด้วยว่าต้องทำอย่างไรบ้าง ต้องจับต้องได้ มีทั้งงานที่ต้องทำเอง และงานที่ต้องใช้เครื่องมือมาช่วย

ขั้นตอนที่ 5 ต้องมีการวัดผลอยู่เสมอ

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

ถ้าทำได้ประมาณนี้ น่าจะทำให้ Security เข้ามาอยู่ในทุก ๆ ส่วนของการทำงาน

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

Viewing all articles
Browse latest Browse all 1997

Trending Articles