Khóa luận tốt nghiệp An toàn thông tin: Bảo mật API Gateway cho nhiều bên trong môi trường Cloud-Native sử dụng học liên kết

Do đó trong khoá luận này,Nhóm nghiên cứu đề xuất giải pháp ứng dụng các mô hình học máy, đặc biệt là mô hình ngôn ngữ, kết hợp với học liên kết để tăng cường bảo mật cho API Gateway: e

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

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THONG TIN KHOA MẠNG MAY TÍNH VA TRUYEN THONG

LE HOANG PHUC - 20521763

NGUYEN TAN GIANG - 20521261

SECURE MULTI-TENANT API GATEWAY IN CLOUD-NATIVE

ENVIROMENTS USING FEDERATED LEARNING

CU NHAN NGANH AN TOAN THONG TIN

GIANG VIEN HUGNG DAN:

TS Nguyén Ngoc Tu

TP Hồ Chí Minh - 2024

LỜI CẢM ƠN

Lời đầu tiên, nhóm xin gửi lời cam ơn đến Ban giám hiệu Trường Đại học

Công nghệ thông tin - Dai học Quốc Gia Thành Phố Hồ Chí Minh đã tạo điều

kiện thuận lợi cho quá trính học tập và nghiên cứu của chúng em.

Hơn thế nữa, nhóm em xin chân thành cảm ơn thầy TS Nguyễn Ngọc Tự

- người hướng dẫn hết sức tận tâm, nhiệt tình, luôn luôn động viên, tạo mọi điều kiện tốt nhất cho chúng em khi thực hiện khoá luận tốt nghiệp tại Trường ĐHCNTT - DHQGHCM Những góp ý của thầy luôn là nguồn cảm hứng và

định hướng cho nhóm ngày càng hoàn thiện, phát triển hướng nghiên cứu ngày

một tốt hơn Trong quá trình thực hiện khoá luận, chúng em nhận ra bản thân còn nhiều hạn chế về kiến thức chuyên ngành và trình độ lý luận, dù đã cố hết

sức nhưng có lẽ là vẫn khó tránh khỏi những sai sót trong thời gian nghiên cứu

và báo cáo Vì vậy, em rất mong được quý thầy cô chỉ bảo, góp ý để chúng em

có thể hoàn thiện hơn về mặt kiến thức, cũng như tích lũy thêm nhiều kinh

nghiệm thực tiễn hữu ích cho tương lai sau này.

Cuối cùng, chúng em xin kính chúc quý thầy cô của trường Dại Học Công

Nghệ Thông Tin, quý thầy cô khoa Mang Máy Tính và Truyền Thông, và đặc

biệt là thầy Tự có được nhiều sức khỏe để có thể dốc lòng trong sự nghiệp "trồng

người”.

Lê Hoàng Phúc Nguyễn Tấn Giang

MỤC LỤC

LỜI CẢMƠN Q.2.

DANH MỤC TỪ TAM DICH

DANH MỤC CÁC HÌNH VẼ

DANH MỤC CÁC BẢNG BIEU

TÓM TẮT KHOÁ LUẬN 1

CHUONG 1 TONG QUAN DE TAI 2 11 Tên đề tài ee 2 12 Giới thiệu đề tai 6l Z7 =ã ÔỎốỐ „` 2 13 Tính ứng dụngf⁄Z2⁄ /£ - \` À 3

1.4 Những thách thức ẶẶẶ Q Q Q Q sa 4 1.5 Mục tiêu, đối tượng, và phạm vi nghiên cứu 4

1.5.1 Mục tiêu nghiên cứu Ặ 4

15.2 Đối tượng nghiên cứu - 4

15.3 Pham vi nghiên cứu so 5 1.6 Cau trúc khoá luận tốt nghiệp 5

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT 7 2.1 Tổng quan về Microservice ee 7 2.1.1 Kiến trúc Microservice 2 0.0.02 ee 7 2.1.2 Giao tiếp trong Microservice 05 11 2.1.3 Bảo mật trong Microservice 14

2.2 API Gateway 2.2.2 00000002 ee 17 2.2.1 Các tính năng pho biển của API Gateway 18

2.2.2 Lợi ích khi sử dụng API Gateway: 19

2.2.3 Nhược điểm khi sử dụng API Gateway 20

2.3 Các dạng tấn công tầng ứng dụng thường gặp: 21

2.3.1 Cross Site Scripting (XSS) 0.200.0 21

2.3.2 SQL Injection 02 0 0000004 23 2.3.3 Directory Traversal 0.0 0000004 24

2.3.5 Log Forging 0.00000 eee eee 26

2.3.6 Cookie Injection 004 27

2.3.7 Remote Code Ðxecute(RCE) 28

2.4 Học sâu trong Cloud Security 0-0 29

2.4.1 Tổng quan về Họcsâu 292.4.2 Ứng dụng Hoc sâu trong Cloud Security j1

3.2.3 Tài nguyên(Resource): co 42

3.2.4 Lớp bảo mat(Security Layer) 43

3.2.5 Máy chủ học liên két(Federated Server global model) 44 3.3 Luong hoạt động chính ccS 46

3.6 Tích hợp Federated Learning 59

CHƯƠNG 4 HIỆN THỰC VÀ ĐÁNH GIÁ 61

4.1 Xây dựng mô hình học sâu ỒẶ So 61

4.11 7 Mạng nữFrOn KH so 61

4.1.2 Giả lập môi trường học liên kết 62

4.2 Môi trường thực nghiệm 63

API Gateway

Federated Learning Deep Learning

Cloud Security Service Mesh

Internal Process

Service Endpoint

Resouce

Authetication Authorization Request Routing Session Management

Data Preprocessing Detection

Trung tâm ghi nhật ky Log Center

Phát hiện bất thường Anomaly Detection Module

Cơ sở dữ liệu mô hình cục bộ ~~ Local Model Database

Đào tào mô hình cục bộ Local Training

Máy chủ học liên kết toàn cầu Federated Server Global Model

Lỗ hồng di chuyển thư mục Directory traversal

DANH MỤC CÁC HÌNH VE

Hình 2.1 Kiến trúc Microservice c So ĩ

Hình 2.2 Giao tiếp đồng bộ trong Microservice 12

Hình 2.3 Giao tiếp bất đồng bộ trong Microservice 13

Hình 2.4 Phan quyền cấp cạnh trong Microservice 14

Hình 2.5 Phân quyền cấp dịch vụ trong Microservice 16

Hình 2.6 APIGateway gà vo 17 Hình 27 XSS Attack Q Q Q Q Q Q Q Q k vV 21 Hình 28 SQL Injection ch 23 Hình 2.9 Directory Traversal 00.0 24 Hình 2.10 Remote Code Execute 0.0 28 Hình 3.1 Hình anh Kiến trúc hệ thống bảo mật cho môi trường Mi-croservice @Z_ ZZỨA 71." | / ỐỐỐỐ5.b— s 37 Hình 32 Hinh anh API Gateway 38

Hình 33 Hình anh internal process - 40

Hình 3.4 Hình anh security layer 43

Hình 3.5 Hình anh API Gateway - 46

Hình 3.6 Hình anh Security layer 2 ee eee 48 Hình 3.7 Hình ảnh các lớp của mô hình đề xuất 1 56

Hình 3.8 Hình ảnh các lớp của mô hình đề xuat 2 57

Hình 3.9 Hình ảnh các lớp của mô hình đề xuất 3 58

Hình 3.10 Hình anh các lớp của mô hình đề xuất 4 59

Hình 4.1 Giá trị loss va chỉ số accucacy tia mô hình đề xuất 1 trong giai đOạn train 2 cu gà gà gà xa 67 Hình 4.2 Precision của mô hình đề xuất 1 trong giai đoạn train 68

Hình 4.3 Recall của mô hình đề xuất 1 trong giai đoạn train 68

Hình 4.4 F1Score của mô hình đề xuất 1 trong giai đoạn train

Hình 4.5 ROC AUC của mô hình đề xuất 1 trong giai đoạn train .

Hình 4.6 Confusion matrix mô hình đề xuất l

Hình 4.7 Giá trị loss va chỉ số accucacy tia mô hình đề xuất 2 trong giai đoạn fñYAII cà vo Hình 4.8 Precision của mô hình đề xuất 2 trong giai đoạn train .

Hình 4.9 Recall của mô hình đề xuất 2 trong giai đoạn train .

Hình 4.10 F1Score của mô hình đề xuất 2 trong giai đoạn train Hình 4.11 ROC AUC của mô hình đề xuất 2 trong giai đoạn train .

Hình 4.12 Confusion matrix mô hình đề xuất 2

Hình 4.13 Giá trị loss và chỉ số accucacy ủa mô hình đề xuất 3 trong giai đoạn train 4Ø ⁄⁄Z /Œ@ÓÔ %s

Hình 4.14 Precision của mô hình đề xuất 3 trong giai đoạn train .

Hình 4.15 Recall của mô hình đề xuất 3 trong giai đoạn train

Hình 4.16 F1Score của mô hình đề xuất 3 trong giai đoạn train Hình 4.17 ROC AUC của mô hình đề xuất 3 trong giai đoạn train .

Hình 4.18 Confusion matrix mô hình đề xuất 3

Hình 4.19 Giá trị loss và chỉ số accucacy ủa mô hình đề xuất 4 trong S0 0nni 0 a.aaT aẶ[ Hình 4.20 Precision của mô hình đề xuất 4 trong giai đoạn train

Hình 4.21 Recall của mô hình đề xuất 4 trong giai đoạn train .

Hình 4.22 F1Score của mô hình đề xuất 4 trong giai đoạn train Hình 4.23 ROC AUC của mô hình đề xuất 4 trong giai đoạn train .

Hình 4.24 Confusion matrix mô hình đề xuất 4

Hình 4.25 Confusion matrix của client 1 trước khi tổng hợp

Hình 4.26 Confusion matrix của client 1 sau khi tổng hợp

Hình 4.27 Confusion matrix của client 2 trước khi tổng hop

Hình 4.28 Confusion matrix của client 2 sau khi tổng hợp

69

69 70

71 72 72 73 73 74

7ð 76 76 77 77 78

Hình 4.29

Hình 4.30

Hình 4.31

Hình 4.32

Hình 4.33

Hình 4.34

Hình 4.35

Hình 4.36

Hình 4.37

Hình 4.38

Hình 4.39

Hình 4.40

Hình 4.41

Hình 4.42

Confusion matrix của client 3 trước khi tổng hợp 89

Confusion matrix của client 3 sau khi tổng hợp 90

Confusion matrix của client 1 trước khi tổng hợp 92

Confusion matrix của client 1 sau khi tổng hợp 93

Confusion matrix của client 2 trước khi tổng hợp 94

Confusion matrix của client 2 sau khi tổng hợp 95

Confusion matrix của client 3 trước khi tổng hợp 96

Confusion matrix của client 3 sau khi tổng hgp 97

Confusion matrix của client 1 trước khi tổng hợp 99

Confusion matrix của client 1 sau khi tổng hdp 100

Confusion matrix của client 2 trước khi tong hợp 101

Confusion matrix của client 2 sau khi tổng hgp 102

Confusion matrix của client 3 trước khi tổng hợp 103

Confusion matrix của client 3 sau khi tổng hgp 104

DANH MỤC CAC BANG BIEU

Bảng 4.2 Bang cấu hình máy tính sử dụng trong quá trình thực hiện

khóa lu€n 2 Q2 63

Bang 4.1 Bảng danh sách các module của API Gateway 63

Bang 4.3 So sánh kha năng phân loai 65

Bảng 4.4 So sánh khả năng phân loại với các nghiên cứu sin có 66

Bảng 4.5 So sánh thời gian phân loại với các nghiên cứu sẵn có 67

Bảng 46 Kết quả mô hình đề xuất 1 71

Bang 47 Kết quả mô hình đề xuất 2 75

Bang 4.8 Két quả mô hình đề xuất 3 79

Bang 4.9 Kết quả mô hình đề xuất 4 83

Bảng 4.10 Đánh giá khả năng phân loại của các mô hình tại clients trước khi tổng hợp - c cẶ Q Q Q Q Q s 84 Bang 4.11 Đánh giá khả năng phân loại của các mô hình tại clients sau khi fame hep “Oh 4 «„ư _ 84

Bang 4.12 Đánh giá khả năng phân loại của các mô hình tai clients

trước khi tổng hợp Q s 91

Bang 4.13 Đánh giá kha năng phân loại của các mô hình tai clients

sau khi tổng hợp - - TQ va 91

Bảng 4.14 Đánh giá khả năng phân loại của các mô hình tại clients

trước khi tổng hop c5 TQ va 98

Bảng 4.15 Dánh giá khả năng phân loại của các mô hình tai clients

sau khi tổng hợp ng v2 98

TÓM TẮT KHOÁ LUẬN

Kiến trúc Microservice đã và đang ngày càng được các nhà phát triển ứng

dụng ưa chuộng bởi khả năng mang lại sự linh hoạt, khả năng mở rộng và tốc

độ triển khai nhanh chóng cho các ứng dụng Tuy nhiên, sự phát triển bùng nổ

của microservice cũng kéo theo những thách thức mới về mặt bảo mật, đặc biệt

là trong bối cảnh các cuộc tấn công mạng ngày càng gia tăng và tỉnh vi.

Mặc dù đã xuất hiện nhiều biện pháp bảo mật cho microservice như API Gateway, Service Mesh nhưng chúng vẫn còn nhiều hạn chế nhất định, phức tạp trong vận hành, khả năng thích ứng hạn chế Đặc biệt trong đó giải pháp API Gateway còn tăng thêm bề mặt tấn công cho các tin tặc Do đó cần cấp thiết

tìm kiếm một giải pháp để giải quyết những vấn đề trên cũng như cung cấp khả

năng bảo mật cho hệ thống microservice.

Trong khoá luận này nhóm em hướng tới giải quyết vấn đề tăng cường bảo

mật trên API Gateway để bảo mật cho hệ thống microservice một cách tự độnghoá để đảm bảo duy trì sự vận hành của hệ thống microservice Đồng thời cóthể áp dụng giải pháp cho nhiều tổ chức một cách hiệu quả mà vẫn duy trì tínhriêng tư của các tổ chức Để làm được những điều trên nhóm ứng dụng các giải

pháp deep learning và học liên kết.

Thông qua khoá luận này chúng em mong muốn sẽ mang đến những cải tiến

đáng kể cho việc ứng dụng deep learning để bảo bảo mật cho API GateWay

cùng với học liên kết để tận dụng nguồn tài nguyên thông tin từ các tổ chức

khác nhau.

Chương 1 TONG QUAN ĐỀ TÀI

1.1 Tên đề tài

BẢO MAT API GATEWAY CHO NHIEU BEN TRONG MOI TRƯỜNG CLOUD-NATIVE SỬ DỤNG HOC LIÊN KET

(SECURE MULTI-TENANT API GATEWAY IN CLOUD-NATIVE

ENVIRO-MENTS USING FEDERATED LEARNING)

1.2 Giới thiệu dé tài

Microservice đang ngày càng khẳng định vị thé trong lĩnh vực phát triển phần

mềm nhờ mang lại nhiều lợi ích vượt trội:

e Tính linh hoạt: Khả năng dễ dàng điều chỉnh, mở rộng từng dịch vụ riêng

lẻ giúp ứng dụng thích ứng nhanh chóng với thay đổi

e Khả năng mở rộng: Hệ thống có thể mở rộng linh hoạt theo nhu cầu sử

dụng bằng cách nhân rộng các microservice cần thiết.

e Tính bảo mật: Thiết kế độc lập giúp giảm thiểu rủi ro lan truyền lỗi và

tấn công sang toàn hệ thống.

e Tính khả dụng: Việc cô lập và sửa lỗi microservice gặp vấn đề không ảnh

hưởng đến các phần khác, đảm bảo hệ thống luôn hoạt động ổn định

Sự trỗi dậy của Microservice cũng mang đến nhiều nguy cơ bảo mật như:

e Bề mặt tan công rộng: Số lượng microservice gia tăng dẫn đến việc tao

ra nhiều điểm tấn công tiềm an hơn cho kẻ xấu.

e Phức tạp trong quan lý: Việc theo dõi, quản lý và bảo mật nhiều

mi-croservice đòi hỏi chuyên môn cao và quy trình bài bản.

se Nguy cơ tấn công API Gateway: API Gateway là một giải pháp bảo

mật cho môi trường microservice đóng vai trò trung tâm, dé dàng trở thành

mục tiêu tấn công để xâm nhập hệ thống

Số liệu thống kê từ Salt cho thấy tần suất tấn công API tăng 400% , vượt

xa khả năng ngăn chặn của các giải pháp WAF va Gateway truyền thống Bao

mật API giờ đây trở thành vấn đề cấp bách cho các nhà phát triển và chuyên

gia bảo mật.

Do đó trong khoá luận này,Nhóm nghiên cứu đề xuất giải pháp ứng dụng các

mô hình học máy, đặc biệt là mô hình ngôn ngữ, kết hợp với học liên kết để

tăng cường bảo mật cho API Gateway:

e Mô hình ngôn ngữ: Phân tích và phát hiện các hành vi truy cập API bất

thường, tiềm ẩn nguy cơ tấn công.

e Học liên kết: Cho phép các tổ chức cùng nhau đào tạo mô hình học máy

mà không cần chia sẻ dữ liệu nhạy cảm, bảo vệ bí mật thông tin.

Sự kết hợp giữa Học máy và học liên kết mang đến giải pháp hiệu quả cho

bài toán bảo mat API Gateway trong kỷ nguyên Microservice Việc ứng dụng

các công nghệ tiên tiến này sẽ giúp doanh nghiệp bảo vệ hệ thống một cách toàn

diện, đảm bảo an toàn cho dữ liệu và ứng dụng của họ.

1.3 Tính ứng dụng

Kiến trúc microservice đang ngày càng sở nên phổ biến nên như cầu tăng

cường bảo vệ cho api gateway ngày càng cấp bách Đặc biệt trong bối cảnh các cuộc tấn công mới đang ngày càng tăng trong thực tế Nghiên cứu ứng dụng

dụng mô hình học máy trong API security sẽ giúp chống lại các cuộc tấn công

này một cách hiệu quả.

1.4 Những thách thức

Mặc dù đã xuất hiện nhiều giải pháp cho cho API Gateway nhưng các giải

pháp này còn nhiều khuyết điểm như:

e Các mô hình hiện nay mặc dù cho kết quả khá tốt nhưng khi áp dụng thực

tế lại không cho kết quả như mong đợi.

e Chi phí đào tạo một mô hình từ đầu quá tốn kém.

e Chưa tận dùng được nguồn tài nguyên phan tán.

e Khả năng cải tiến: hầu hết các giải pháp hiện tại điều rất khó để nâng cấp.

1.5 Mục tiêu, đối tượng, và phạm vi nghiên cứu

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

e Xây dựng, triển khai hệ thống API Gateway tích hợp mô hình máy học để

phòng chống các cuộc tấn công tần ứng dụng.

e Tích hợp kỹ thuật Federated để giảm thiểu tải nguyên đào tạo và tận dụng

nguồn tài nguyên phân tán.

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

e Microservice Security.

e Các loại tấn công tang ứng dung.

e Các mô hình máy học

1.5.3 Pham vi nghién cứu

e API Gateway Security.

e Các mô hình xử ly ngôn ngữ tu nhiên.

e Federated trong microservice.

1.6 Cau trúc khoá luận tốt nghiệp

Khóa luận này có cấu trúc chính như sau:

e Chương 1 Tổng quan đề tài

Chương 1 sẽ giới thiệu cái nhìn tổng quan về đề tài nghiên cứu, các công trình

liên quan, mục tiêu nghiên cứu, đối tượng nghiên cứu và phạm vi nghiên cứu.

e Chương 2 Cơ cổ lý thuyết.

Chương 2 sẽ mô tả kiến thức cơ bản về kiến trúc Mieroservice, phương thức giao tiếp giữa các Microservice, các biện phòng thủ cho Microservice hiện nay,

các dạng tấn công tầng ứng dụng, giới thiệu các mô hình học sâu hiện nay.

e Chương 3 Mô hình đề xuất.

Chương 3 mô tả chi tiết về Hệ thống API Gateway và các module của nó mà nhóm đề xuất, đặc biệt tập trung vào module Deep Learning phát hiện tấn công

và tác dụng của sự tích hợp học liên kết để tăng khả năng phát hiện tấn công

e Chương 4 Thực nghiệm và đánh giá.

Chương 4 trình bày quá xây dựng và thực nghiệm hệ thống, các kịch bản thực nghiệm của nhóm và phương thức đánh giá kết quả.

e Chương 5 Kết luận

Chương 5 tổng kết quá trình nghiên cứu, xây dựng hệ thống và đề xuất cáchướng triển trong tương lai

Chương 2 CƠ SỞ LÝ THUYET

2.1 Tông quan về Microservice

2.1.1 Kién trúc Microservice

Kiến trúc Microservice(MFA), hay còn gọi là Microservice, là một thiết kế

kiến trúc phần mềm dựa trên dịch vụ, trong đó ứng dụng phân tách thành

nhiều dịch vụ nhỏ, liên kết với nhau Mỗi dịch vụ xử lý một chức năng cụ thể

của ứng dụng như đăng ký người dùng mới hoặc truy vấn cơ sở dữ liệu Trong kiến trúc Microservice, mỗi dịch vụ là một giao diện được xác định rõ ràng, hoạt

động cùng với các dịch vụ khác nhưng có thể được phát triển, kiểm thử, mở

rộng và triển khai một cách độc lập nhờ thiết kế polylithic của ứng dụng Giao

diện này có thể được gọi khi có lời gọi API RESTful hoặc RPC từ người dùng

Microservices

A | @ - SỐ T

API

Client —> Gateway

2.1.1.1 Đặc điểm kiến trúc Microservice

e Tách rời: Các dịch vụ trong một hệ thống phần lớn được tách rời Vì vậy,

toàn bộ ứng dụng có thể dễ dàng được xây dựng, thay đổi và thu nhỏ

e Thành phần hoá: mỗi dịch vụ được coi là các thành phần độc lập có thể

dễ dàng thay thế và nâng cấp.

e Phù hợp với doanh nghiệp: các lập trình viên hay các nhóm có thể làm

việc độc lập với nhau trong quá trình phát triển

e Khả năng tự trị: Khả năng phân tán và phân cấp tạo ra tính linh hoạt

và chống lại sự tập trung quyền lực.

e Cơ sở mã riêng biệt: không có mẫu chuẩn hóa hoặc bất kỳ mẫu công

nghệ nào Được tự do lựa chọn các công cụ hữu ích tốt nhất để có thể giải

quyết van dé.

e Phân phối liên tục: Cho phép phát hành phan mềm thường xuyên, liên

tục.

2.1.1.2 Lợi ích của kiến trúc Microservice

e Khả năng nhanh nhẹn: Do các Microservice được triển khai độc lập, việc

quản lý sửa lỗi và phát hành tính năng trở nên dé dàng hơn Bạn có thécập nhật một dịch vụ mà không cần triển khai lại toàn bộ ứng dụng, và cóthể hoàn nguyên cập nhật nếu có vấn đề gì xảy ra Trong nhiều ứng dụng

truyền thống, nếu phát hiện lỗi trong một phần của ứng dụng, nó có thể

chặn toàn bộ quá trình phát hành Các tính năng mới có thể bị trì hoãnchờ đợi việc sửa lỗi được tích hợp, kiểm thử và xuất bản

e Tập trung theo nhóm nhỏ: Một Microservice nên đủ nhỏ để một nhóm

tính năng duy nhất có thể xây dựng, kiểm thử và triển khai nó Nhóm nhỏthúc day tính linh hoạt cao hơn Các nhóm lớn thường kém năng suất hơn

vì giao tiếp chậm hơn, chi phí quản lý tăng lên và tính linh hoạt giảm.

e Hệ thống mã nhỏ: Trong một ứng dung monolithic, theo thời gian, các

phụ thuộc mã có xu hướng trở nên rối ram Thêm một tính năng mới đòi

8

hỏi phải chạm vào mã ở nhiều vị trí Bằng cách không chia sẻ code hoặc kho

lưu trữ dữ liệu, kiến trúc Microservice giảm thiểu các phụ thuộc và giúp

việc thêm các tính năng mới dễ dàng hơn.

e Kết hợp nhiều công nghệ: Các nhóm có thể chọn công nghệ phù hợp

nhất với dịch vụ của họ, sử dụng kết hợp các ngăn xếp công nghệ khi cần thiết.

e Tách biệt lỗi: Nếu một Microservice riêng lẻ không khả dụng, nó sẽ không

làm gián đoạn toàn bộ ứng dụng, miễn là bất kỳ Microservice thượng nguồn

nào được thiết kế để xử lý lỗi chính xác Ví dụ, bạn có thể triển khai mẫuNgắt mạch (Circuit Breaker) hoặc bạn có thể thiết kế giải pháp của minh

để các Microservice giao tiếp với nhau bằng cách sử dụng các mẫu nhắn tin

bất đồng bộ.

e Khả năng mở rộng: Các dịch vụ có thể được mở rộng độc lập, cho phép

bạn mở rộng các hệ thống phụ yêu cầu nhiều tài nguyên hơn, mà không cần mở rộng toàn bộ ứng dụng Bằng cách sử dụng một bộ dàn nhạc như

Kubernetes, bạn có thé đóng gói mật độ dịch vụ cao hơn trên một host duy

nhất, cho phép sử dụng tài nguyên hiệu quả hơn.

e Tách biệt dữ liệu: Việc cập nhật lược đồ trở nên dễ dàng hơn nhiều

vì chỉ có một Microservice duy nhất bị ảnh hưởng Trong một ứng dung

monolithic, việc cập nhật lược đồ có thể trở nên rất khó khăn vì các phankhác nhau của ứng dụng đều có thể chạm vào cùng một dit liệu, khiến bất

kỳ thay đổi nào đối với lược đồ đều trở nên rủi ro

2.1.1.8 Các thách thúc của Microservice

e Phức tap: Ứng dụng Microservice có nhiều thành phần hoạt động hơn so

với ứng dụng monolithic tương đương Mỗi dịch vụ riêng lẻ đơn giản hơn, nhưng toàn bộ hệ thống lại phức tạp hơn.

9

e Phát triển và kiểm thử: Viết một dịch vụ nhỏ phụ thuộc vào các dich

vụ phụ thuộc khác đòi hỏi cách tiếp cận khác so với việc viết một ứng dụng monolithic hoặc theo lớp truyền thống Các công cụ hiện có không phải lúc

nào cũng được thiết kế để hoạt động với các phụ thuộc dịch vu Refactoring

vượt qua các ranh giới dịch vụ có thể khó khăn Kiểm thử các phụ thuộcdịch vụ cũng là một thách thức, đặc biệt là khi ứng dụng phát triển nhanh

chóng.

e Thiếu sự kiểm soát: Cách tiếp cận phân cấp để xây dựng Microservice

có những ưu điểm, nhưng cũng có thể dẫn đến vấn đề Bạn có thể kết thúc

với quá nhiều ngôn ngữ và framework khác nhau khiến ứng dụng khó bảo

trì Sẽ hữu ích nếu đặt ra một số tiêu chuẩn cho toàn bộ dự án, mà không

hạn chế quá nhiều tính linh hoạt của các nhóm Điều này đặc biệt áp dụng

cho các chức năng cắt ngang như ghi nhật ký.

e Tắc nghẽn mạng và độ trễ: Việc sử dụng nhiều dịch vụ nhỏ, chỉ tiết

có thể dẫn đến nhiều giao tiếp giữa các dịch vụ hơn Ngoài ra, nếu chuỗiphụ thuộc dịch vụ quá dài (dịch vụ A gọi B, B gọi C ), độ trễ bổ sung

có thể trở thành vấn đề Bạn cần thiết kế API cẩn thận Tránh các API

"nói nhiều", suy nghĩ về định dạng serialization và tìm kiếm các vị trí để

sử dụng các mẫu giao tiếp không đồng bộ như cân bằng tải dựa trên hàng

đợi.

e Tính toàn vẹn dữ liệu: Với mỗi Microservice chịu trách nhiệm cho sự tồn

tại dit liệu của riêng nó Do đó, tính nhất quán của dữ liệu có thể là một

thách thức Sử dụng tính nhất quán cuối cùng (eventual consistency) bất

cứ khi nào có thể

e Kha năng quản lý: Dé thành công với Microservice, đòi hỏi một văn hóa

DevOps chuyên nghiệp Ghi nhật ký tương quan giữa các dịch vụ có thể

10

là một thách thức Thông thường, nhật ký phải tương quan nhiều cuộc gọi dịch vụ cho một hoạt động của người dùng duy nhất.

e Xung đột giữa các bản cập nhật: Cập nhật cho một dịch vụ không

được làm gián đoạn các dịch vụ phụ thuộc vào nó Nhiều dịch vụ có thểđược cập nhật bất kỳ lúc nào, vì vậy nếu không thiết kế cẩn thận, bạn cóthể gặp vấn đề về khả năng tương thích ngược hoặc hướng tới tương lai

2.1.2 Giao tiếp trong Microservice

Trong các ứng dung monolithic trong quá khứ, giao tiếp giữa các thành phan được gọi là giao tiếp giữa các tiến trình (inter-process communication) - nhưng

điều cần lưu ý là tất cả các tiến trình này thực chất chỉ là một tiến trình duy nhất Các thành phần trong ứng dung monolithic gọi lan nhau bằng cách sử dụng các gọi phương thức (method calls).NÑgười lập trình chỉ cần tạo lớp và gọi

phương thức bên trong module mục tiêu Tất cả các thành phần này đều chạy

trong cùng một tiến trình.Ưu điểm của cách giao tiếp này là rất đơn giản Tuy

nhiên, mặt trái của nó là các thành phần trở nên rất phụ thuộc lẫn nhau, gây khó khăn trong việc tách biệt và mở rộng độc lập từng thành phần.

Một trong các thách thức lớn nhất khi chuyển đổi từ ứng dung monolithicsang kiến trúc Microservice là sự thay đổi cơ chế giao tiếp Điều này là do các

Microservice được phân tán va chúng giao tiếp với nhau thông qua giao tiếp giữa các dịch vụ trên lớp mạng Mỗi Microservice có phiên bản và tiến trình riêng biệt Do đó, các dịch vụ phải tương tác với nhau bằng các giao thức giao tiếp

giữa các dịch vụ như HTTP, gRPC hoặc giao thức message broker AMQP.

Vì Microservice là một cấu trúc phức tap được phát triển và triển khai độc

lập thành các dịch vụ riêng lẻ, nên chúng ta cần cần thận khi xem xét các loại

hình giao tiếp và quản lý chúng trong giai đoạn thiết kế.

Trước khi thiết kế giao tiếp Microservice, chúng ta cần hiểu về các kiểu giao

11

tiếp, chúng có thể được phân loại theo hai loại Bước đầu tiên là xác định giao

thức giao tiếp là đồng bộ (synchronous) hay không đồng bộ (asynchronous).

2.1.2.1 Giao tiếp đồng bộ

Request

MicroService A Waiting MicroService B

Response

Hình 2.2: Giao tiếp đồng bộ trong Microservice

Về cơ bản, chúng ta có thể nói rằng giao tiếp đồng bộ sử dụng giao thứcHTTP hoặc gRPC để trả về phản hồi đồng bộ Trong giao tiếp đồng bộ, phíclient sẽ gửi yêu cầu sử dụng giao thức HTTP/gRPC để để gửi yêu cầu đên dịch

vụ và chờ đợi phản hồi Điều này có nghĩa là phía client sẽ tạm ngưng luồng van hành của phiên làm việc này cho đến khi nhân được phản hồi từ dịch vụ Client

sẽ tiếp tục nhiệm vụ chỉ khi nhận được phản hồi từ phía dịch vụ.

12

2.1.2.2 Giao tiếp bat đồng bộ

Hình 2.3: Giao tiếp bat dong bộ trong Microservice

Trong giao tiếp bất đồng bộ, client gửi yêu cầu nhưng không đợi phản hồi từ dịch vụ Điều cốt yếu ở đây là client không nên chiếm một luồng trong khi chờ

đợi phản hồi.Giao thức phổ biến nhất cho giao tiếp bất đồng bộ này là AMQP

(Advanced Message Queuing Protocol) Khi sử dụng giao thức AMQP, client gửi

message thông qua các hệ thống message broker Bên gửi message (producer) thường không đợi phản hồi Message này được consumer (bên nhận) xử lý theo cách bất đồng bộ, và không ai phải đột ngột chờ đợi phản hồi.

Giao tiếp bất đồng bộ cũng được chia thành 2 loại theo cách triển khai Hệthống bất đồng bộ có thể được triển khai theo chế độ one-to-one (queue) hoặc

one-to-many (topic).

Trong triển khai một-đến-một (queue), chỉ có một bên gửi và một bên nhận.

Nhưng triển khai một-đến-nhiều (topie) có nhiều bên nhận Mỗi yêu cầu có thể

được xử lý bởi nhiều bên nhận Giao tiếp một-đến-nhiều (topic) phải là bất đồng

bộ.

13

2.1.3 Bao mật trong Microservice

Kiến trúc microservice đang ngày càng được sử dung để thiết kế và triển khai

các hệ thống ứng dụng trên cả cơ sở hạ tầng đám mây và tại địa điểm vật lý đối

với các ứng dụng và dịch vụ quy mô lớn Cần giải quyết nhiều thách thức bảo

mật trong các giai đoạn thiết kế và triển khai ứng dụng Các yêu cầu bảo mật

cơ bản cần được giải quyết trong giai đoạn thiết kế là xác thực và ủy quyền.Do

đó cần hiểu và sử dụng đúng các mẫu kiến trúc hiện có để thực hiện xác thực

và ủy quyền trong các hệ thống dựa trên Microservice.

© Order & Message Broker

Api GatewayKub

© Product

Hình 2.4: Phân quyén cap canh trong Microservice

Trong trường hợp đơn giản nhất, việc ủy quyền(authorization) có thé chỉ xảy

ra ở cấp cạnh (API Gateway) API gateway có thể được tận dụng để tập trung

thực thi ủy quyền cho tất cả các microservice phía sau, loại bỏ nhu cầu cung cấp

xác thực và kiểm soát truy cập cho từng dịch vụ riêng lẻ Trong những trườnghợp như vậy, NIST khuyến nghị thực hiện các biện pháp kiểm soát giảm nhẹnhư xác thực tương hỗ để ngăn chặn các kết nối trực tiếp, ẩn danh đến các dịch

14

vụ nội bộ (bỏ qua API gateway).

Cần lưu ý rằng việc kiểm soát truy cập tại cấp cạnh (Edge-level) có những

hạn chế sau:

e Day tất cả các quyết định kiểm soát quyền cho API Gateway có thể nhanh

chóng trở nên khó quản lý trong các kiến trúc phức tạp với nhiều vai trò và

quy tắc kiểm soát truy cập

e API GateWay có thể trở thành điểm ra quyết định duy nhất, vi phạm

nguyên tắc "phòng thủ chiều sâu"(defense in depth).

e API Gateway thường thuộc sở hữu của nhóm vận hành hệ thống, do các các

nhóm phát triển ứng dụng không thể trực tiếp thay đổi kiểm soát quyền,làm chậm tốc độ phát triển do chi phí trao đổi giữa các nhóm

15

2.1.3.2 Phân quyén cấp dich vu

Policy Administration | | Policy Policy Information |

Point (PAP) 4 repositorv | | Point (PIP)

LY g” Ì ae

| =

Attribute repository

Hinh 2.5: Phan quyén cap dich vu trong Microservice

Cung cấp cho từng microservice nhiều quyền kiểm soát hơn để thực thi cácchính sách kiểm soát truy cập Để thảo luận thêm, chúng ta sẽ sử dụng các

thuật ngữ và định nghĩa theo NIST SP 800-162 Các thành phần chức năng của

hệ thống kiểm soát truy cập có thể được phân loại như sau:

e Điểm quản trị chính sách - Policy Administration Point (PAP):

Cung cấp giao diện người dùng để tạo, quản lý, kiểm tra và gỡ rối các quytắc kiểm soát truy cập

e Điểm quyết định chính sách - Policy Decision Point (PDP): Đánh

giá các chính sách kiểm soát truy cập phù hợp và đưa ra quyết định cho

phép hoặc từ chối truy cập dựa trên các thuộc tính liên quan.

16

e Điểm thực thi chính sách - Policy Enforcement Point (PEP): Thực

thi các quyết định của PDP PEP nhận yêu cầu truy cập từ một chủ thể(subject) tới một đối tượng được bảo vệ (object), sau đó kiểm tra với PDP

để xác nhận tính hợp lệ của truy cập Cuối cùng, PEP cho phép hoặc từ

chối truy cập dựa trên quyết định của PDP.

e Điểm thông tin chính sách - Policy Information Point (PIP): Là

nguồn cung cấp các thuộc tính cần thiết để đánh giá chính sách kiểm soát

truy cập Các thuộc tính này có thể liên quan đến chủ thể (subject), đối

tượng (object), môi trường (environment), hoặc các yếu tố khác có liên quan

đến yêu cầu truy cập PIP cung cấp thông tin này cho PDP dé PDP có thể

API Gateway là thành phần bao mat then chốt trong thiết kế hệ thống, đặc biệt là trong kiến trúc Microservice và các ứng dung web hiện đại Nó hoạt

động như một reverse proxy, nằm giữa các ứng dụng khách va các microservice

back-end Nó cung cấp một điểm vào duy nhất và an đi sự phức tap của cácdịch vụ ở phía back-end Cổng API xử lý việc định tuyến các yêu cầu đến cácdịch vụ phù hợp, tổng hợp dữ liệu từ nhiều dịch vụ và áp dụng các chính sách

thống nhất trên tất cả các Microservice.

2.2.1 Các tính năng phổ biển của API Gateway

e Định tuyến lưu lượng: API Gateway có thể quản lý và kiểm soát lưu

lượng giữa các dịch vụ Nó có thể thực hiện cân bằng tải(load balancing),

phân tích lưu lượng(traffic splitting) và hoạt động như một reverse proxy hoặc forward proxy).

e Giới hạn tốc độ(Rate limiting): API Gateway có thể giới han các yêu

cầu dựa trên địa chỉ IP hoặc HTTP header Do đó API Gateway có thẻ giúp các dịch vự tránh bị quá tải và ngăn chặn các cuộc tấn công độc hại

như DOS Rate limitting cũng giúp các nhà cung cấp API triển khai các

chiến lược kinh doanh khác nhau.

e Xử lý lỗi: API gateway có thể xử lý và chuẩn hoá các phản hồi lỗi nếu yêu

cầu API không thành công do các sự cố như lỗi máy chủ nội bộ, đầu vào

không hợp lệ, lỗi xác thực Các mã trạng thái (status code) của lỗi có thểđược tuỳ chỉnh cho client thông qua API Gateway, giúp client hiểu và xử

lý lỗi dễ dàng hơn.

e Ngắt mạch:API Gateway có thể triển khai các mẫu ngắt mạch(circuit

breaker) giúp các dịch vụ phía sau tránh bị quá tải với các yêu cầu khi cá

dịch vụ này đang bị lỗi Tính năng này sẽ ngừng chuyển tiếp các yêu cầu

18

tới dịch vụ dang gặp sự cố va trả về mã lỗi thích hợp Do đó giúp ngăn chặn lỗi lan sang các dịch vụ khác trong hệ thống.

e Khả năng quan sát: API Gateway cung cấp tính năng ghi nhật ký, giám

sát và phân tích để quan sát các hoạt động đã diễn ra Điều này giúp các

nhóm vận hành hiểu rõ hiệu suất và hành vi của hệ thống.

e Cơ chế bộ nhớ dém(Caching): API Gateway có thể lưu trữ bộ đệm và

phục vụ các phản hồi được thực hiện từ các yêu cầu trước đó cho client.

Nếu tính năng lưu trữ đệm API được bật, API Gateway sẽ kiểm tra các yêucầu với các phản hồi được lưu trong bộ nhớ đệm và chuyển tiếp một phản

hồi nếu nó tồn tại, do đó không cần thực hiện yêu cầu mới đến dịch vụ nội

bộ Điều này giúp giảm đáng kể tải trên các dịch vụ và độ trễ phản hồi

e Chấm dứt SSL: API Gateway có thể thực hiện chấm dựt SSL, bao gồm

giải mã SSL từ clients thay cho các dịch vu phía sau Dùng chấm dứt

SSL(SSL termination) có thể giúp các dịch vụ phía sau chỉ tập trung vào

tác vụ chính của chúng.

2.2.2 Lợi ích khi sử dung API Gateway:

e Che dấu được cấu trúc của hệ thống Microservice với bên ngoài: Clients sẽ

tương tác với hệ thống thông qua API Gateway chứ không gọi một service

cụ thể nào, các endpoints của các services sẽ chỉ được gọi nội bộ giữa các

services hoặc từ API Gateway Do đó phía client sẽ không biết được các

services phía backend được phân chia như nào.

e Phần code phía frontend sẽ gọn gàng hơn: Do chỉ việc gọi đến api gateway

nên phần code frontend sẽ gọn gàng hơn sơ với việc phải tracking nhiều

enpoint trên từng dịch vụ một.

e Dé dàng theo dõi và quan lý traffic: Hầu hết các API Gateway đều sẽ đi

19

kèm tinh năng theo dõi va quản lý lượng traffic bằng GUI thông qua các

API của hệ thông Gateway.

e Requests caching và cân bằng tải: API Gateway sẽ kiêm luôn vai trò load

balancer của hệ thống, requests sẽ không được gửi trực tiếp đến backend nên sẽ giảm thiểu rủi ro hệ thống bị quá tải.

e Thêm một lớp bảo mật nữa cho hệ thống: API Gateway giúp ngăn chặn các

cuộc tấn công bằng cách thêm một lớp bảo vệ các loại tấn công như ddos,

sql injections.

e Thay thé authetication services: API Gateway thường cung cấp nhiều cơ

chế xác thực, chúng ta có thé sử dung nó để xác thực người dùng, tiết kiệm

thời gian và làm hệ thống đơn giản hơn.

2.2.3 Nhược điểm khi sử dung API Gateway

e Performance bottlenecks:Performance bottlenecks: API Gateway có thé

trở thành một điểm yếu đơn lẻ hoặc một nút thắt cổ chai về hiệu năng, đặc

biệt là khi xử lý một lượng lớn yêu cầu Cần thiết kế và cấu hình can thận

để đảm bảo chúng có thể xử lý được tải

e Increased latency: Việc giới thiệu API Gateway có thể làm tăng thêm

độ trễ cho các yêu cầu, đặc biệt nếu nó cần thực hiện định tuyến, xác thực hoặc các hoạt động phức tạp khác Tối ưu hóa cấu hình của API Gateway

và sử dụng bộ nhớ cache có thể giúp giảm thiểu vấn đề này

e Complexity: Quan lý và cấu hình API Gateway có thể phức tạp, đặc biệt

trong các môi trường có nhiều dịch vụ và điểm cuối Tài liệu thích hợp vàcác công cụ tự động hóa có thể giúp giảm thiểu độ phức tạp này

e Security risks: Cấu hình sai API Gateway có thể dẫn đến lỗ hổng bảo

mật, chang hạn như xác thực, ủy quyền không phù hợp hoặc tiết lộ thông

20

tin nhạy cảm Kiểm tra bảo mật thường xuyên và cập nhật là cần thiết đểgiảm thiểu những rủi ro này.

e Scalability challenges: Mở rộng quy mô API Gateway có thể là một thách

thức, đặc biệt trong các môi trường động với lưu lượng truy cập dao động.

Cân bằng tải và các chiến lược mở rộng ngang là cần thiết để đảm bảo khả

năng mở rộng.

e Monitoring and logging: Giám sát và ghi nhật ký hiệu năng và hoạt

động của API Gateway có thể phức tạp, đặc biệt khi xử lý một lượng lớn

yêu cầu và dịch vụ Các công cụ giám sát và ghi nhật ký phù hợp là rất

quan trọng để duy trì khả năng hiển thị hoạt động của API Gateway

2.3 Các dạng tấn công tầng ứng dụng thường gặp:

2.3.1 Cross Site Scripting (XSS)

https://insecure-website.com/comment?message=<script src=https://evil-user.net/badscript.js></script>

21

Cross-site scripting (còn được gọi là XSS) là một lỗ hổng ứng dụng web cho

phép kẻ tấn công xâm nhập vào các tương tác mà người dùng có với ứng dụng

có lỗ hồng Lỗ hổng này cho phép kẻ tấn công vượt qua same origin policy, được

thiết kế để phân tách các trang web khác nhau với nhau Thường thì lỗ hong

XSS cho phép kẻ tấn công giả mạo như là một người dùng nạn nhân, thực hiện

bất kỳ hành động nào người dùng đó có thể thực hiện, và truy cập vào bất kỳ

dữ liệu của người dùng đó Nếu người dùng nạn nhân có quyền truy cập đặc

biệt trong ứng dụng, thì kẻ tấn công có thể kiểm soát hoàn toàn toàn bộ chức

năng và dữ liệu của ứng dụng.

Cross-site scripting hoạt động bằng cách điều khiển một trang web có lỗ hong

để trả về mã JavaScript độc hại đến người dùng Khi mã độc hại được thực thitrong trình duyệt của nạn nhân, kẻ tấn công có thể hoàn toàn chiếm quyền kiểm

soát tương tác của họ với ứng dụng.

Thông thường XSS được chia làm 3 loại chính :

e Reflected Cross Site Scripting: là dang tấn công XSS đơn giản nhất.

Nó xảy ra khi một ứng dụng nhận dữ liệu trong yêu cầu HTTP (ví dụ như

từ ô tìm kiếm, form nhập liệu) và không kiểm tra an toàn trước khi đưa

dữ liệu đó trực tiếp vào phản hồi trả về cho người dùng Điều này tạo ra lỗ

hồng cho kẻ tấn công có thể đưa mã độc hại của chúng vào cùng với dữ liệu

hợp lệ, và mã độc hại này sẽ được trình duyệt của nạn nhân thực thi khi

đọc phan hồi từ ứng dụng Nếu người dùng truy cập vào URL do kẻ tan

công tạo ra, thì mã nguồn độc hại của kẻ tấn công sẽ được thực thi trong

trình duyệt của người dùng, trong chính ngữ của phiên làm việc của người

dùng đó với ứng dụng Lúc này, mã độc hại có thể thực hiện bất kỳ hành

động nào và truy xuất bất kỳ dữ liệu nào mà người dùng được phép truy

cập.

e Stored Cross Site Scripting: xuất hiện khi ứng dụng nhận dữ liệu từ

22

một nguồn không đán tin cậy và không hề có cơ chế kiểm tra đầu vào Sau

này ứng dụng dùng chính dữ liệu chưa được kiểm tra này để hiển thị trong

các phản hồi HTTP trả về cho người dùng.

e Dom-Based Cross Site Scripting: còn được gọi là Dom-based XSS, xảy

ra khi JavaScript lấy dữ liệu từ một nguồn do kẻ tấn công kiểm soát, changhạn như URL, và truyền dữ liệu đó đến một điểm nhạy (sink) hỗ trợ thựcthi mã động, chang hạn như eval() hoặc innerHTML Điều này cho phép

kẻ tấn công thực thi mã JavaScript độc hại, thường cho phép chúng chiếm

đoạt tài khoản của người dùng khác.

2.3.2 SQL Injection

' UNION SELECT username, password FROM

users SELECT name, description FROM products WHERE category

= 'Gifts' UNION SELECT username, password FROM

users-—-[IIIIIIIIIIII IIIIIIIIIIIII [IIIIIIIIIIII

Hình 2.8: SQL Injection

2

SQL Injection (SQLI) là một lỗ hong bảo mật web cho phép kẻ tấn công can

thiệp vào các truy vấn mà ứng dụng gửi tới cơ sở dữ liệu của nó Điều này có

23

thể cho phép kẻ tấn công xem dữ liệu mà thông thường họ không thể truy xuất

được Dữ liệu này có thể bao gồm:

e Dữ liệu thuộc về người dùng khác.

e Bất kỳ dữ liệu nào khác mà ứng dụng có thể truy cập.

Trong nhiều trường hợp, kẻ tấn công có thể sửa đổi hoặc xóa dữ liệu này,gây ra những thay đổi lâu dài cho nội dung hoặc hành vi của ứng dụng

Trong một số tình huống, kẻ tan công có thể leo thang lỗ hong SQL injection

để xâm nhập vào máy chủ nền tảng hoặc cơ sở hạ tầng back-end khác Ñó cũng

có thể cho phép chúng thực hiện các cuộc tấn công từ chối dịch vụ (DoS)

2.8.8 Directory Traversal

xo

< ¢ Noadimage?filename= / /./etc/passwd]

«© IeadImage?filename=gift.png

games: x-5-60-games-/usr/games-/bin/sh man-:x-:6-12-man-:/var/cache/man:/bin/sh 1p:x:T:7:1p: /var/spool/1pd: /bin/sh

mail-x-8-:8-:mail-:/var/mail:/bin/sh

wucp:x:10:10:ưucp: /var/spool/uucp: /bin/ah

'www-data -x: 33 - 33 -www-data : /wax/www: /bin/sh

ackun:x: 34 : 34-backup: /var/backups: /“hin/zh

Hành 2.9: Directory Traversal

3

Còn gọi là Path Traversal, còn được gọi là di chuyển thu mục, là một lỗ hổng

bảo mật cho phép kẻ tấn công đọc các file tùy ý trên máy chủ đang chạy ứng

24

dụng Điều này có thể bao gồm:

e Mã nguồn và dữ liệu ứng dụng: Kẻ tấn công có thể truy cập và đánh cắp mã

nguồn của ứng dụng, giúp chúng hiểu cách thức hoạt động của ứng dụng vàtiềm ẩn các lỗ hồng khác Dữ liệu ứng dụng bị lộ có thể chứa thông tin nhạy

cảm của người dùng hoặc thông tin quan trọng khác của doanh nghiệp.

e Thông tin xác thực cho các hệ thống back-end: Nếu ứng dụng lưu trữ thông

tin đăng nhập hoặc khóa API cho các hệ thống back-end (hệ thống cơ sở

dữ liệu, dịch vụ khác) trong các file, kẻ tấn công có thể đánh cắp thông tinnày và sử dụng nó để truy cập trái phép vào các hệ thống đó

e Các file nhạy cảm của hệ điều hành: Kẻ tấn công có thé đọc các file cấu hình

nhạy cảm của hệ điều hành, chang hạn như file /ete/passwd chứa thong tin

tài khoản người dùng, hoặc các file nhật ký hệ thống chứa thông tin nhạy cảm về hoạt động của máy chủ.

Trong một số trường hợp nghiêm trọng hơn, kẻ tấn công thậm chí có thể ghi

vào các file tùy ý trên máy chủ Điều này cho phép chúng:

e Sửa đổi dữ liệu ứng dụng: Kẻ tấn công có thể thay đổi nội dung của các file

dữ liệu ứng dụng, dẫn đến việc ứng dụng hoạt động không chính xác hoặc

bị can thiệp.

e Sửa đổi hành vi ứng dụng: Kẻ tấn công có thể thay đổi mã nguồn của ứng

dụng, dẫn đến việc ứng dụng hoạt động theo cách thức độc hại, chang han

như đánh cắp dữ liệu người dùng hoặc thực hiện các cuộc tấn công khác.

2.3.4 Log4d

Lỗi tồn tại ở Log4J, mot framework mã nguồn mở phổ biến trên Apache,thường được dùng để ghi nhật ký các hoạt động trong ứng dụng Lỗi này dễ

25

dàng bị lợi dụng để kiểm soát từ xa Kẻ tấn công sẽ phải gửi một chuỗi mã độchại dến hệ thống để rồi thông được độc hai này được ghi lại bằng Logj(phiên

bản 2.0 đến 2.14.1) Việc khai thác cho phép kẻ tấn công tải mã Java tuỳ ý trên

máy chủ, cho phép chúng quyền kiểm soát hệ thống mục tiêu

2.8.5 Log Forging

Là trường hợp đơn giản nhất của Log Injection, kẻ tấn công có thể chèn các

mục giả mạo vào file nhật ký bằng cách cung cấp cho ứng dụng đầu vào chứa

các ký tự phù hợp Nếu file nhật ký được xử lý tự động, kẻ tấn công có thể làm

cho file này không sử dụng được bằng cách làm hỏng định dạng của file hoặc

chèn các ký tự không mong đợi Một cuộc tấn công tỉnh vi hơn có thể liên quan

đến việc làm sai lệch các thống kê của file nhật ký Các file nhật ký bị làm giả,

sai sót có thể được sử dụng để che giấu dấu vết của kẻ tấn công hoặc thậm chí

đổ lỗi cho bên khác thực hiện hành vi độc hại.Các tác động kẻ tấn công có thể

gây Ta:

e Làm hỏng định dạng file nhật ký: Kẻ tấn công có thể cung các đầu vào đặc

biệt khiến ứng dụng ghi thêm các ký tự đặc biệt vào file nhật ký, làm hỏng

cấu trúc file và khiến các chương trình phân tích nhật ký không thể đọc

được.

e Chèn các ký tự không mong đợi: Kẻ tấn công có thể chèn các ký tự không

mong muốn để khiến chúng trở nên vô nghĩa hoặc thậm chỉ gây ra lỗi khi

được xử lý.

e Làm sai lệch thống kê file nhật ký: Kẻ tấn công có thể thao túng đầu vào

để tạo các mục nhật ký giả mạo, làm các số liệu thống kê và hoạt động ứng

dụng không còn chính xác Điều này giúp kẻ tấn công che giấu được các hoạt động độc hại đã gây ra trên hệ thống mục tiêu.

26

2.3.6 Cookie Injection

Các giá trị của cookie có thé được sử dung dé tấn công người dùng trên web

Kẻ tấn công có thé cần truy cập vào tài khoản của người dùng và có thể sử dụng

cookie để đạt được mục tiêu của mình

Kịch bản tấn công tiêm cookie:

e Kẻ tấn công gửi một yêu cầu đến máy chủ web chứa mã JavaScript độc hại

được nhúng trong chuỗi yêu cầu.

e Máy chủ web dễ bị tấn công không lọc mã độc hại và xử lý yêu cầu, tiêm

mã JavaScript vào trang web.

e Khi người dùng truy cập trang web bị nhiễm, mã JavaScript độc hại được

thực thi trên trình duyệt của họ.

e Mã độc hại có thể được thiết kế để đọc, sửa đổi hoặc tạo cookie trên trình

duyệt của người dùng.

27

2.3.7 Remote Code Execute(RCE)

Writing malicious Injecting malicious oe 2)

scripts 0I0111 010111 code to web server

Hinh 2.10: Remote Code Execute

Remote Code Execution (RCE) được sử dung để phơi lộ một dang lỗ hong

có thể bị khai thác khi đầu vào từ người dùng được tiêm vào một tập tin hoặc

chuỗi và toàn bộ gói tin được chạy trên trình phân tích của ngôn ngữ lập trình.

Đây không phải là loại hành vi mà nhà phát triển ứng dụng web thường thấy.

Một cuộc tấn công thực thi mã từ xa có thể dẫn đến một cuộc tấn công quy mô

lớn có thể đe dọa toàn bộ ứng dụng web và máy chủ web RCE cũng có thể dẫn

đến tăng quyền, chuyển hướng mạng và thiết lập tính liên tục Đây là lý do tại

sao RCE luôn có mức độ nghiêm trọng CAO/CỰC KỲ Nghiêm Trọng.

Tác động của tấn công RCE:

e Kiểm soát hoàn toàn: Thành công tấn công RCE có thể trao cho kẻ tấn

công quyền kiểm soát hoàn toàn đối với máy chủ chạy ứng dụng web

e Dánh cắp dữ liệu: Kẻ tấn công có thể đánh cắp dữ liệu nhạy cảm được lưu

28

trữ trên máy chủ, chang hạn as thông tin người dùng, thông tin tài chính

hoặc dữ liệu ứng dụng.

e Cài đặt phần mềm độc hại: Kẻ tấn công có thể cài đặt phần mềm độc hại

trên máy chủ, chang hạn như ransomware hoặc trojan horse, để duy tri

quyền truy cập hoặc gây thêm thiệt hại.

e Gây gián đoạn dich vụ (DoS): Kẻ tan công có thể sử dụng RCE để gây ra

tình trạng DoS, khiến ứng dụng web ngừng hoạt động và người dùng không

thể truy cập

e Leo thang đặc quyền (Privilege Escalation): Trong một số trường hợp, kẻ

tấn công có thể sử dung RCE để leo thang đặc quyền, cho phép chúng truy

cập vào các phần nhạy cảm hơn của hệ thống.

e Duy trì tính kiên trì (Persistence): Kẻ tấn công có thể sử dụng RCE để

thiết lập sự tồn tại lâu dài trên hệ thống, cho phép chúng duy trì quyền

truy cập ngay cả khi các dịch vụ được khởi động lại.

2.4 Hoc sâu trong Cloud Security

2.4.1 Tổng quan vé Học sâu

Các kỹ thuật học sâu (Deep Learning - DL) đã nổi lên như những công cụhiệu quả để tăng cường bảo mật trong các lĩnh vực khác nhau Chúng tận dụngkhả năng của mạng lưới thần kinh nhân tạo để học hỏi và xác định các mẫu từlượng di liệu khổng 16, cho phép xây dựng các giải pháp bảo mật mạnh mẽ và

hiệu quả hơn Đặc biệt là khi nó khi được ấp dụng vào bảo mật cho môi trường

đám mây, các kỹ thuật học sâu mang lại nhiều lợi ích như:

e Phát hiện tự động các mối đe dọa: Các thuật toán Học sâu có thể phân tích

khối lượng lớn dữ liệu, chẳng hạn như nhật ký lưu lượng truy cập mạng,

29

nhật ký hệ thống và hành vi người dùng, để tự động phát hiện các bấtthường và mối đe dọa bảo mật tiềm ẩn [1] [2] Điều này, cùng với các ứng

dụng khác của Học sâu, giúp giảm nhu cầu giám sát và phân tích thủ công, dẫn đến việc xác định nhanh hơn các sự cố bảo mật, phản hồi kịp thời,

giảm thiểu và tiết kiệm chi phí về thời gian và tài nguyên

e Giảm thiểu rủi ro do lỗi của con người: Giám sát bảo mật thủ công dễ mắc

phải sai sót của con người, có thể tạo ra lỗ hồng bảo mật Học sâu tự động

hóa nhiều tác vụ bảo mật, giảm thiểu rủi ro do lỗi của con người và đảm bảo phát hiện mối de dọa chính xác và nhất quán [3].

e Phân bổ tài nguyên tối ưu: Các mô hình học sâu học các mẫu và mối quan

hệ trong dữ liệu, cho phép phát hiện và phân loại mối đe dọa chính xác hơn Bằng cách phát hiện các mẫu và bất thường mà các hệ thống dựa trên quy

tắc truyền thống có thể bỏ qua, việc triển khai Học sâu giúp các tổ chứctối ưu hóa phân bổ tài nguyên và giảm thiểu chi phí không cần thiết

e Phát hiện mối đe dọa theo thời gian thực: Các mô hình học sâu tiên tiến có

thể phân tích dữ liệu theo thời gian thực, cho phép xác định ngay lập tứccác mối đe dọa bảo mật mới nổi Điều này rất quan trọng để đi trước một

bước so với các cuộc tấn công mạng [4].

e Dự đoán bảo mật: Bằng cách phân tích đữ liệu và mẫu lịch sử, Học sâu

cung cấp thông tin giá trị về các mối đe dọa tiềm ẩn trong tương lai Thôngqua phân tích dự đoán, các tổ chức có thể chủ động phân bổ tài nguyên và

thực hiện các biện pháp phòng ngừa, giảm thiểu các sự cỗ bảo mật tiềm ẩn

và các chi phí liên quan [5] [6].

Bên cạnh những ưu điểm, mặt khác, hiện nay học sâu vẫn còn nhiều khókhăn và hạn chế, chang hạn như:

e Yêu cầu lượng dữ liệu lớn: Học sâu đòi hỏi một lượng lớn dữ liệu để đào tạo

30