Khóa luận tốt nghiệp An toàn thông tin: Nghiên cứu và triển khai mô hình đảm bảo an toàn thông tin trong quy trình phát triển và vận hành phần mềm (DevSecOps)

DANH MỤC TỪ VIET TATSTT [ Ký hiệu Nguyên nghĩa Tiếng Anh Nguyên nghĩa Tiếng Việt 1 API Application Programming Interface Continuous Integration Giao diện lập trình ứng dung Tích hợp liên

ĐẠI HỌC QUOC GIA TP HO CHÍ MINH

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

KHOA MẠNG MAY TÍNH VÀ TRUYEN THONG

TRAN GIA BAO

TRUONG THAO VY

KHOA LUAN TOT NGHIEP

NGHIEN CUU VA TRIEN KHAI MO HINH DAM BAO

AN TOAN THONG TIN TRONG QUY TRINH PHAT TRIEN VA VAN HANH PHAN MEM

(DEVSECOPS)

RESEARCHING AND IMPLEMENTING THE MODEL OF

INFORMATION SECURITY IN SOFTWARE DEVELOPMENT

AND OPERATIONS LIFE CYCLE (DEVSECOPS)

KY SU NGANH AN TOAN THONG TIN

ĐẠI HỌC QUỐC GIA TP HÒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN KHOA MẠNG MAY TÍNH VÀ TRUYEN THONG

TRAN GIA BẢO - 17520276 TRUONG THẢO VY - 17521281

KHOA LUAN TOT NGHIEP

NGHIEN CUU VA TRIEN KHAI MO HINH DAM BAO

AN TOAN THONG TIN TRONG QUY TRINH PHAT TRIEN VA VAN HANH PHAN MEM

(DEVSECOPS)

RESEARCHING AND IMPLEMENTING THE MODEL OF

INFORMATION SECURITY IN SOFTWARE DEVELOPMENT

AND OPERATIONS LIFE CYCLE (DEVSECOPS)

KY SU NGANH AN TOAN THONG TIN

GIANG VIEN HUONG DAN

THS DANG LÊ BẢO CHUONG - THS BÙI THANH BÌNH

THÔNG TIN HỘI ĐÒNG CHÁM KHÓA LUẬN TÓT NGHIỆP

Hội đồng chấm khóa luận tốt nghiệp, thành lập theo Quyết định số

463/QD-ĐHCNTT ngày 23 tháng 7 năm 2021 của Hiệu trưởng Trường Đại học Công nghệ Thông tin.

1 TS Nguyén Gia Tuấn Anh Chủ tịch

2 _ Th§ Đỗ Thị Thu Hiền Ủy viên

3 ThS Trần Tuấn Dũng Thư ký

LỜI CẢM ƠN

—z2#+%———

Nhóm tác giả xin bày tỏ lòng biết ơn chân thành, sâu sắc đến ThS Đặng Lê Bảo Chương và ThS Bùi Thanh Bình - Giảng viên Khoa Mạng máy tính và Truyền thông Trường Đại học Công nghệ Thông tin đã định hướng đề tài, động viên, giúp đỡ nhóm tác giả bằng tất cả sự tận tâm và nhiệt huyết trong suốt thời gian nghiên cứu, hoàn thành đề tài này.

Nhóm tác giả xin chân thành cảm ơn quý Thầy Cô Trường Đại học Công nghệ

Thông tin đã tạo mọi điều kiện giúp đỡ nhóm tác giả trong quá trình học tập, nghiên cứu, thực nghiệm và hoàn thành đề tài.

Cuối cùng, nhóm tác giả xin bày tỏ lòng biết ơn đối với gia đình và bạn bè đã luôn giúp đỡ, động viên nhóm tác giả hoàn thành đề tài.

Do những điều kiện chủ quan và khách quan chắc chắn khóa luận không thê tránh khỏi những thiếu sót, nhóm tác giả rất mong nhận được những ý kiến đóng góp của Thầy Cô và các bạn.

Tran trọng cam ơn.

TP Hồ Chi Minh, ngày tháng nim

Nhóm tác giả

MỤC LỤC

CHƯƠNG 1 MỞ ĐẦU 5-5 55s +£+eExSEEExerkevveEtersersersersesrssree 2 1.1 Lý do chọn đề tài 55c 525212 22122122121121121121121212121 xe 2

1.2 Mục tiêu nghiên CỨU ce E2 E 1E 91 211 1v ng ren 2

1.3 Đối tượng nghiên cứu

1.4 Phạm vi nghiên CỨU + + 2+2 E221 231 211 1 1 1 vn 3 1.5 Những đóng góp của khóa luận - .- ¿+ ¿5+5 2+2 *+teersieereex 3

1.5.1 Tính mới của đề tài :2c: 2c 2x22 EEEEErrtrrrrirrrrier 3 1.5.2 Khả năng ứng dụng thực tế của đề tài -s¿©cc+ccccccxrreecee 4 1.6 Cấu trúc của khóa luận

CHƯƠNG 2 CƠ SỞ LÝ THUYÊTT -cc-c ccceeeeeecccveeesrrrrrrrreerree 6

2.1 Các mô hình phát triển phần mềm ¿2 25+ +£++2x++£++zxtzx+zx+ 6

2.1.1 Waterfall’ gm rcs no 1 vìàăeieice.e 6 2.1.2 Agiloili NG -euyế cài § 2.2 Mô hình CI/CD ¿25+ 2E 339121 19121 12121 112 1E xree 11

2.2.1 Continuous Integration - CÌÍ «+ xxx sekkkrsekree I1

2.2.1.1 Tổng quan ¿2:22 2E2EeExrEkrrerrerrerrrrree 11

2.2.1.2 GitLab .13 2.2.1.3 Jenkins cà SH He 13 2.2.2 Continuous Delivery - CD/CDE 5 52+ c+c+ss+ 15 2.2.3 Continuous Deployment - CTD -. 55 55+ 2< ££+*£sscczsczer 16

2.3.3 Triển khai che 21

2.4 Mô hình DevSecODs 11k n HT ng ngư 23

2.4.1 Nguồn gỐC :- 5: 22222221 2122121 21221212121121211121121 xe 23 2.4.2 Đặc điểm c1 E111 1111121112111 re 24 2.4.3 Triển khai ch nHeerre 24

2.5 Mô hình MicrOSerViCeS - cc c+nSn St nai 26

2.5.1 Tổng quan 5: 221222 EE2192121212212112127121211121111 2X 26

2.5.2 Container hóa 27 P.2 29 2.5.4 Kubernetes c cty 30

2.5.4.1 Tổng quan ¿-2:- +2 2 2ExSExEEEErerkerrerrerree 30

2.5.4.2 Lightweight Kubernetes - K3s 52c 5< c+<c++ 33 2.5.4.3 Heli ssa, CS vựm , S Ă.oHeeeeheiie 34

2.6 Phat triển ứng dung web : :- 5s x2x2E2Exerkerxrrrrerrerrrrrrrrres 36

2.6.1 Tổng quan -52-52c22222+22E2E2E122122121211211211 2e 36

2.6.2 Angulir cS-c SS SH TT ng ng Hư 37

P "na 38

Pa 39 2.6.5 PostpreSQL, LH HH tiệt 39

2.7 Bảo mật quá trình phát triển ứng dụng web -. ¿5 z+s++x+zx+z 40 2.7.1 Tổng quan

2.7.2 SonarQube SH TT ng nen ra 40

2.7.5 TTÍVY cà HH HH HH HH HH HH tre 47

CHƯƠNG 3 PHAN TÍCH VÀ THIẾT KE MÔ HÌNH 49 3.1 Thiết kế mô hình ::©+t22+222+2221221122112211221122112211.11 tr 49 3.1.1 Phân tích và thiết kế mô hình ¿¿+++2x++zxxszxxsrxrerrrrrk 49 3.1.1.1 Mô hình tổng quan -2- + ©s+22++2++£xvzxzxrsrxerrerxrsses 49 3.1.1.2 Mô hình chỉ tiết :22+22+2Ex2EE2ESE.E.trrrrrree 51

3.1.1.3 Mục đích của mô hinh ce eee eceeeeseeeeseeeeeneeeeeeeeeseeeeeneeeae 54

3.1.2 Phân tích và thiết kế Jenkins pipeline

3.1.3 Quản lý và điều phối tập trung ¿- 2 25++2+22xtzxvsrvsrxerrrrer 57

3.1.3.1 Cơ sở dữ liệu 2c 2c SEtsritrrerrrirrierrrrre 57 3.1.3.2 Trang web quản tTỊ -.- c + xxx sverrrersrrreree 58 3.1.3.3 Kubernetes cty 67

3.2 Đặc điểm của mô HUM occ eecceceecsseecseesseesseessecsseesseesseesseesseesseesesseeess 69 3.2.1 Ưu điểm 22c 2E 22t 2 2 E2 eo 69

3.3.3.1 Lỗ hổng SQL Injection -:-25222x2x+2x2zverxerxrssee 81 3.3.3.2 Lỗ hổng XSSveececccccsscssssssessecssessessessessesssessessessecseessessesseeseeees 83 CHƯƠNG 4 ĐÁNH GIA KET QUA.

4.1 Kịch bản thử nghiệm - - - 1k HH Hy 87

4.1.1 Triển khai ứng dụng Web : :- +22 22+ezxerxrxrerrerrerrrrree 87

4.1.2 Cập nhật tính năng cho ứng dụng 55 55+ +5 *<+£++c++ 92 4.1.3 Cập nhật phiên ban của ứng dụng - 5 55+ x+sccsseeseersx 93

4.2 Kết quả thử nghiệm.

4.2.1 Thống kê trên trang web quản lý -.¿ :- + xecxsrvsrxsrrrrxee 94 4.2.2 - Phát hiện các lỗi bảo mật -.-:-22¿222+22v+22rxrerrxrrsrxrcrrs 96 4.2.3 Triển khai ứng dung e.sceceeceeceecsesseesessesseeseeseesseeseeseestssseeseestesees 101

4.2.4, Thông báo tự động -.:©22:22++t2cvrrerEvrerrrrerrrrrrrrree 102

4.3 Kiểm thử ào 2 0022122 r0 221211 103 4.4 Đánh giá mô hình đã triển khai .2:22222vxcScxvrerrrrerrrrerrrree 105

4.4.1 Ưu điểm của mô hình đã triển khai -. ¿c2 ©5+25++c+zz++x 105

4.4.2 Nhược điểm của mô hình đã triển khai - : -:cc+ss++>s+c2 106 CHUONG 5 KET LUẬN VÀ HƯỚNG PHAT TRIẺN - 107 5.1 KẾtHuận Ă 2 v22 2E 2 H2 H222 107 5.2 Hướng phát triển ¿- ¿©2¿©2++2++EEt2E+2EEEEEEEEEEESEEEerkrrkrrer 107 TÀI LIEU THAM KHẢO 5° 5° 25s s£©S££S££Ss£EseEse+Ssesezsersesse 108

PHU LUCA

1 Nội dung tập tin Jenkinsfile ¿555 55+ S2*+S+sssrseseerseree 110

4 Mã nguồn của trang web quản lý :-¿+ +cx+cxtzx+zxzzxerxerrrrsee

):800/2.0002020277 ầâẳậ)| AĂ

DANH MỤC HÌNH

Hình 2.1: Các giai đoạn của mô hình Waterfall - ccsssnnnnnnnnnnh hư 6

Hình 2.2: Các bước trong chu kỳ phát triển phần mềm của mô hình Agile 9

Hình 2.3: Chu kỳ phát triển phan mềm của mô hình Scrum -:- 10

Hình 2.4: Mô hình tích hợp liên tỤC + v19 3 1v ng ket 12 Hình 2.5: Quy trình làm việc với JenKIns eeeeeenennnnneeeeeeeeeeeceeeeeeeeees 14

Hình 2.6: Mô hình phân phối liên tục + ¿+2 2 2£ £+£+E+E+EzEzEzzzzzeccz 16

Hinh 2.7: M6 hinh trién khai lién 1 17Hình 2.8: Văn hóa [Devps 999900101 ng 19

Hình 2.9: Mô hình DevSecODps TQ LH nh re 24

Hình 2.10: Mô hình container hóa - - - << + + + 1 nh hy 27Hình 2.1 1: Kiến trúc DOcker ¿-¿ ¿ ¿S5 S332 2E2E2E£££E£EeEeEekekrererererei 29Hình 2.12: Kiến trúc của một Kubernetes Cluster khi không đi cùng với Cloud

Hình 2.17: Kiến trúc OWASP ZAP cssesescecsssesseeseeseeseseeseesesesnesneeneeneaeeeeenees 44

Hình 2.18: Kiến trúc OWASP Z⁄AP -.- 5S n1 11121212111 5111111111 1111110 cxeg 44

Hình 3.1: Mô hình tổng quan - +25 + +22 EE*ESEE£E£E£EEEEEEEEEEEEErErkrrrrkreri 50

Hình 3.2: Mô hình chi tiẾt - ¿+ 2 5£ SE SE 2EEE2E2E2525EE 1 112111121211 xe 51

Hình 3.3: Lưu đồ toàn hệ thống ¿+ ¿+ EE2E2E2E2EEEEEEEEEEEEEEEEEEEEErrrrrei 54

Hình 3.4: Thiết kế Jenkins pipeline - ¿+ 25252 2£ ££EeE+EeEzEzEzezsrered 55

Hình 3.5: Giao diện trang đăng nhập của trang web quản trỊ ‹‹ - 59

Hình 3.6: Giao diện trang web quản tri với tùy chon hiển thị chế độ xem bảng điều

khiến (dashboarc) - -á- c stx S1 1 11 51 11 111111111 11 11 1n ng TH TH TT nh ray 59

Hình 3.7: Giao diện trang web quản trị với tùy chọn hiển thị chế độ xem các báo cáo

về những lần thay đổi nội dung trên kho lưu trữ mã nguồàn - - -=¿ 60

Hình 3.8: Quy trình hoạt động của trang web quan fỊ ‹‹‹s << ++++++s: 60

Hình 3.9: Mô hình ứng dụng Kubernetes - - - sư 68

Hình 3 10: Mô hình triển khai ¿ ¿2522222 2E2E2E2E£EvEvEEEEEEEEEzxrxexexrrererred 70Hình 3.11: Danh sách các thành phan đã triển khai 5-5-5 5552s+szs+s2 73Hình 3.12: Các thành phần chạy trên Kubernefes ¿2 5 +2 +x+s+z£z£+xzz£z 74Hình 3.13: Cau hình webhook trên SonarQube - 7 nnsnn xxnxy 75

Hình 3.14: Tạo mới repository trên GI(ab - S333 xxx 76

Hình 3.15: Cau hình SonarQube trên J]enkIns +‹ << + **++ssssss 77

Hình 3.16: Cau hình Kubernetes trên Jenkins cccccccscscsesesesesesesessseseseeeeeeeees 78

Hình 3.17: Cau hình Kubernetes trên Jenkins c cccccccccscsesssesesesessseseseesseeeeeeees 78

Hình 3.18: Cấu hình GitLab trên Jenkins - -:- cxcc++rczxerxererrerrrei 79

Hình 3.19: Tạo docker registry trên Nexus repOSitOLry - 5S <<<<*+ 79

Hình 3.20: Trang web có 16 hong bảo mật + + 2 ++* +2 +E+E£z£+E+Ezz£zeexzsrs 80

Hình 3.21: Đoạn mã JavaScript minh họa các lỗ hồng bảo mật trong ứng dụng web

" Ẽ 6è ` Ấ cec sce eeeeeaeneeeeesesnsueeaeeeneeeeeees 81

Hình 3.22: Kết qua khai thác thành công lỗ hong SQL Injection trên ứng dụng web

"“— - ẮẮ 82

Hình 3.23: Doan mã HTML tôn tại lỗ hông XSS trên ứng dụng web 84

Hình 3.24: Khai thác thành công lỗ hồng XSS trên ứng dụng web 84

Hình 3.25: Doan mã JavaScript áp dụng giải pháp ngăn chặn 16 héng XSS và SQL

Injection trên ứng dụng web ng 85

Hình 3.26: Đoạn mã HTML áp dụng giải pháp ngăn chặn lỗ hồng XSS trên ứng dụng

1 sa 86

Hình 4.1: Lưu đồ kịch bản triển khai ứng dung web - - 52 + sec cz£+xzscz 87

Hình 4.2: Tạo mới Jenkins pIpeÌÏIne - - - ««« « «+ «xxx xxx nhe 88

Hình 4.3: Cau hình Jenkins pipeline ¿+ ¿+ +2 + E+E+E££E+E+E£zEeEeErererrerers 88

Hình 4.4: Cấu hình Jenkins pipeline 0.0.c.c.ccccccccccscscsssscsesesesesteseeeeseesseeesesees 89

Hình 4.5: Cấu hình Jenkins pipeline ¿- 5+ 52552222 22tzxzxzxrxererred 89

Hình 4.6: Tạo webhook trên GitLLab 5< - c2 {2111111111 1111531115512 90

Hình 4.7: Trang web được triển khai xuống môi trường production - 91Hình 4.8: Lưu đồ kịch bản cập nhật tinh năng cho ứng dung 92Hình 4.9: Tinh năng tìm kiếm được cập nhật trên ứng dụng web - 93Hình 4.10: Lưu đồ kịch ban cập nhật phiên bản của ứng dụng - 93

Hình 4.11: Phiên bản của ứng dụng được cập nhật ¿cccc << +++++++>: 94

Hình 4.12: Thống kê trên trang Dashboard - - ¿5z 25252 222£+tztzxzxzxexess 95

Hình 4.13: Các commit trên trang Dashboard + s + s****++>+++xss 95

Hình 4.14: Hiển thị kết quả của công cụ quét trên Dashboard - 96

Hình 4.15: Kết quả trạng thái của các công cụ quét -¿ + +2 +x+xcczesxzsrs 96

Hình 4.16: Kết quả phát hiện lỗi SQLi - 552525252 22222t2EzEzxzxexvss 97

Hình 4.17: Kết quả phát hiện đữ liệu nhạy cảm ¿-¿ + + 2222222222252 98

Hình 4.18: Kết quả phát hiện thư viện mắt an toàn -¿-2-+++++x+x+x+<+s+ 99

Hình 4.19: Kết quả phát hiện thiếu cấu hình bao mật - ¿25552 100

Hình 4.20: Kết quả phát hiện lỗi XSS - 552525252 222e++ztzxzxzxrea 101

Hình 4.21: Kết quả hoàn thành Jenkins pipeline - 5 2 + +s££+£+szs£+ 101

Hình 4.22: Jenkins pipeline tự động dừng khi phát hiện lỗi - 102

Hình 4.23: Jenkins pipeline tự động dừng khi không dat staging test 102

Hình 4.24: Kết quả ứng dụng chạy ở môi trường production - + 102

Hình 4.25: Thông báo commit không đạt staging fesfS -. -‹-<< - 102

Hình 4.26: Thông bao commit không đạt bảo mậit + -+ + + << <3 103

Hình 4.27: Thông báo ứng dụng đã triển khai xuống production 103

DANH MỤC BANG

Bảng 3.1: Mô tả các API HH 62

Bảng 3.2: Mô tả tham số của một API cụ thé với đường dẫn /api/commit 63Bang 3.3: Mô tả tham số của một API cụ thé với đường dẫn /detailreport 63Bảng 3.4: Mô tả tham số của một API cụ thé với đường dẫn /search 64Bang 3.5: Các thành phan trong mô hình triển khai 2- 2-5-5 5252szs+s+52 71Bang 3.6: Phần cứng của mô hình triển khai 5-2 2 2 +2 2 £zE+E£z£zezxzerz 71Bang 4.1: Kết quả kiểm thử trên một số ứng dung web 5-5-5552 104

DANH MỤC TỪ VIET TAT

STT [ Ký hiệu Nguyên nghĩa Tiếng Anh Nguyên nghĩa Tiếng Việt

1 API Application Programming

Interface Continuous Integration

Giao diện lập trình ứng dung

Tích hợp liên tục

Continuous Delivery Phân phối liên tục

Công nghệ Thông tin

Culture, Automation,

Measurement, Sharing

Văn hóa, Tự động, Đánh giá,

Chia sẻ Central Processing Unit

Command Line Interface

Bộ xử lý trung tâm Giao diện dòng lệnh

Cascading Style Sheet Bảng định kiêu theo tầng

Comma Separated Values

Common Vulnerabilities and

Exposures

Các giá tri được phân tách

băng dấu phây

Môi trường phát triển tích hợp

JavaScript Object Notation Ký pháp đối tượng của

JavaScript

Kubernetes Mean time to Detect Thời gian trung bình dé phat

hiện

Hệ thông tập tin mạng

Quality Assurance

Representational State Transfer

Đảm bảo chất lượng

Truyên trạng thái đại diện

22 RPC Remote Procedure Call

Random Access Memory

Cuộc gọi thủ tục từ xa

Bộ nhớ truy cập ngẫu nhiên

24 SRS | Software Requirements Tài liệu đặc tả yêu cau phan

27 TLS Transport Layer Security Bao mật tang giao vận

Uniform Resource Locator Dinh vi tai nguyén thong nhat

29 XML Extensible Markup Language

Data Serialization Language

Ngôn ngữ đánh dau mở rộng

Ngôn ngữ tuân tự hóa dữ liệu

TÓM TẮT KHÓA LUẬN

———<2 + t®———

Trên thị trường Công nghệ Thông tin hiện nay, việc day nhanh tốc độ triển khai sảnphẩm phần mềm đến khách hàng là một yếu tố cạnh tranh quan trọng Văn hóaDevOps có khả năng đây nhanh quy trình phát triển và nâng cao hiệu quả vận hànhphần mềm, nhờ vậy sản phẩm tiếp cận người dùng trong thời gian ngăn nhất Tuynhiên, DevOps không có tính bảo đảm an toàn thông tin, điều này tạo ra những rủi ro

bao mật cho người dùng Do đó, trong phạm vi khóa luận này, nhóm tác gia đã nghiên

cứu và triển khai mô hình đảm bảo an toàn thông tin theo hướng DevSecOps dé vừađáp ứng tốc độ vừa đảm bảo an toàn thông tin trong quy trình phát triển và vận hànhphần mềm Mô hình là sự ứng dụng công nghệ tự động hóa, tích hợp các công cụ bảo

mật và xây dựng trang web quản lý Sau đó, mô hình được thử nghiệm với một dự án

phát triển web cụ thé dé đánh giá ưu nhược điểm cũng như khả năng ứng dung của

mô hình trong thực tế

CHƯƠNG 1 MỞ ĐẦU

1.1 Lý do chọn đề tài

Trong thời đại số ngày nay, khi thị trường công nghệ thông tin ngày càng mởrộng và mang tính cạnh tranh cao, doanh nghiệp cần tiếp cận nhiều khách hàng hơn

bằng việc cải thiện trải nghiệm người dùng đối với sản phẩm phần mềm của họ Các

tính năng mới của phần mềm cần được cập nhật liên tục dé đáp ứng nhu cầu của

khách hàng Điều này đòi hỏi quy trình phát trién và vận hành phần mềm phải đây

nhanh tốc độ đồng thời vẫn phải đảm bảo tính én định của hệ thống Do đó, vấn đề

nghiên cứu mô hình phát triển phần mềm nhanh và an toàn là rất quan trọng cho bất

kỳ doanh nghiệp nào dé tổn tại trong thời đại cạnh tranh này

DevOps đang trở thành xu hướng dé day nhanh tốc độ triển khai sản phẩmphần mềm đến người sử dụng Đó là một phương pháp tiếp cận nhằm mục đích kết

hợp phát triển phần mềm (software development) và vận hành phần mềm (software

operations) [1] Trong thập ky qua, DevOps đã phát trién 6n định như một phươngpháp phát triển phần mềm và khả năng trién khai sản phẩm liên tục của DevOps đãgiúp các tô chức có thê trién khai ứng dụng lên đến hàng trăm lần mỗi ngày [2] Điều

nay đã giúp sản phẩm tiếp cận người dùng sớm hơn và nâng cao khả năng kiểm soát

lỗi.

Tuy nhiên, thực hiện bảo mật trong DevOps là một thách thức vì các phương

pháp bao mật truyền thong không thé theo kịp DevOps về khả năng và tốc độ [3].Chính vì thé DevSecOps đã được đề xuất dé đáp ứng nhu cầu bảo mật trong DevOpsbằng việc tạo ra các phương pháp bảo mật hiện đại có thé được kết hợp với DevOpsmột cách nhanh chóng và linh hoạt Nhờ vậy, quy trình phát triển và vận hành phần

mềm được thực hiện trong thời gian ngắn nhưng vẫn đảm bảo an toàn thông tin Vì

những lý do trên, nhóm tác giả đã quyết định chọn đề tài này

1.2 Mục tiêu nghiên cứu

- Nghiên cứu quy trình phát triển phần mềm có tính tích hợp liên tục

(Continuous Integration - CI), triển khai liên tục (Continuous Deployment

- CD) dựa trên mô hình DevOps và các nguy cơ gây mat an toàn thông tin

- _ Xây dựng quy trình đảm bao an toàn thông tin và tích hợp các công cu

kiêm thử tự động đề kiêm tra tính bảo mật của ứng dụng

- _ Triển khai và đánh giá quy trình đảm bảo an toàn thông tin cho một dự án

phát triển ứng dụng web

1.3 Đối tượng nghiên cứu

- Mô hình DevOps và các nguy cơ gây mat an toàn thông tin.

- _ Các công cụ hỗ trợ cho quá trình tích hợp liên tục va triển khai liên tục

- Các công cụ tích hợp đảm bảo an toàn thông tin trong quá trình phát triển

ứng dụng web.

- _ Nền tảng xây dựng ứng dung web Node1S

- Framework xây dựng ứng dụng web Express, Angular.

1.4 Pham vi nghiên cứu

Tìm hiểu, tham khảo các hướng nghiên cứu quy trình phát triển phan mềm

DevOps trên nền tang container hóa (Kubernetes) Từ đó, triển khai mô hình nâng

cao tính bảo mật cho DevOps bằng việc ứng dụng giải pháp mã nguồn mở và các

công cụ kiểm thử bảo mật nhăm phát hiện các nguy cơ gây mất an toàn thông tin trên

ứng dụng web.

1.5 _ Những đóng góp của khóa luận

1.5.1 Tinh mới của đề tai

Cho tới thời điểm hiện tại, đã có nhiều nghiên cứu về mô hình DevOps

cũng như những lợi ích mà nó đem lại đối với quy trình phát trién phần mềm Tuy

nhiên, việc triển khai mô hình có tích hợp bao mật DevSecOps còn hạn chế Mộtkhảo sát của nhóm HPE Security Fortify cho thấy trong khi nhiều người tin rằngbảo mật là một phần nên có trong DevOps, bảo mật không phải là điều mà nhiều

mô hình DevOps có Một nghiên cứu khác của Gartner? chỉ ra rằng ban quản lý, nhà

1Hewlett Packard Enterprise, "Application Security and DevOps" URL:

phát triển và nhà điều hành coi bảo mật là yếu tố cản trở sự nhanh nhẹn và tốc độ

cần thiết trong các hoạt động DevOps, như CI và CD, đây là một lý do dé không áp

dụng mô hình DevSecOps.

Tích hợp và nâng cao khả năng bảo mật cho mô hình DevOps là xu hướng

tat yêu đề tận dụng tối đa lợi ích mà DevOps mang lại Do đó, dé tài này sẽ nghiêncứu và trién khai mô hình DevSecOps vừa đảm bao được tính an toàn thông tin,vừa đảm bảo thời gian chuyên giao sản phâm cho khách hàng

1.5.2 Khả năng ứng dụng thực tế của đề tài

Ngày càng xuất hiện nhiều rủi ro gây mat an toàn thông tin và van dé bảo

mật ứng dung đang cấp thiết hơn bao giờ hết Khi sự cé bảo mật xảy ra, tính tin cậycủa sản phâm phần mềm trực tiếp bị ảnh hưởng và tốn rất nhiều nguồn lực dé khắc

phục sự cố Trong thực tế, đội ngũ bảo mật đã thực hiện một số công đoạn dé kiểm

tra tính an toàn của ứng dụng trước khi triển khai đến người dùng

Tuy nhiên, việc này làm chậm quy trình phát triển phần mềm dẫn đến ảnhhưởng đến tốc độ cập nhật các tinh năng mới dé đáp ứng nhu cầu khách hàng Do

đó, mô hình đảm bảo an toàn thông tin trong quy trình phát triển và vận hành phầnmềm (DevSecOps) được nhóm tác giả nghiên cứu nhăm giải quyết vấn đề thực tế

này.

Mặt khác, các quy trình phát trién phần mềm đã triển khai theo hướng

DevOps trong thực tế thi van có khả năng mở rộng và tích hợp mô hình DevSecOps

để giảm thiêu rủi ro bảo mật Mô hình có thé ứng dung cho các doanh nghiệp vừa

và nhỏ trong hoạt động phát triển và vận hành phần mềm

1.6 Cấu trúc của khóa luận

Khóa luận bao gồm 5 chương như sau:

Chương 1: Mở đầuTrình bày lý do chọn đề tài, mục tiêu nghiên cứu, đối tượng nghiên cứu, phạm

vi nghiên cứu, những đóng góp của khóa luận.

Chương 2: Cơ sở lý thuyết

Bao gồm nội dung liên quan đến các khái niệm, công nghệ, mô hình mà nhóm

tác giả đã tìm hiểu trong quá trình thực hiện khóa luận Những kiến thức được trình

bày trong chương này là cơ sở đề thực hiện thiết kế và triển khai hệ thống DevSecOps.

Ngoài ra, tại chương này còn mô tả về các công cụ kiểm thử bảo mật dé phát hiện cácvan đề về bao mật và bảo đảm an toàn thông tin cho ứng dụng web

Chương 3: Phân tích và thiết kế mô hìnhTrình bày ý tưởng của nhóm tác giả khi thiết kế mô hình Bao gồm mô hình

của hệ thống, Jenkins pipeline để thực hiện CI/CD và ứng dung web quản lý bảo mật

tập trung Giải thích các thành phần trong hệ thống, mô tả chức năng của chúng trong

mô hình, liệt kê các bước cần thiết đề triển khai mô hình

Chương 4: Đánh giá kết quả

Đánh giá ưu nhược diém của mô hình trong kịch bản thử nghiệm

Chương 5: Kết luận và hướng phát triển

Tổng kết quá trình thực hiện khóa luận và dé xuất các hướng phát triển dé tàitrong tương lai.

CHUONG 2 CƠ SỞ LY THUYET

2.1 Các mô hình phát triển phan mềm

2.1.1 Waterfall

Mô hình Waterfall được Winston W Royce đề xuất vào năm 1970 dé mô

tả một quy trình phát triển phần mềm tuần tự [4], trong đó các giai đoạn trong quá

trình phát triển phần mềm được thực hiện tuần tự từ trên xuống dưới (tương tự như

dòng chảy của thác nước ngày càng chảy xuống)

Mô hình xác định một số giai đoạn liên tiếp trong quy trình phát triển phầnmềm phải được hoàn thành lần lượt và chỉ chuyên sang giai đoạn tiếp theo khi giai

đoạn trước của nó được hoàn thành hoàn toàn Vì lý do này, mô hình Waterfall

mang tính chất đệ quy, trong đó mỗi giai đoạn có thể được lặp lại liên tục cho đến

khi hoàn thiện Hình 2.1 minh họa các giai đoạn khác nhau cua mô hình Waterfall.

Hình 2.1: Các giai đoạn của mô hình Waterfall

- Giai đoạn 1 (Requirements): Thường được gọi là Software

Requirements Specification (SRS) Đây là một mô tả đầy đủ và toàn

diện về các yêu cầu của phần mềm sẽ được phát triển Nó đòi hỏi các

nhà phân tích hệ thống và phân tích nghiệp vụ phải xác định cả các yêu

cầu chức năng và phi chức năng Thông thường, các yêu cầu chức năng

được xác định bang các trường hợp liên quan đến tương tác của người

dùng với phần mềm Các yêu cầu chức năng bao gồm như mục đích,

phạm vi, quan điểm, chức năng, thuộc tính phần mềm; đặc điểm người

dùng, đặc tả chức năng, yêu cầu giao diện và yêu cầu về cơ sở dit liệu

Ngược lại, các yêu cầu phi chức năng đề cập đến các tiêu chí, ràng buộc,

giới hạn và các yêu cầu khác nhau được đặt ra đối với việc thiết kế vàvận hành phần mềm Nó bao gồm các đặc tính như độ tin cậy, khả năng

mở rộng, khả năng kiểm thử, tính sẵn sàng, khả năng bảo trì, hiệu suất

và tiêu chuẩn chất lượng

Giai đoạn 2 (Design): La quá trình lập kế hoạch và giải quyết các van

đề cho một giải pháp phần mềm Nó yêu cầu các nhà phát triển phần

mềm và thiết kế phần mềm xác định kế hoạch cho một giải pháp bao

gồm thiết kế thuật toán, thiết kế kiến trúc phan mềm, mô hình khái niệm

cơ sở dit liệu và thiết kế sơ đồ logic, thiết kế ý tưởng, thiết kế giao diệnngười dùng, định nghĩa cấu trúc dữ liệu

Giai đoạn 3 (Implementation): Day là quá trình chuyền đổi toàn bộ các

yêu cầu (giai đoạn 1) và bản thiết kế (giai đoạn 2) thành môi trường sản

xuất

Giai đoạn 4 (Verification): Đây là một quá trình dé kiểm tra xem mộtgiải pháp phần mềm có đáp ứng các yêu cầu, thông số kỹ thuật ban đầu

và có đạt được mục đích dự kiến hay không Giai đoạn này gồm hai quá

trình là verification va validation Verification là quá trình đánh giá

phần mềm đề xác định xem các sản phẩm của một giai đoạn phát triểnnhất định có thỏa mãn các điều kiện đặt ra khi bắt đầu giai đoạn đó haykhông Trong khi validation là quá trình đánh giá phần mềm trong quytrình phát triển hoặc khi kết thúc quy trình phát triển dé xác định xem

nó có thỏa mãn các yêu cầu quy định hay không [5] Hơn nữa, giai đoạn

này là đầu ra đề thực hiện gỡ lỗi, trong đó các lỗi và những trục trặc hệ

thong được tim thấy, sửa chữa và tinh chỉnh cho phù hợp

- Giai đoạn 5 (Maintenance): Đây là quá trình sửa đổi giải pháp phan

mềm sau khi phân phối và triển khai dé tinh chỉnh đầu ra, sửa lỗi, cảithiện hiệu suất và chất lượng Các hoạt động bảo trì bổ sung có thể đượcthực hiện trong giai đoạn này bao gồm điều chỉnh phần mềm phù hợpvới môi trường của nó, đáp ứng các yêu cầu mới của người dùng vàtăng độ tin cậy của phần mềm [6]

2.1.2 Agile

Trong các mô hình phát triển phần mềm truyền thống (vi dụ như mô hìnhWaterfall), các nhóm phải làm việc với một kế hoạch chỉ tiết và có một danh sáchđầy đủ các nhiệm vụ phải hoàn thành trong vài tháng tới hoặc trong toàn bộ vòngđời của sản phẩm Phương pháp làm việc này hoàn toàn phụ thuộc vào việc phântích yêu cau và lập kế hoạch một cách can thận ở đầu chu kỳ phát triển phần mềm.Bat kỳ thay đổi nào được đưa vào sẽ phải trải qua một quá trình ưu tiên quản lýkiểm soát thay đổi nghiêm ngặt

Mô hình Agile dựa trên cách tiếp cận lặp đi lặp lại quy trình phát triển

Thay vì lập kế hoạch chuyên sâu ngay khi bắt đầu dự án, các phương pháp Agilesan sàng đáp ứng các yêu cầu thay đôi theo thời gian và khuyến khích phản hồi liên

tục từ người dùng cuối Mục tiêu của mỗi lần lặp là tạo ra một sản phẩm hoạt động

tốt.

Mô hình Agile đề cập đến bat kỳ quy trình nào phù hợp với các khái niệmtrong Tuyên ngôn Agile? được xuất bản vào năm 2001 Chu kỳ phát trién phan mềm

của mô hình Agile được mô tả trong hình 2.2.

3 K Beck, A Cockburn, J Highsmith and R Jeffries, "Manifesto for Agile Software Development" URL:

Hình 2.2: Các bước trong chu kỳ phát triển phần mềm của mô hình Agile

Một số thuận lợi khi sử dung mô hình Agile:

Các thay đôi trong quy trình phát trién phan mềm được chấp nhận

Mô hình Agile có lợi cho các dự án mà mục tiêu cuối cùng không được

xác định rõ ràng Khi dự án tiễn triển, các mục tiêu sẽ trở nên rõ ràng

và nhóm phát triển có thé thích ứng

Phân phối nhanh hơn

Tương tác nhóm làm việc mạnh mẽ.

Khách hàng được lắng nghe: Khách hàng có nhiều cơ hội để xem công

việc được giao, chia sẻ ý kiến đóng góp của họ Những ý kiến của khách

hàng có nhiêu tác động đên sản phâm cuôi cùng.

Mặc dù mô hình Agile rất linh hoạt, tuy nhiên nó cũng đi kèm với một vài

Một số phương pháp được sử dụng để triển khai Agile như: Scrum,

Kanban, Trong số đó, Scrum được sử dụng phổ biến nhất.

Scrum là một mô hình phát triển dựa trên cách tiếp cận lặp đi lặp lạiquy trình phát trién phan mềm và thường được sử dụng dé quản lý quytrình phát triển phan mềm phức tạp Thuật ngữ Sprint trong mô hìnhScrum thể hiện cho các công việc cần được thực hiện trong khoảng thờigian từ một đến bốn tuần Dựa vào Sprint sẽ giúp cho nhóm phát triểnphân phối phần mềm đều đặn Vào cuối mỗi Sprint, các bên liên quan

và các thành viên trong nhóm phát triển tiến hành họp dé lập kế hoạch

cho các bước tiếp theo.

Chu kỳ phát triển phan mềm của mô hình Scrum được minh họa trong

Product Sprint Planning Sprint Finished

Backlog Meeting Backlog Work

Hình 2.3: Chu ky phát trién phan mềm của mô hình Scrum

Một số thuận lợi khi áp dụng mô hình Scrum:

e Minh bạchhơn: Với các cuộc họp trực tiếp hàng ngày, cả nhóm biết

được ai đang lam gi, nắm bắt các van dé đã được xác định trước Từ

đó, giúp cải thiện khả năng giao tiếp và cho phép nhóm xử lý cácvan đề ngay lập tức

e Tăng trách nhiệm giải trình của nhóm: Không có người quản lý dự

án, thay vào đó, nhóm quyết định những công việc họ có thể hoàn

thành trong mỗi Sprint và làm việc cùng nhau, có trách nhiệm giải

trình.

e Dễ dàng điều chỉnh các thay đổi: Với thời gian kéo dài trong mỗi

Sprint ngắn và phản hồi liên tục, việc điều chỉnh các thay đôi trở

nên dễ dàng hơn.

e _ Tiết kiệm chi phi: Các thành viên trao đồi thông tin liên tục đảm bảo

nhóm nhận thức được tất cả các vấn đề và thực hiện các thay đôisớm hơn, từ đó giúp giảm chỉ phí và tăng chất lượng

- Một số khó khăn khi áp dụng mô hình Scrum:

e Nhóm cần phải nam rõ các nguyên tắc Scrum, cũng như cần cam

kết thực hiện các cuộc họp hàng ngày và không được rời khỏi dự án

trong suốt quá trình phát triển

e Scrum Master sai có thé làm hỏng mọi thứ: Scrum Master rất khác

với một người quản lý dự án Scrum Master không có quyên đối với

nhóm, vì vậy người đó phải tin tưởng vào nhóm đề hoàn thành công

aA

viéc.

e Các nhiệm vụ được xác định không rõ rang có thé dẫn đến chi phí

và thời gian của dự án không chính xác.

2.2 Mô hình CI/CD

2.2.1 Continuous Integration - CI

2.2.1.1 Tổng quan

Tích hợp liên tục (Continuous Integration - CI) là phương pháp phát triển

phần mềm được thiết lập rộng rãi [7], trong đó các thành viên của nhóm phát triển

phải thường xuyên tích hợp các thay đổi trong mã nguồn của họ vào một kho lưutrữ trung tâm (central repository), thường thì mỗi người tích hợp ít nhất một lầntrong ngày - dẫn đến nhiều lần tích hợp mỗi ngày Mỗi một lần tích hợp sẽ đượcxác minh bởi quá trình xây dựng (build) và thử nghiệm (test) tự động dé phát hiện

lỗi tích hợp nhanh nhất có thé [8] CI thuong dé cap dén giai đoạn xây dựng hoặctích hợp của quá trình phát hành phần mềm, yêu cầu cả thành phần tự động hóa(ví dụ như CI hoặc build service) và thành phần văn hóa (ví dụ như học cách tích

hợp code thường xuyên) Các mục tiêu chính của CI là tìm và giải quyết các lỗi

nhanh hơn Từ đó, giúp cải thiện chất lượng phần mềm, gắn kết các thành viêntrong nhóm phát triển và giảm thời gian phát hành các bản cập nhật phần mềm

mới [7].

Tích hợp liên tục tập trung vào các thay đổi trong code dé tích hợp Cácnhà phát trién commit code đều đặn, ít nhất một lần mỗi ngày Tuy nhiên, các nhàphát triển phải lay code từ kho lưu trữ trung tâm dé đảm bảo code trên kho lưu trữcục bộ được hợp nhất (merge) trước khi day lên máy chủ thực hiện chức năng xâydựng (build server) Ở giai đoạn này, build server sẽ thực hiện kiểm thử bằng cáchchạy các test case tự động Nếu không có lỗi xảy ra, dự án sẽ chuyên sang giaiđoạn tiếp theo Ngược lại, nếu có lỗi xảy ra, lỗi đó sẽ được thông báo cho nhómphát triển dé tiền hành sửa lỗi một cách nhanh nhất

Việc trién khai CI cũng gặp nhiều thách thức Các thách thức cơ bản nhưphải thường xuyên commit code, duy trì một kho lưu trữ mã nguồn duy nhất, tựđộng hóa quá trình xây dựng và kiểm thử Ngoài ra, còn có các thách thức khácnhư vấn đề thử nghiệm trong các môi trường tương tự môi trường sản xuất

Source control Cl Server

Push the code

2.2.1.2 GitLab

GitLab là một ứng dụng web được thiết kế dé cải thiện và nâng cao sự

phát triển hợp tác trên một phần mềm Nó cho phép mọi người tương tác với một

hoặc nhiều kho lưu trữ git bằng cách sử dụng giao diện web thân thiện Ngoài ra,

GitLab còn mở rộng chức năng của kho lưu trữ bằng các công cụ chuyên dụng

GitLab được viết bằng ngôn ngữ Ruby với giấy phép phần mềm mãnguồn mở MIT Một số phan sau đó được viết băng ngôn ngữ Go và VueJS.GitLab cũng là một nền tảng DevOps hoàn thiện được phân phối dưới dạng mộtphần mềm đơn lẻ'

Với GitLab, các cá nhân, tổ chức hay doanh nghiệp có thể lưu trữ và quản

lý kho mã nguồn một cách nhanh chóng, thuận tiện, khoa học và an toàn Ngoài

ra, GitLab cũng có thể được cài đặt trên một máy chủ riêng dé tiện cho việc sử

dụng và quản lý.

2.2.1.3 Jenkins

Jenkins là một trong những công cụ tích hợp liên tục lâu đời nhất, được

phát hành lần đầu vào năm 2011 Jenkins có mã nguồn mở và được phát triểnbằng Java Nhờ vào cộng đồng lớn làm việc trên Jenkins và một số lượng lớn cácplugin mà Jenkins đã trở thành công cụ phô biến nhất để thực hiện các quy trình

tích hợp liên tục và phân phối liên tục hoặc triển khai liên tục

Một quy trình làm việc đơn giản với Jenkins được mô tả trong hình 2.5.

4 GitLab Inc, "DevOps platform delivered as a single application" URL: https://about.gitlab.com/

Các nhà phát triển (developer)

commit code thay đổi lên shared

repository.

trình build và chạy các thử

nghiệm (test) nếu được yêu cầu.

Kết qua của quá trình build sẽ hiển thị trong bảng điều khiển cua Jenkins Jenkins tự động gửi thông báo đến các nhà phát triển

nếu có lỗi xảy ra.

Hình 2.5: Quy trình làm việc với Jenkins

Một vài đặc điêm nôi bật của Jenkins như sau:

Jenkins có rất nhiều plugin hỗ trợ hầu hết các ngôn ngữ lập trình và

các framework.

Jenkins có thé sử dụng bat kỳ lệnh shell và phần mềm nào nên nó phù

hợp với mọi quy trình tự động hóa.

Jenkins cho phép người dùng viết các plugin của riêng mình dé tùychỉnh Jenkins theo nhu cầu

Jenkins được viết băng Java nên có thê chạy trên mọi hệ điều hành

Nó cũng được cung cấp với nhiều phiên bản như: WAR, Docker

image, tệp nhị phân Windows, tệp nhị phân macOS và tệp nhị phân

Linux.

Jenkins tích hợp với hầu hết các công cụ xây dựng và quản lý mã

nguôn.

- Jenkins có một cơ chế tích hợp ở chế độ master/slave Cơ chế này hỗ

trợ phân phối việc thực thi của Jenkins trên nhiều node năm trên nhiều

máy Các node khác nhau có thé được cài đặt các hệ điều hành khác

nhau.

- Qua trình cài đặt và cấu hình Jenkins rat đơn giản Người dùng không

cần phải cấu hình bat kỳ phần mềm bé sung nào cũng như cơ sở dữliệu Jenkins có thé được cấu hình hoàn toàn thông qua GUI hoặc tậptin XML, tập lệnh Groovy Vì vậy, người dùng hoàn toàn có thê giữ

cau hình Jenkins trong kho lưu trữ mã nguồn và giúp tự động hóa cấu

hình Jenkins.

2.2.2 Continuous Delivery - CD/CDE

Phân phối liên tục (Continuous Delivery - CD/CDE) là bước tiếp theo sau

khi hoàn tất thành công quá trình tích hợp liên tục Quá trình này sẽ triển khai ứng

dụng tự động trong một hoặc nhiều môi trườn g staging

CI thực hiện đóng gói ứng dung va lưu trữ chúng trong package

management (ví dụ như Nexus, Azure Artifacts, ) Goi ứng dung này sẽ được triển

khai trong quá trình phân phối liên tục Điều này đảm bảo rằng ứng dụng sẽ đượcxác thực trong các môi trường khác nhau đều có cùng chất lượng như nhau

Môi liên kết giữa tích hợp liên tục và phân phối liên tục trong môi trường

tích hợp rất phô biến Trong khi CI sẽ thực hiện kiểm thử đơn vị (unit test) trong

quá trình phát triển phần mềm thi CD sẽ kiểm tra toàn bộ ứng dụng bao gồm giaodiện người dùng, chức năng và tất cả các phụ thuộc của nó

Điểm quan trọng trong quy trình phân phối liên tục là việc triển khai xuốngmôi trường sản xuất được kích hoạt theo cách thủ công bởi những người được cấpquyền phê duyệt

nhà phát triển commit mã nguồn, những thay đồi trong mã nguồn sẽ được triển khai

lên môi trường sản xuất thông qua một deployment pipeline Phạm vi của phân phối

liên tục không bao gồm việc phát hành phần mềm thường xuyên và tự động, và

cũng do đó mà triển khai liên tục là sự tiếp nối của phân phối liên tục Trong khi,

5 J Humble, "Continuous Delivery vs Continuous Deployment" URL:

phân phối liên tục có thé áp dụng cho tat cả các loại hệ thống, tô chức thì triển khai

liên tục có thé chi phù hợp với một số loại tổ chức hoặc hệ thống.

Thực hiện những thay đổi lên môi trường sản xuất không phải là một sựkiện gây gián đoạn Việc triển khai không yêu cầu nhóm kỹ thuật ngừng làm việcvới những thay đổi tiếp theo và không cần kế hoạch dự án, tài liệu bàn giao hoặcthời hạn bảo trì Việc triển khai trở thành một quá trình lặp lại đã được thực hiện vàchứng minh nhiều lần trong môi trường thử nghiệm

Dus Integration 3Š Continuous Deployment

Hinh 2.7: M6 hinh trién khai lién tuc

2.3 Mô hình DevOps

2.3.1 Nguồn gốc

Ưu điểm của các quy trình Agile, bao gồm Scrum và Kanban thường bị vô

hiệu hóa vì những trở ngại đối với sự hợp tác, quy trình và công cụ được xây dựng

trước khi vận hành Do đó, phần mềm được phát hành thường xuyên nhưng chỉ

trong môi trường thử nghiệm Phần mềm hiếm khi được đưa vào giai đoạn triển

khai trên môi trường sản xuất Nói cách khác, không phải tất cả các bản phát hànhđều đến được người dùng và việc triển khai đến người dùng thường xảy ra sau khinhóm phát triển đã viết mã và kiểm thử bản phát hành

Tóm lại, thời gian từ khi hình thành một ý tưởng đến khi nó được đưa đến

tay người dùng vẫn còn quá dài Tần suất phát hành phần mềm cao từ quá trình phát

triên và các tác động của nó đôi với quá trình vận hành dân đên điêu mà nhiêu người

trong công ty sẽ coi là nút thắt cổ chai trong vận hành Nhóm phát trién muốn nhóm

vận hành đưa các thay đổi của họ vào sản phẩm và nhóm vận hành có thé chấp nhận

lịch phát hành trong thời gian ngắn Do đó, việc phát triển có thé đã hoàn thành sớmbang cách sử dụng mô hình Agile nhưng việc vận hành có thé không nhận được tat

cả các thay đôi từ các nhà phát triển

Theo quan điểm của nhóm phát triển, thời gian chờ đợi phát hành phanmềm không phải là vấn đề duy nhất Một vấn đề khác là bản phát hành phần mềmmới phải hoạt động trong một khoảng thời gian cụ thể Nếu sự cố xảy ra trong

khoảng thời gian này, không phải lúc nào cũng có giải pháp và trong trường hợp

xâu nhất, nhóm vận hành phải quay lại phiên bản cũ và bộ phận phát triển phải xemxét thời điểm phát hành tiếp theo trong tương lai Các nhà phát triển sẽ đồ lỗi chocác nhà vận hành không thé thiết lập phần mềm hoạt động Các nhà vận hành sẽ đồ

lỗi cho các thành viên trong nhóm phát triển vì họ không có khả năng phát triển

phần mềm sẵn sàng cho môi trường sản xuất

Trong những năm qua, nhiều người đã làm việc để áp dụng các phương

pháp Agile vào các hoạt động vận hành nhằm mục đích xóa bỏ bức tường giữa hai

bộ phận phát triển và vận hành Bang cách chia sẻ kỹ năng, ý tưởng, van dé, quytrình, công cụ, mục tiêu và kinh nghiệm, phong trào đã hình thành nên DevOps Với

cách tiếp cận DevOps, vai trò của nhà phát triển bao gồm lập trình viên, người kiêmthử, QA và chuyên gia vận hành Mỗi cá nhân đều có các hiểu biết cơ bản về lĩnhvực của các thành viên khác Tắt cả đều phát triển phần mềm và đưa phần mềm đóđến với người dùng một cách nhanh chóng và an toàn

Thuật ngữ DevOps được Patrick Debois, Gene Kim và John Willis đưa ra

vào năm 2007-2009 và nó đại diện cho sự kết hợp giữa Dev (Development) va Ops(Operations) Phong trào DevOps nham mục dich cải thiện giao tiếp giữa các nhàphát triển và nhóm vận hành dé giải quyết các van đề quan trọng như sự thay đôihay bổ sung tính năng của phần mềm và các rủi ro trong quá trình triển khai phan

mềm DevOps đòi hỏi một quy trình liền mạch, tích hợp cao từ khi bắt đầu pháttriển cho đến khi kết thúc triển khai vào môi trường sản xuất và bảo tri Dé giúp tự

động hóa và tích hợp tất cả các bước phân phối thiết yêu một cách tông thé, phương

pháp DevOps cũng cần có những thay đổi về công cụ DevOps nhắn mạnh vào con

người và văn hóa, đây cũng chính là nền tảng cơ bản để DevOps thành công

DevOps hướng đến cách làm việc theo nhóm và cách tiếp cận hợp tác giải

quyết vấn đề Nếu một dịch vụ gặp sự cố, mọi người phải biết những quy trình cần

tuân theo dé chân đoán sự có và đưa hệ thống hoạt động trở lại Ngoài ra, tat cả các

vai trò và kỹ năng can thiết dé thực hiện các nhiệm vụ này phải sẵn có và có théphối hợp tốt với nhau Đào tạo và hợp tác hiệu quả là rất quan trọng ở đây

năm 2010 Bốn yếu tố cau thành mô hình CAMS bao gồm:

- Culture (Văn hóa): Đây là một phan thiết yếu của DevOps Văn hóa

DevOps chính là việc tăng cường sự hợp tác giữa các vai trò khác nhau

chăng hạn như bộ phận phát triển, bộ phận vận hành và bảo mat® Mộtthái độ chia sẻ trách nhiệm là điều quan trọng để đạt được sự hợp tác

`

này.

® R Wilsenach, "DevOpsCulture" URL: https://martinfowler.com/bliki/DevOpsCulture.html

Automation (Tự động hóa):

e DevOps thường được liên kết với tự động hóa Đề nhanh chóng triển

khai mã, nên áp dụng các phương pháp liên tục như tích hợp liên

tục, phân phối liên tục và triển khai liên tục Tích hợp liên tục là khicác thành viên trong nhóm tích hợp và hợp nhất công việc phát triểnthường xuyên, chăng hạn như nhiều lần trong ngày [10] Công việcnày bao gồm kiểm thử và xây dựng phần mềm tự động Điều đó cónghĩa là các bài kiểm tra có thé được viết và sau đó tự động chạy

trên máy chủ tích hợp liên tục.

Trong thực tiễn DevOps, các công cụ và cơ sở hạ tầng thích hợp làcần thiết để tự động hóa quá trình phân phối mã Sự thành công củaviệc áp dụng các bản phát hành liên tục chủ yếu dựa vào việc triển

khai pipeline.

- Measurement (Sự đo lường): Đề ngăn chặn sự có hệ thống nên thực

hiện giám sat và đo lường các chỉ số hệ thông Thường có ba loại phép

đo khác nhau”:

e Loại đầu tiên là ứng dụng chính và sức khỏe cơ sở hạ tầng Loại này

liên quan đến việc đo các điểm chuẩn như mức sử dụng phan trămCPU va thời gian phản hồi trung bình

Loại thứ hai bao gồm các phép đo về độ tin cậy và sức khỏe của hệ

thống Loại này bao gồm khoảng thời gian từ khi bắt đầu sự có đếnkhi phát hiện ra sự có, tức là thời gian trung bình dé phát hiện (Mean

time to Detect - MTTD).

Loại cuối cùng liên quan đến các phép đo về sức khỏe và hiệu suất

của nhóm làm việc như số lượng mã được commit, thời gian và tần

suât triên khai.

Sharing (Sự chia sẻ): Một khía cạnh của việc khắc phục sự phân chia

giữa các bộ phận khác nhau là chia sẻ kiến thức Mô hình SECI cung

cấp bốn cơ chế chia sẻ kiến thức giữa bộ phận phát triển và vận hành

[11] Bốn cơ chế này được chia thành hai loại: kiến thức ngầm và kiến

thức rõ ràng Kiến thức rõ ràng là kiến thức chính thức, có hệ thống, dễdàng lưu trữ và tài liệu hóa Mặt khác, kiến thức ngầm mang tính cánhân và khó thể hiện một cách có hệ thống Việc chia sẻ kiến thức thậm

chí còn khó hơn đối với một công ty so với việc sử dụng các công cụ

chính xác Báo cáo DevOps Maturity Model năm 2017 cho thấy rằng

các công ty đang chia sẻ các công cụ nhưng không chia sẻ kiên thức.

dụng, các ngôn ngữ lập trình như C, C++, JavaScript, Python, Ruby,

được sử dụng Các công cụ như GIT, GitLab, TFS va Mercurial giúp tôchức và duy trì mã nguồn

Tích hợp liên tục (Continuous Integration): Day là giai đoạn nam vaitrò cốt lõi trong toàn bộ vòng đời DevOps Trong thực tiễn, mã nguồn

được sửa đổi nhiều lần và những thay đổi này diễn ra hàng tuần hoặc

hàng ngày Trong tích hợp liên tục, các mã mới được xây dựng và tích

hợp vào mã hiện có Mỗi một lần tích hợp sẽ được xác minh bởi quátrình xây dựng và thử nghiệm tự động đề phát hiện lỗi tích hợp nhanh

"DevOps Maturity Model report: trends and best practices in 2017" URL:

https://www.atlassian.com/blog/devops/devops-culture-and-adoption-trends

nhất có thé Đề thực hiện quá trình tích hợp liên tục, công cụ được sửdụng phổ biến nhất là Jenkins.

Kiểm thử liên tục (Continuous Testing): Ở giai đoạn này, phan mềm đãphát triển liên tục được kiêm tra lỗi Một môi trường thử nghiệm được

mô phỏng với việc sử dụng các vùng chứa (container) của Docker.

Kiểm thử tự động giúp các nhà phát trién tiết kiệm được công sức vàthời gian thay vì phải thực hiện kiêm thử theo cách thủ công

Phản hồi liên tục (Continuous Feedback): Phản hồi liên tục là một giaiđoạn đặc biệt, nơi những bổ sung, cải tiễn trong mã nguồn của ứng dụngđược phân tích Tại đây, các nha phat trién có thể đánh giá về chat lượngcủa những tính năng mới được phát triển Đặc biệt, những phản hồi củakhách hang trong quá trình thử nghiệm ứng dụng mới là yếu tố quan

trong đề các nhà phát triển có thể đánh giá và sửa đổi kịp thời nhằm đáp

ứng tốt nhất các nhu cầu của khách hàng

Triển khai liên tục (Continuous Deployment): Trong giai đoạn này, mã

nguồn của ứng dụng được triển khai vào các môi trường staging và môitrường sản xuất Các công cụ container hóa đóng một vai trò quan trọngtrong quá trình trién khai liên tục Những công cụ này giúp duy trì tínhnhất quán trên các môi trường nơi ứng dụng được thử nghiệm, pháttriển và triển khai

Giám sát liên tục (Continuous Monitoring): Nhằm mục đích ngăn chặncác sự có hệ thong và các rủi ro bao mật trong cơ sở hạ tang CNTT nênthực hiện giám sát và đo lường các chỉ số hệ thống liên tục Điều này

sẽ giúp duy trì tính sẵn sàng của các dịch vụ trong ứng dụng Thông

qua quy trình giám sát liên tục, các môi đe dọa, rủi ro bảo mật và nguyênnhân sự cô sẽ được xác định Nếu một sự cố xảy ra trong giai đoạn nay,

ứng dụng sẽ được chạy lai qua các giai đoạn trước đó Nhờ vậy, giúp

khắc phục sự cố và các van đề bao mật nhanh chóng Đây là giai đoạn

mà các nhà vận hành phải hoạt động một cách tích cực.

- Van hành liên tục (Continuous Operations): Day là giai đoạn cuốỗi cùng

của vòng đời DevOps, mặc dù rất quan trọng nhưng ít phức tạp nhất và

tốn ít thời gian nhất Giai đoạn này chủ yêu nhằm mục đích tự động hóa

Trong quá khứ, vai trò của an ninh được phân lập cho một nhóm cụ thê

trong giai đoạn phát triển cuối cùng Điều đó không có vấn đề gì khi chu kỳ phát

triển kéo đài hàng tháng hoặc thậm chí hàng năm, nhưng những ngày đó đã qua.DevOps dam bao chu kỳ phát trién nhanh chóng và thường xuyên (đôi khi vài tuầnhoặc vài ngày) Tuy nhiên, các phương pháp bảo mật truyền thống có thé khôngtheo kịp tốc độ và sự linh hoạt của DevOps cũng trở thành một thách thức lớn đối

với việc tích hợp bao mật vào DevOps [3].

Gio đây, trong khuôn khổ hợp tác của DevOps, bao mật là trách nhiệmchung được tích hợp từ đầu đến cuối D6 là một tư duy quan trọng đến mức khiếnmột số người đặt ra thuật ngữ “DevSecOps” để nhân mạnh sự cần thiết phải xâydựng nền tảng bảo mật cho quy trình DevOps

DevSecOps có nghĩa là áp dung bảo mật ứng dụng và cơ sở hạ tang ngay

từ đầu Nó cũng có nghĩa là tự động hóa một số công bảo mật dé giữ cho quy trìnhlàm việc DevOps không bị chậm lại Việc lựa chọn các công cụ phù hợp để liên tụctích hợp bảo mật, ví dụ như một môi trường phát triển tích hợp CIDE) với các tínhnăng bảo mật có thể giúp đáp ứng các mục tiêu này

DevSecOps đáp ứng nhu cầu bảo mật trong DevOps Nó bao gồm cácphương pháp bảo mật hiện đại có thể được tích hợp trong DevOps nhanh chóng và

linh hoạt DevSecOps thúc day phần mở rộng cho mục tiêu của DevOps là thúc day

sự hợp tác giữa các nhà phát triển và nhà vận hành băng cách thu hút sự tham gia

của các chuyên gia bảo mật ngay từ đâu.

Sec

Ops |

2.4.2 Đặc điểm

Các nguyên tắc đặc trưng cho DevSecOps dựa trên DevOps và các nguyên

tac CAMS Tuy nhiên, nó bổ sung thêm bao mật ngay từ đầu Trong quy trình pháttriển phần mềm, bảo mật là bước gần với phần cuối của quy trình DevSecOps thúcđây sự chuyên dịch sang bên trái để bảo mật sẽ được đưa vào mọi phần của quytrình phát triển phần mềm° Các nhóm bảo mật tham gia ngay từ bước lập kế hoạchđầu tiên và là một phần của việc lập kế hoạch cho mọi lần lặp lại của chu kỳ pháttriển Điều đó cũng có nghĩa là bảo mật ở đó dé giúp các nhà phát triển và nhà vậnhành về các cân nhắc bảo mật

2.4.3 Triển khai

Quy trình triển khai DevSecOps có thé tuân theo các giai đoạn sau đây:

- M6 phỏng mối đe doa và đánh giá rủi ro (Threat modeling and risk

assessments): Triển khai DevOps an toàn có nghĩa là các tổ chức phải

phát triển chuyên môn và quy trình dé phát hiện, bảo vệ chống lại và

tìm ra giải pháp tốt nhất cho các mối đe dọa và rủi ro!°, tốt nhất là trước

thời hạn Thực hiện đánh giá rủi ro từ giai đoạn lập kế hoạch đầu tiên

3 S, Lietz, "Shifting Security to the Left" URL: https://goo.gl/sbheKS

và liên tục trước mỗi lần lặp lại là quan trọng như một cách dé ưu tiênrủi ro, kiểm tra các biện pháp kiểm soát đã có và quyết định cái nào cầnthiết trong tương lai Mô phỏng mối đe dọa là một phương pháp khác

trong đó nhóm bảo mật cần mô phỏng các cuộc tấn công trong chu kỳ

phát triển để xác định cách một cuộc tan công có thé xảy ra và nơi nó

có nhiều khả năng xảy ra nhất

- _ Kiểm thử liên tục (Continuous testing): Kiểm soát bảo mật tự động ở

mọi phan của quy trình phát trién phần mềm rat quan trọng đối với việcdam bảo an ninh và cho phép kiểm thử dé liên tục quét mã tìm các thay

đi, liên tục phát hiện các điểm bat thường và tự động khôi phục mãkhi cần thiée?

- Gidm sát và ghi nhật ký (Monitoring and logging): Khi tự động hóa các

biện pháp kiểm soát bảo mật trong suốt quy trình phát triển phần mềm,điều quan trọng là nhóm bảo mật có thể tạo ra báo cáo theo yêu cầurằng các biện pháp kiểm soát đang hoạt động và chúng có hiệu quả

- Bao mật dưới dang mã (Security as code): Điều này có nghĩa là xác

định các chính sách bảo mật, ví dụ như kiêm tra tích hợp, cấu hình mạng

và truy cập, đồng thời viết các mẫu kịch bản hoặc tệp cấu hình có thểđược trién khai vào quy trình phát triển từ khi bắt đầu dự án Các chínhsách bảo mật được hệ thống hóa này sau đó có thé được kích hoạt tựđộng theo lịch trình hoặc được kích hoạt bởi người dùng (chỉ cần nhắnvào một nút) và được lưu trữ trong kho lưu trữ trung tâm đề sử dụng lại

trên các dự án moi".

- Red-Team và diễn tập bảo mật (Red-Team and security drills): Dé tránh

những cuộc tan công có thé xảy ra, những người thực hiện DevSecOps

11 K, Lindros, “How to craft an effective DevSecOps process with your team" URL: https://goo.gl/ppWtjx

12 C, Romeo, "The 3 most crucial security behaviors in DevSecOps" URL: https://goo.gl/FJKUYQ

13 G Bledsoe, "Getting to DevSecOps: 5 best practices for integrating security into your DevOps" URL:

https://goo.gl/ZPzgxa

14 J McKay, "How to use DevSecOps to smooth cloud deployment" URL: https://goo.gl/vqoh4L