Nghiên cứu các cơ chế bảo mật web service và ứng dụng vào hệ thống cơ sở dữ liệu dùng chung ngành giáo dục tỉnh an giang

Trang 1

BỘ GIÁO DỤC VÀ ĐÀO TẠO

DAI HOC HUE

TRUONG DAI HOC KHOA HOC

THAI HOANG VU

NGHIEN CUU CAC CO CHE

BAO MAT WEB SERVICE VA UNG DUNG

VÀO HỆ THỐNG CO SO DU LIEU DUNG

CHUNG NGANH GIAO DUC TINH AN GIANG

CHUYEN NGANH: KHOA HOC MAY TINH

MA SO: 60.48.01.01

LUAN VAN THAC SI KHOA HOC

ĐỊNH HƯỚNG ỨNG DỤNG

NGƯỜI HƯỚNG DẪN KHOA HỌC

TS NGUYEN VAN HOA

Thiva Thién Hué, 2018

Trang 2

LOI CAM DOAN

Tơi cam đoan cơng trình nghiên cứu này là của riêng tơi Các số liệu, kết qua nêu trong luận văn là trung thực và chưa từng được ai cơng bố trong bất kỳ cơng

trình nào khác

Tác giả

Trang 3

LOI CAM ON

Xin chân thành cảm ơn Thầy hướng dẫn, TS Nguyễn Văn Hịa, Phĩ Trưởng

Khoa Cơng nghệ Thơng tin, Trường Đại học An Giang Thầy đã tận tình hướng dẫn

và tạo điều kiện thuận lợi đề tơi thực hiện luận văn này

Xin gửi lời tri ân đến quý Thầy, Cơ Khoa Cơng nghệ thơng tin Trường Dai

học Khoa học, Đại học Huế Thay, Co da tan tinh truyén dạy những kiến thức và

kinh nghiệm quý báu cho tơi trong suốt quá trình học tập

Cảm ơn tất cả các bạn học lớp Cao học Khoa học máy tinh khoa 3 — An

Giang đã cùng nhau học tập, nghiên cứu và chia sẽ những khĩ khăn trong suốt quá

trình học tập

Sau cùng, xin gửi lời cảm ơn sâu sắc tới gia đình đã động viên, chia sẽ khĩ

khăn và hết lịng hỗ trợ, tạo điều kiện thuận lợi để tơi hồn thành tốt khĩa học này

Tran trong!

Tac gia Thai Hoang Vii

Trang 4

MUC LUC Trang I9 0e 006900 e.e /1 i 98000092777 -1äà ii h/I0/9800 00 .- 3212}ƯỌỮƯ})}Ãà ,ƠỎ Hi ID 0028)/10/01697.(e0:70 ca vi 31:60 0027227757 - ‹*+Bg,),.,.,), )HẬH, Ð 3

1.1 TƠNG QUAN VỀ WEB SER.VICE 252 2222221222122112211221222 ae 3

1.1.1 Giới thiệu -252- 222222212 2221212221122112211222222222ere 3

1.1.2 Kiến trúc của web S€rVIC€ s- c2 c E111 21 12 t.2 tre 5

1.1.3 Các thành phần web serviee - 22 222221222121121122122222 ae 6

1:1;4:.Hoat:đồng:cfia:webi SGPVIGC pooissstois5e0SISEGENIEEEREIEEEHSIYĐSEGSIAĐVtSSssaensai 9 1.1.5 RESTFul web s€rVICe c2 c1 22011201 12211121 112 111011181115 11 811k xe 10

1.2 BẢO MẬT CHO WEB SER.VICE 222222 2212221122121121121222 e0 17

1.2.1 Tính bí mật -©222 222 29211212121112211122111221122221222 1 erae 17

12.2), Tinh toan Ven) sneer 18

1.2.8:.Tiính,Khã QUnng recone rec narceneesmeoncexonenmnrsnseornnereerenmmentensneemnnsterenn meres 19

1.3 KET CHUONG 1oooiccoccocsesceosceeseeeseseseesteteettentevtestettesetetteteeeteteceseeseeeees 20

CHƯƠNG2: CÁC CƠ CHÉ BẢO MẬT TRONG WEB SERVICE 21

2.1 QUẢN LÝ ĐỊNH DANH . - + 122 1E212212112110112E1 trrerrerrai 21

2.1.1 Xác thực và ủy quyền -225-2222212221222221122122222 re 21

2.1.2 Bảo mật dựa trên vai trỊ 1 2211222111122 1 1112111121111 1 111111811 x kêu 22 2.1.3 Bảo mật dựa trên xác nhận quyền SỞ hữu 22c nn S2 nhi 23

2.2 CÁC PHƯƠNG PHÁP XÁC THỰC VÀ ỦY QUYẺN -2 25

2.2.1 Xác thực cơ bản - G1 1112211112511 1151111111111 1121111111111 11 kg k nhện 25

Trang 5

2.2.2 Xác thực thơng điệp - S1 t1 1n nh nh Hà Hà HH Hee 26 2.2.3 Ủy quyển mớở -22- 222 221122122122121121121122122121222222 2e 28 2;2:4: Mã'th6ng báo” ÌTUW GẤP) sssssnisisttbisHbittfipBtltfGEBISIIGGIEEIGDNEEESBRIRSSEBĐASBAg8Ri 30 2.2.5 Mã truy cập dưới dang Bearer Token -cccccccsssiserrrrrrrsres 30 2.3 MÃ HĨA VÀ KỸ SỐ 2202221222221 ree 31 2.3.1 Mã hĩa 22 252 2222221222122122112212222222222222222222 re 31 2.3.2 Ký SỐ Q 0022022222112 re 31 2.3.3 Mật mã -2 2222122212211 arree 32 2.4 GIAO THỨC HTTP§ 22S2212211221221122112112112112112112222 xe 33 2.5 NGUY CO BAO MAT CUA ỨNG DỤNG WEB 22222222222 e2 35 2.6 KÉT CHƯƠNG 2 522222 221222112212112221221122112212222222221 are 4

CHƯƠNG 3: XAY DUNG CO CHE BAO MAT HE THONG CO SO DU LIEU DUNG CHUNG NGANH GIÁO DỤC TỈNH AN GIANG 43 3.1 GIỚI THIỆU VẺ HỆ THĨNG CƠ SỞ DỮ LIỆU DỪNG CHƯNG NGÀNH

GIÁO DỤC TỈNH AN GIANG 52 2222212221221112112112122222ee 43

3.1.1 Giới thiệu - 222 22222121112111211121112111211211221212122222222 re 43

3.1.2 Hệ thống cơ sở dữ liệu dùng chung ngành giáo dục tỉnh An Giang 43

3.2 PHAN TICH YEU CAU BAO MAT HE THONG CO S86 DU LIEU DUNG

CHUNG NGANH GIAO DUC TINH AN GIANG oo ooccc ccs csseceseceseceseteeeeeseeees 45

3.2.1 Yêu cầu bảo mật chung của một hệ thống thơng tin - 22 45 3.2.2 Yêu cầu bảo mật cụ thê của hệ thống cơ sở đữ liệu đùng chung ngành pião:dục tÏHh (An 8D: ạaitig0 t2 t00DDIVHEIEDEGEEEYĐAGSSEEAGBSHEERSHSNRERSHBIRĐSBAsmeenl 45 3.2.3 Phân tích các yêu cầu bảo mật hệ thống cơ sở dữ liệu dùng chung ngành giáo dục tỉnh An G1ang - cc t1 nn Tnhh HH HH Hà tra 45

3.3 THIET KE VA CAI DAT CO CHE BAO MAT HE THONG CO SO DU LIỆU DỪNG CHUNG NGÀNH GIÁO DỤC TỈNH AN GIANG 47

3.3.1 Thiết kế cơ chế bảo mật hệ thống . 22 222222221222122212221222ee 47

3.3.2 Cai đặt cơ chế bảo mật hệ thống 22 2222222221222122211221222122 e0 49

3.4 KÉT CHƯƠNG 3 222 2222222112211121112112112112122122222 are 51

I:45/0) 97.901.040) 81900) .ốốốốố 52

Trang 6

1 KET LUAN 2 KIEN NGHI TÀI LIỆU THAM KHAO wacccccccscsssssssssssssssssssssssccccssssssssssssusssssseseesesssssssssssnssssees 54 5008009202127 : HHĂHĂH , PL

PHU LUC 1: DANH SACH CAC WEB API CAP CHO CAC QUYEN TRUY CAP DEN AGEDU PMIS

PHU LUC 2: CAC MAN HINH CHỨC NĂNG CUA HE THONG KIEM SOAT

Trang 7

DANH MUC CAC BANG

Trang Bảng 3.1 Mơ tả các quyền truy cập hệ thong cece cee cee ccee cece cese tess ceeeteteeeteee 46 Bảng 3.2 Danh sách các bảng của cơ sở đữ liệu định danh va ty quyén 48

Trang 8

DANH MỤC CÁC HÌNH

Trang Hình 1.1 Kiến trúc của web servie 2s 22122122111211122112211211222 xe 5

Hình 1.2 Cấu trúc W§DL -: 222222 22222221 11222 te errrrie 7

Hình 1.3 Cấu trúc thơng điệp SOAP [ 16] -22:-2222222222222222212223122312212zzxe, §

Hình 1.4 Mơ tả hoạt động web S€TVIC€ ncnn TH nhàng 9

Hình 1.5 So sánh giữa RESTFul web service và Web servIce 11

Hình 1.6 Yéu cau Delete that bai ccccccsssssceeeeeessessessssssnsssneneeeeeeeeeeesssen 16

Hình 2.1 Bảo mật dựa trên xác nhận quyền sở hữu [l4] . -ccccsccscsss 25 Hình 2.2 Xác thực cơ bản - 1 1112221111251 11 1521111111111 11111 1112111120111 1k nhyn 26

Hình 2.3 Xác thực thơng điệp (Digest Authentication) -.-sccsc sec 27

Hình 2.4 Luồng thơng tin đăng nhập Web API sử dụng mật khẩu [ 15] 29

Hình 3.1 Kiến trúc hệ thống thơng tin CSDL đùng chung ngành giáo dục 43 Hình 3.2 Thiết kế mở của hệ thống quản lý trực tuyến - 2222222222222 44 Hình 3.3 Sơ đồ luồng thơng tin trong mơ hình xác thực ủy quyền cơ sở đữ liệu dùng chung ngành giáo dục tỉnh An Giang cc cc Share 48 Hình 3.4 Sơ đồ quan hệ giữa các bảng trong cơ sở AGEDU_Auth 49

Hình 3.5 Kết quả đạt được sau khi cài đặt hệ thống kiểm sốt truy CẬP :eanssense 50

Trang 9

API HTTP OWASP REST RP RPC SOAP STS UDDI URI W3C WSDL XML

DANH MUC CAC CHU VIET TAT

Application programming interface (Giao dién lap trinh ung dung) Hypertext Transfer Protocol (Giao thire truyén tai ndi dung siéu van ban)

Openweb application security project (Du an bao mat tng dung web

mo)

Representational State Transfer (Chuyển đổi trạng thái dai diện) Relying party (Ứng dụng bên thứ ba)

Remote Procedure Call (Triệu gọi thủ tục từ xa)

Simple Object Access Protocol (Giao thức truy cập đối tượng đơn giản)

Security token service (Dịch vụ cung cấp thơng báo bảo mật) Universal Description, Discovery Integration

Uniform resource identifier (Xác định tài nguyên đồng nhất) World Wide Web Consortium (Tổ chức World Wide Web) Web Service Description Langguage (Ng6n ngit m6 ta dich vu) Extensible Markup Langguage (Ngơn ngữ đánh dấu mở rộng)

Trang 10

MO DAU

1 Ly do chon dé tai

Trong thời đại bùng nỗ cơng nghệ thơng tin ngày nay, cơng nghệ web đã trở thành một nên tảng quen thuộc và phát triển rộng khắp Cĩ nhiều tổ chức lớn như Facebook, Google, Amazon, Ebay, Paypal, Youtube đang phát triển và thu được những thành tựu nổi bật nhờ phát triển website của họ cùng với những web service

được cung cấp

Giá trị cơ bản của web service dựa trên việc cung cấp các phương thức theo chuẩn trong việc truy nhập đối với hệ thống đĩng gĩi và hệ thống kế thừa Các phần mềm được viết bởi những ngơn ngữ lập trình khác nhau và chạy trên những nền tảng khác nhau cĩ thê sử đụng web service để chuyển đổi đữ liệu thơng qua mạng Internet theo cách giao tiếp tương tự bên trong một máy tính

Như bất kỳ hệ thống thơng tin nào, các web service cũng dé bị các vấn đề

bảo mật liên quan đến chứng thực, tính khả dụng và tính tồn vẹn Các vấn đề mới

và đầy thách thức liên quan đến an ninh phát sinh do tính chất phân phối của các web service và truy cập trên nhiều nền tảng của chúng Khi các web service cung

cấp truy cập vào dữ liệu một cách tự chủ, sự bảo mật và tính xác thực của dữ liệu

truyền qua chúng càng quan trọng hơn

Trong những năm gần đây, nhiều cơng nghệ và tiêu chuẩn đã được để xuất dé xử lý các vấn đề bảo mật liên quan đến các web service Tuy nhiên các mối đe dọa mới và các cuộc tấn cơng liên quan đến các web service cũng đang hiện hữu Vì vậy, cần cĩ một cách nhìn tổng quát về các cơng nghệ và tiêu chuẩn bảo mật liên quan đến các web service hiện cĩ

Trang 11

dục tỉnh An Giang” Mục tiêu của dé tai trên là xây dựng một cơ sở dùng chung cho

tồn ngành và một hệ thống các web service phục vụ cho việc truy, xuất, cập nhật, tương tác đến dữ liệu dùng chung Do đĩ, để đảm bảo được vấn để bảo mật liên quan đến chứng thực, tính khả dụng và tính tồn vẹn của hệ thống trên Tơi chọn để

tài “Nghiên cứu các cơ chế bảo mật web service và ứng dụng vào hệ thống cơ sở dữ liệu dùng chung ngành giáo dục tỉnh An Giang”

2 Mục đích nghiên cứu

Nắm vững các cơng nghệ, các cơ chế bảo mật của web service và thiết kế,

cài đặt cơ chế bảo mật vào hệ thống web service cơ sở dữ liệu dùng chung ngành giáo dục tỉnh An Giang

3 Đối tượng và phạm vi nghiên cứu

Các cơ chế bảo mật web service của cơ sở đữ liệu dùng chung ngành giáo dục tỉnh An Giang

4 Phương pháp nghiên cứu - Lý thuyết:

Tìm hiểu về lý thuyết từ các cơng trình nghiên cứu cĩ uy tín trên các tạp chí cĩ uy tín trong và ngồi nước, các giáo trình, sách tham khảo được xuất bản bởi những nhà xuất bản đáng tin cậy Trên cơ sở đĩ lựa chọn giải pháp thích hợp

- Thực nghiệm:

Thiết kế và cài đặt cơ chế bảo mật trên hệ thống web service co so dit liéu

Trang 12

CHUONG 1: TONG QUAN VE WEB SERVICE

VA BAO MAT WEB SERVICE

1.1 TONG QUAN VE WEB SERVICE

1.1.1 Giới thiệu

Theo định nghĩa của W3C (World Wide Web Consortium), Web service la một hệ thống phần mềm được thiết kế để hỗ trợ khả năng tương tác giữa các ứng dụng trên các máy tính khác nhau thơng qua mạng Internet, giao diện chung và sự gắn kết của nĩ được mơ tả bằng XML

Web service định nghĩa tài nguyên phần mềm cĩ thể xác định bằng địa chỉ URL, thực hiện các chức năng và đưa ra các thơng tin người dùng yêu cầu Một web service được tạo nên bằng cách lấy các chức năng và đĩng gĩi chúng sao cho các ứng dụng khác dễ dàng nhìn thấy và cĩ thể truy cập đến những dịch vụ mà nĩ thực hiện, đồng thời cĩ thể yêu cầu thơng tin từ web service khác Nĩ bao gồm các mơ đun độc lập cho hoạt động của khách hàng và doanh nghiệp và bản thân nĩ

được thực thi trên server

Giá trị cơ bản của web service dựa trên việc cung cấp các phương thức theo chuẩn trong việc truy nhập đối với hệ thống đĩng gĩi và hệ thống kế thừa Các phần mềm được viết bởi những ngơn ngữ lập trình khác nhau và chạy trên những nền tảng khác nhau cĩ thê sử đụng web service để chuyển đổi đữ liệu thơng qua mạng Internet theo cách giao tiếp tương tự bên trong một máy tính Tuy nhiên, cơng nghệ xây dựng web service khơng nhất thiết phải là các cơng nghệ mới, nĩ cĩ thể kết hợp

với các cơng nghệ đã cĩ như XML, SOAP, WSDL, UDDI Với sự phát triển và lớn mạnh của Internet, web service thật sự là một cơng nghệ đáng được quan tâm dé

giảm chi phí và độ phức tạp trong tích hợp và phát triển hệ thống + Các đặc điểm của web service:

Trang 13

- Phần lớn kĩ thuật của web service được xây dựng dựa trên mã nguồn mở và được phát triển từ các chuẩn đã được cơng nhận

- Web service bao gém cĩ nhiều mơ-đun và cĩ thể cơng bố lên mạng Internet

- Là sự kết hợp của việc phát triển theo hướng từng thành phần với những

lĩnh vực cụ thể và cơ sở hạ tầng web, đưa ra những lợi ích cho doanh nghiệp, khách

hàng, những nhà cung cấp khác và những cá nhân thơng qua mạng Internet

- Ngày nay web service đang rất phát triển, những lĩnh vực trong cuộc sống cĩ thể áp dụng và tích hợp web service là khá rộng lớn

+ Ưu điểm:

- Web service cung cấp khả năng hoạt động rộng lớn với các ứng dụng phần mềm khác nhau chạy trên những nên tảng khác nhau

- Sử dụng các giao thức và chuẩn mở Giao thức và định dạng dữ liệu dựa

trên văn bản (text), giúp các lập trình viên dé dàng hiểu được - Nâng cao khả năng tái sử dụng

- Thúc đây đầu tư các hệ thống phần mềm đã tổn tại bằng cách cho phép các tiến trình/chức năng nghiệp vụ đĩng gĩi trong giao điện web service

- Tạo mối quan hệ tương tác lẫn nhau và mềm dẻo giữa các thành phần trong hệ thống, dễ dàng cho việc phát triển các ứng dụng phân tán

- Thúc đây hệ thống tích hợp, giảm sự phức tạp của hệ thống, hạ giá thành hoạt động, phát triển hệ thống nhanh và tương tác hiệu quả với hệ thống của các doanh nghiệp khác

+ Nhược điểm:

- Những thiệt hại lớn sẽ xảy ra vào khoảng thời gian chết của web service, giao diện khơng thay đổi, cĩ thể lỗi nếu một máy khách khơng được nâng cấp, thiếu

Trang 14

- Cĩ quá nhiều chuẩn cho web service khiến người dùng khĩ nắm bắt - Phải quan tâm nhiều hơn đến vấn để an tồn và bảo mật

1.1.2 Kiến trúc của web service

Web service gồm cĩ 3 chuẩn chinh: SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language) va UDDI (Universal Description, Discovery, and Integration) UDDI (Dang ky dich vu) M6 ta dich vu (WDSL) Xuất bản Dịch vụ yêu cầu Gửi thơng điệp Dịch vụ cung cấp

Hình 1.1 Kiến trúc của web service

Giao thức web service là tập hợp các giao thức mạng máy tính được sử dụng

để định nghĩa, xác định vị trí, thi hành và tạo nên web service tương tác với những

ứng dụng hay dịch vụ khác

Giao thức này cĩ 4 thành phần chính:

Dịch vụ vận chuyên (Service Transport): cĩ nhiệm vụ truyền thơng điệp giữa các ứng dụng mạng, bao gồm những giao thức như HTTP, SMTP, FTP, JSM va giao thức thay đổi khối mở rộng (Blocks Extensible Exchange Protocol- BEEP)

Thơng điệp XML: cĩ nhiệm vụ giải mã các thơng điệp theo dinh dang XML để cĩ thể hiểu được ở mức ứng dụng tương tác với người dùng Hiện tại, những

Trang 15

Mơ tả dịch vụ: được sử dụng để miêu tả các giao diện chung cho một web service cụ thể WSDL thường được sử dụng cho mục đích này, nĩ là một ngơn ngữ

mơ tâ giao tiếp và thực thi dựa trên XML Web service sé sir dụng ngơn ngữ này để truyền tham số và các loại dữ liệu cho các thao tác và chức năng mà web service cung cấp

Khám phá dịch vụ: tập trung dịch vụ vào trong một nơi được đăng ký, từ đĩ

giúp một web service cĩ thể đễ dàng khám phá ra những dịch vụ nào đã cĩ trên

mạng, tốt hơn trong việc tìm kiếm những dịch vụ khác để tương tác Web service

cũng phải tiến hành đăng ký để các dịch vụ khác cĩ thể truy cập và giao tiếp Hiện

tại, UDDI API thường được sử dụng để thực hiện cơng việc này

Trong đĩ, tầng giao thức tương tác dich vu (Service Communication Protocol) với cơng nghệ chuẩn là SOAP SOAP là giao thức nằm giữa tầng vận chuyển và tầng mơ tả thơng tin về địch vụ, cho phép người đùng gọi một dich vụ từ

xa thơng qua một thơng điệp XML Ngồi ra, để các dịch vụ cĩ tính an toản, tồn

vẹn và bảo mật thơng tin, trong kiến trúc web service, chúng ta cĩ thêm các tầng Policy, Security, Transaction, Management

1.1.3 Các thành phần web service 1.1.3.1 Ngơn ngữ đánh dẫu mở rộng

eXtensible Markup Language (XML) là một chuẩn mở do W3C đưa ra cho

cách thức mơ tả dữ liệu, nĩ được sử dụng để định nghĩa các thành phan dữ liệu trên

trang web và cho những tài liệu B2B (Business to Business) Về hình thức, XML hồn tồn cĩ cấu trúc thẻ giống như ngơn ngữ HTML nhưng HTML định nghĩa

thành phần được hiển thị như thế nào thì XML lại định nghĩa những thành phần đĩ

chứa cái gì Với XML, các thẻ cĩ thể được lập trình viên tự tạo ra trên mỗi trang web và được chọn là định dạng thơng điệp chuẩn bởi tính phổ biến và hiệu quả mã

Trang 16

1.1.3.2

Web Service Description Language (WSDL) dinh nghia cach m6 ta web service theo ci pháp tổng quát của XML, bao gồm các thơng tin:

- Tên dịch vụ

- Giao thức và kiểu mã hĩa sẽ được sử dụng khi gọi các ham cua web service - Loại thơng tin: thao tác, tham SỐ, những kiểu dữ liệu (cĩ thể là giao diện

của web service cộng với tên cho giao diện này)

Một WSDL hợp lệ gồm hai phần: phần giao diện (mơ tả giao diện và phương thức kết nối) và phần thi hành mơ tả thơng tin truy xuất CSDL Cả hai phần này sẽ được lưu trong 2 tập tin XML tương ứng là tập tin giao diện dịch vụ va tap tin thi

hành dịch vụ Giao diện của một web service được miêu tả trong phan này đưa ra

cách thức làm thế nào để giao tiếp qua web service Tên, giao thức liên kết và định dạng thơng điệp yêu cầu để tương tác với web service được đưa vào thư mục của WSDL Service Interface Service Implementation Hình 1.2 Cấu trúc WSDL

1.1.3.3 Universal Description, Discovery, and Integration (UDDI)

Đề cĩ thể sử dụng các dịch vụ, trước tiên client phải tìm dịch vụ, ghi nhận thơng tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ UDDI định

Trang 17

- Trang trắng (White pages): chứa thơng tin liên hệ và các định đạng chính

yếu cua web service, chang hạn tên giao dịch, địa chỉ, thơng tin nhận dang Những

thơng tin này cho phép các đối tượng khác xác định được địch vụ

- Trang vàng (Yellow pages): chứa thơng tin mơ tả web service theo những loại khác nhau Những thơng tin này cho phép các đối tượng thấy được web service theo từng loại với nĩ

- Trang xanh (Green pages): chứa thơng tin kỹ thuật mơ tả các hành vi và các chức năng của web service

- Loại dịch vụ (tModel): chứa các thơng tin về loại dịch vụ được sử dụng

Những thơng tin về web service được sử dụng và cơng bố lên mạng sử dụng giao thức này Nĩ sẽ kích hoạt các ứng dụng để tìm kiếm thơng tin của web service

khác nhằm xác định xem dịch vụ nào sẽ cần đến nĩ

1.1.3.4 Simple Object Access Protocol (SOAP)

SOAP là một giao thức giao tiếp cĩ cấu trúc như XML Nĩ được xem là cau trúc xương sống của các ứng dụng phân tán được xây dựng từ nhiều ngơn ngữ và các hệ điều hành khác nhau SOAP là giao thức thay đổi các thơng điệp dựa trên XML qua mang may tinh, thơng thường sử dụng giao thức HTTP

Một client sẽ gửi thơng điệp yêu cầu tới server và ngay lập tức server sẽ gửi những thơng điệp trả lời tới client Cả SMTP và HTTP đều là những giao thức ở lớp ứng dụng của SOAP nhưng HTTP được sử dụng và được chấp nhận rộng rãi hơn

bởi nĩ cĩ thể làm việc rất tốt với cơ sở hạ tầng Internet

NV: Envelope

Trang 18

- Phần tử gốc — envelop: phần tử bao trùm nội dung thơng điệp, khai báo văn bản XML như là một thơng điệp SOAP

- Phần tử đầu trang — header: chứa các thơng tin tiêu để cho trang, phần tử này khơng bắt buộc khai báo trong văn bản Header cịn cĩ thể mang những dữ liệu chứng thực, những chứ ký số, thơng tin mã hĩa hay cài đặt cho các giao dịch khác

- Phần tử khai báo nội dung chính trong thơng điệp — body, chứa các thơng tin yêu cầu và thơng tin được phản hồi

1.1.4 Hoạt động của web service

Một ứng dụng WS bao gồm 2 thành phần: Client và Server giao tiếp với nhau qua giao thức HT TP

rrr SOAP over HTTP SOAP over HTTP Internet + + XML XML ¬._ User Web Service Location A Location B

Hình 1.4 Mơ tả hoạt động web service

Client gửi yêu cầu qua các lời gọi hàm thơng qua HTTP Request đến server Server gửi các kết quả được thực thi các ở hàm thơng qua HTTP Request

Mơ hình hoạt động của ứng dụng web service gồm 3 thành phân chính: UDDI register: Cơng cụ giúp nhà phát triển WS cơng bố những thơng tin về web service của mình cho cộng đồng các nhà phát triển ứng dụng Người dùng sẽ dựa vào các thơng tin này để sử đụng web service trong ứng đụng riêng của minh

Web service: Chứa giao thức SOAP định dạng dữ liệu, tài liệu WSDL định

nghĩa các hàm trong web service, XML để xây dựng ứng đụng phân tán

Trang 19

Cách thức hoạt động cĩ thể mơ tả như sau:

Đầu tiên, Applicantion Client cần truy vấn các mẫu tin UDDI theo 1 thơng

tin nào đĩ (chang han tén loai) để xác định web service cần tìm Khi đã xác định

được web service cần cho ứng dụng, Client cĩ thế lấy thơng tin về địa chỉ của tài

ligu WSDL cua web service nay dia trén mẫu tin UDDI Tài liệu WSDL sẽ mơ tả cách thức liên lạc với web service, định dạng gĩi tin truy vấn và phản hồi Dựa vào

những thơng tin này, Client cĩ thể tạo những gĩi tin SOAP tương ứng để liên lạc v6i Service

1.1.5 RESTFul web service

REST là một kiêu kiến trúc được định nghĩa bởi Roy Fielding [8] Muc dinh

của REST là thiết kế các ứng đụng mạng phân tán sử đụng HTTP như là một giao

thức tầng ứng dụng và nĩ là một mơ hình kiến trúc thực sự cho web Nĩ đã trở

thành nền tảng cho sự bùng nỗ của các API 1.1.5.1 Tổng quan về RESTFul web service

Theo định nghĩa của IBM [12], “REST dinh nghĩa một tập hợp các nguyên tắc kiến trúc mà chúng ta cĩ thể thiết kế các web service tập trung vào tài nguyên của hệ thống, bao gồm cách các trạng thái tài nguyên được xử lý và truyền qua giao thức HTTP bằng các ngơn ngữ khác nhau" Đây cũng là tính năng nổi bật nhất của RESTful web Service la hướng tài nguyên Tính năng này giúp đơn giản hố sự phức tạp của kiến trúc web bằng cách tránh sử dụng các cơ chế phức tạp như CORBA, RPC hoặc SOAP để giao tiếp qua lại giữa máy khách và máy chủ Các phương thức HTTP đơn giản với một số điều chỉnh được thay thế các thuật tốn đĩ

để cải thiện các dịch vụ như cĩ thể thấy trong hình bên dưới [4]

Trang 20

SOAP REST | _PO-xML_j —XML \@6soNsj[ Han ] LRS5/ATOM | 'WCF Services/ ata WS* Specs Hinh 1.5 So sanh gitta RESTFul web service va Web service 1.1.5.2 Kién tric cia RESTFul web service + Phương thức HP rõ ràng

Cĩ bốn phương thức HTTP chính trong phiên bản 1.1 cĩ tên GET, PUT, POST va DELETE (ngoai ra con cé cac phương thức khác như HEAD, CONNECT va TRACE; tuy nhién, nghiên cứu này sẽ khơng tap trung vào các phương thức đĩ)

Trong RESTful Web Server, mỗi phương thức đại diện cho một tương tác cụ thể và

sửa đổi đối với tài nguyên:

- GET: Phương thức này lấy dữ liệu từ máy chủ Web, tìm kiếm các tài nguyên được yêu cầu và thu thập dữ liệu theo yêu cầu Phương thức này khơng cĩ

quyền thay đổi hoặc sửa đi tài nguyên

- POST: Phương thức POST nhằm mục đích tạo tài nguyên mới trong máy chủ Do đặc điểm đĩ, phương thức POST được yêu cầu để chứa nội dung làm rõ tất cả các giá trị cần thiết cho việc tạo ra đĩ Giống như phương thức GET, phương thức này cũng khơng thể sửa đổi các tài nguyên hiện cĩ

Trang 21

- PUT: Phương thức PUT được sử dụng để thay đổi trang thái hoặc giá tri cập nhật của tài nguyên Khác với GET và POST, phương thức này cĩ thể sửa đổi các tài nguyên hiện cĩ Do đĩ, phương thức PUT phải chứa giá trị mới để sửa đổi tải nguyên

- DELETE: Phương pháp này loại bỏ hoặc xĩa các tài nguyên Trong một số trường hợp, các nhà cung cấp API khơng hỗ trợ loại phương thức này Chúng khơng cho phép người dùng xĩa tài nguyên và các tài nguyên đĩ chỉ được chuyển đến một thư mục riêng biệt hoặc thay đổi trạng thái thành xĩa Trong những trường hợp đĩ,

phương thức DELETE và PUT khá giống nhau

Bằng cách sử dụng các phương thức riêng biệt cho các mục đích cụ thể, nĩ khơng chỉ cải thiện việc làm sáng tỏ yêu cầu mà cịn giảm tải cơng việc cho máy chủ Chúng ta hãy xem xét một số phương thức HTTP trong RESTful để chứng kiến mức độ hiệu quả và đơn giản của chúng

+ Hướng tài nguyên

Tính năng này mơ tả rõ ràng nhất về định hướng tài nguyên trong RESTful web service cũng là chức năng nổi bật nhất của mơ hình này URI sẽ trực quan trỏ đến tài nguyên nào sẽ được tương tác bởi yêu cầu đĩ Bằng cách đọc URI, các nhà phát triển và người dùng cĩ thể cĩ nhận thức về những gì yêu cầu sẽ sửa đổi trong

tải nguyên Kiểu REST khuyến khích cĩ một URI riêng biệt cho mỗi mục đữ liệu, giống như một ảnh hoặc một mục nhập trong cơ sở dữ liệu Chúng ta xem một ví dụ: POST http://www.example.com/bookstore/books/name=exambook&ISBN=ISBN123

Theo phương thức HTTP, yêu cầu này yêu cầu tạo một cuốn sách mới với tên là “exambook” với “ISBN” của nĩ là ISBN123 Người đùng và nhà phát triển cĩ thể hiểu yêu cầu này bằng cách đọc URI, tuy nhiên, cách máy chủ web cĩ thể

hiểu yêu cầu và thực thi lệnh của nĩ Câu trả lời là cấu trúc của URI Về cơ bản, một URI hồn chỉnh chứa ba phan chính xác định rõ mục đích của yêu cầu đĩ:

Trang 22

- Host: Đây là địa chỉ của Web Server Trong trường hợp này, máy chủ lưu trữ là “www.example.com” Khi nhận được yêu cầu, trước tiên máy chủ web sẽ kiểm tra tính hợp lệ của máy chủ về yêu cầu đĩ để đảm bảo rằng yêu cầu đã được gửi đến địa chỉ chính xác

- Tài nguyên: Tên tài nguyên tương tác Sau khi kiểm tra máy chủ, máy chủ Web sẽ phát hiện và phê duyệt tên tài nguyên Tên tài nguyên của URI phải theo cấu trúc của tài nguyên Ví dụ: cĩ một tài nguyên cĩ tên là "books" trong tài nguyên "bookstore" và tên tài nguyên trên URI phải là bookstore/books Hai giá trị cần được phân cách bằng đấu “/”

- Giá trị: Day là giải thích cho yêu cầu Phần này sẽ bổ sung các yêu cầu để thu hẹp phạm vi tương tác hoặc chỉ định thêm chỉ tiết về hành động của yêu cầu đĩ Trong URI 6 trén, “name = exambook & ISBN = ISBN123” đĩng vai trị là giá trị của yêu cầu Nĩ làm rõ rằng yêu cầu là yêu cầu tạo ra cuốn sách mới với tên "exambook" và ISBN la ISBN123 Bang cách áp dụng cấu trúc rõ ràng, URI RESTful khơng chỉ trực quan để đọc, hiểu và định hướng tài nguyên (nghĩa là, mỗi yêu cầu phải chỉ định tài nguyên mà nĩ muốn thực hiện hành động bên trong) mà cịn đơn giản hĩa yêu câu

Chúng ta so sánh sự phức tạp của yêu cầu giữa các web service bằng cách sử dung SOAP va RESTful web Service <?xml version="1.0"?> <soap:Envelope xmins:soap="http://www.w3.org/2001/12/soap-envelope" soap: encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:body pb="http://www.acme.com/phonebook"> <pb:GetUserDetails> <pb:UserTD>12345</pb:UserTD> </pb:GetUserDetails> </soap:Body> </soap:Envelope>

Trang 23

động của yêu cầu đĩ phải được chỉ ra bằng cách sử đụng cấu trúc XML Hơn nữa, tất cả các thơng tin bổ sung cho hành động đĩ phải được chèn vào bên trong Body Cấu trúc này sẽ đây gánh nặng lên cả phía máy khách và phía máy chủ vì người dùng cần tạo một biểu mẫu phức tạp cho một yêu cầu đơn giản và máy chủ cần xử lý một XML phức tạp để lấy ra các thơng tin cần thiết Đối với cùng một mục đích, trong RESTful, yêu cầu sẽ ngắn gọn, đơn giản và chính xác Nĩ cĩ thể được hiểu

như sau:

GET http://www.acme.com/phonebook/UserDetails/12345

Chỉ cĩ một dịng cĩ thể đại điện cho tồn bộ tệp XML phức tạp và khơng cĩ

phan thân yêu cầu Nĩ chỉ là một URL, được gửi bằng phương thức HTTP GET Do

cấu trúc đơn giản, định hướng tài nguyên và thân thiện với người dùng, REST trở

thành cơ sở hạ tầng của nhiều API hơn vì tài liệu dễ hiểu và dễ thực hiện hơn nhiễu

+ Đại diện

Như đã giải thích ở trên trong Hình 1.5, sự khác biệt giữa các RESTful web service và các web service là REST sử dụng phương thức HTTP kết hợp một số

định dạng cĩ thể đọc như JSON hoặc XML JSON cũng được biểu diễn cho tài

nguyên được kích hoạt trong yêu cầu và nĩ phản ánh trạng thái hiện tại và các thuộc tính của tài nguyên JSON hoặc XML này đáp ứng đủ yêu cầu và được gửi đi trong

phan than HTTP

Trang 24

Kết quả này là một tập tin JSON chứa tất cả các thuộc tính cần thiết cho tài nguyên đĩ, trong trường hợp này, các thuộc tính trả về là ID Facebook, tên, giới

tính Đối với một số thuộc tính cĩ kích thước lớn như hình ảnh và video, liên kết

sẽ được bao gồm trong tập tin JSON và khách hàng cĩ thể truy cập và tải xuống chúng sau này Điều này cĩ thể giúp máy chủ tránh các giao dịch cổng kểnh vì văn bản đơn giản và đễ đọc chỉ được gửi Điều này cũng cĩ thể dẫn đến giảm sự phụ

thuộc vào cơ sở hạ tầng của nền tảng và thiết bị, do đĩ, các dịch vụ này cĩ thể được

sử đụng trên các hệ thống khác nhau bất chấp các ngơn ngữ lập trình + Phi trang thai

Giao tiép trong RESTful web service phải là phi trạng thái Nĩ cĩ nghĩa là mọi yêu cầu duy nhất từ phía máy khách đến máy chủ web phải chứa tất cả các thơng tin cần thiết dé phân tích và thực hiện yêu cầu đĩ Điều này cĩ thể dan dén giảm đung lượng lưu trữ trong máy chủ vì khơng cần lưu hoặc lưu trữ ngữ cảnh của các yêu cầu đĩ ở phía máy chủ Do đĩ, trạng thái phiên được giữ hồn tồn ở phía máy khách

Một trong những điều kiện để xác thực yêu cầu là cấu trúc URL được giới

thiệu ở trên Thơng thường, một yêu cầu nên chứa ba phần chính, hơn nữa, cĩ khả

năng là nhà cung cấp API sẽ cĩ một số đối số bắt buộc bổ sung Ví dụ: AdWords API của Google cũng yêu cầu khách hàng của họ bao gồm phiên bản API trong yêu cầu Các yêu cầu khơng thể đi qua quá trình xác thực của Google nếu cĩ bất kỳ đối số cịn thiếu nào

Một lần nữa, ràng buộc này sẽ duy trì hiệu suất cao của REST Phi trạng thái

cho thấy những lợi thế của nĩ như:

- Khả năng hiển thị: Các yêu cầu đủ rõ ràng đề máy chủ khơng phải tốn thêm cơng sức để cĩ cái nhìn xa hơn ngồi yêu cầu Như đã đề cập ở trên, trong thiết kế phi trạng thái, yêu cầu phải càng chỉ tiết càng tốt và do đặc điểm này, khả năng hiền

thị của mỗi yêu cầu được cải thiện đáng kể

Trang 25

- Độ tin cậy: Trong REST, sự thất bại một phần từ yêu cầu trước đĩ cĩ thể

được phục hồi dễ dàng mà khơng cần sao chép hoặc thay đổi trạng thái của tài nguyên

Chúng ta hãy xem xét sự thất bại của yêu cầu DELETE [5]

S Server DELETE SEND 200 DO SEND 404

RESOURCE NOTHING | NOT FOUND ` }} A a + ie) ; | Client DELETE | 382412 DELETED

RESOURCE RESOURCE ALREADY

Trong trường hợp này, phía máy khách gửi một yêu cầu xĩa để loại bỏ một oe ( |

Hình 1.6 Yêu cầu Delete thất bại

đối tượng trong tài nguyên đến máy chủ Sau khi đủ điều kiện yêu cầu, máy chủ

chấp nhận và thực hiện lệnh theo yêu cầu và gửi lại xác nhận Tuy nhiên, do lỗi kết nỗi, cĩ một sự thất bại ở giai đoạn này và xác nhận khơng thể được gửi cho máy

khách Kết quả là, máy khách sẽ cho rằng yêu cầu chưa được thực hiện và yêu cầu

mới sẽ được gửi lại đến máy chủ Tại thời điểm này, máy chủ sẽ khơng thực hiện hành động nào vì đối tượng đĩ đã bị xĩa rồi xác nhận khơng hợp lệ sẽ được gửi lại cho máy khách Do đĩ, tính tồn vẹn của hệ thống được duy trì ở mức cao nhất cĩ

thê vì khơng cĩ thay đối hoặc trùng lặp trong tài nguyên

- Khả năng mở rộng: Đây là một trong những tính năng nổi bật của REST, máy chủ khơng bắt buộc phải chuẩn bị khơng gian cho kết quả yêu cầu vì tất cả các thơng tin cần thiết của kết quả đã được gửi lại cho khách hàng như trả lời yêu cầu

đĩ Do đĩ, yêu cầu sẽ xác định loại kết quả trả về trong loại nội dung bên trong mọi

yêu cầu Điều này sẽ giảm độ trễ, lưu lượng mạng và tải trên máy chủ

Trang 26

1.2 BAO MAT CHO WEB SERVICE

Bảo mật, đây là một thuật ngữ rất rộng, nhưng nĩi chung nĩ biểu thị trạng

thái an tồn, hoặc khơng bị các mối nguy hiểm đe dọa Trong luận văn này chúng

tơi tập trung vào bảo mật cho các web service cụ thể là các web API được thiết kế

trên nền tảng ASP.NET của cơ sở đữ liệu đùng chung ngành giáo đục tỉnh An Giang Vì vậy rõ ràng là trọng tâm của chúng tơi ở đây là bảo mật thơng tin Thuật ngữ bảo mật thơng tin cĩ nghĩa là bảo vệ thơng tin và hệ thống thơng tin khỏi truy

cập trái phép, sử dụng, tiết lộ, gián đoạn, sửa đổi hoặc phá hủy nĩ Một hệ thống

thơng tin bảo mật (Secure Information System) là một hệ thống mà thơng tin được xử lý trên nĩ phải đảm bảo được 3 đặc trưng sau đây [ 13]:

- Tính bí mật của thơng tin (Confidentiality) - Tính tồn ven cua thong tin (Integrity) - Tinh kha dung cua thong tin (Availability) 1.2.1 Tinh bi mat

Một số loại thơng tin chỉ cĩ giá trị đối với một đối tượng xác định khi chúng

khơng phổ biến cho các đối tượng khác Tính bí mật của thơng tin là tính giới hạn về đối tượng được quyên truy xuất đến thơng tin Đối tượng truy xuất cĩ thể là con

người, là máy tính hoặc phần mềm, kể cả phần mềm phá hoại như virus, worm,

spyware

Tuy theo tính chất của thơng tin mà mức độ bí mật của chúng cĩ khác nhau

Ví dụ: các thơng tin về chính trị và quân sự luơn được xem là các thơng tin nhạy

cảm nhất đối với các quốc gia và được xử lý ở mức bảo mật cao nhất Các thơng tin khác như thơng tin về hoạt động và chiến lược kinh doanh của doanh nghiệp, thơng tin cá nhân, đặc biệt của những người nỗi tiếng, thơng tin cấu hình hệ thống của các

mạng cung cấp dịch vụ, v.v đều cĩ nhu cầu được giữ bí mật ở từng mức độ Đề

đảm bảo tính bí mật của thơng tin, ngồi các cơ chế và phương tiện vật lý như nhà

Xưởng, thiết bị lưu trữ, dịch vụ bảo vệ, thì kỹ thuật mật mã hố (Cryptography)

được xem là cơng cụ bảo mật thơng tin hữu hiệu nhất trong mơi trường máy tính

Trang 27

Ngồi ra, kỹ thuật quản lý truy xuất (Access Control) cũng được thiết lập để bảo đảm chỉ cĩ những đối tượng được cho phép mới cĩ thê truy xuất thơng tin

1.2.2 Tính tồn vẹn

Đặc trưng này đảm bảo sự ton tai nguyên vẹn của thơng tin, loại trừ mọi sự

thay đổi thơng tin cĩ chủ đích hoặc hư hỏng, mất mát thơng tin đo sự cố thiết bị

hoặc phan mềm Tính tồn vẹn được xét trên 2 khía cạnh:

- Tính nguyên vẹn của nội dung thơng tin - Tính xác thực của nguồn gốc thơng tin

Nĩi một cách khác, tính tồn vẹn của thơng tin phải được đánh giá trên hai mặt: tồn vẹn về nội dung va toan ven vé nguồn gốc Ví dụ: một ngân hàng nhận

được lệnh thanh tốn của một người tự xưng là chủ tài khoản với đầy đủ những thơng tin cần thiết Nội dung thơng tin được bảo tồn vì ngân hàng đã nhận được một cách chính xác yêu cầu của khách hàng (đúng như người xưng là chủ tài khoản gởi đi) Tuy nhiên, nếu lệnh thanh tốn này khơng phải đo chính chủ tài khoản đưa

ra mà do một người nào khác nhờ biết được thơng tin bí mật về tài khoản đã mạo

danh chủ tài khoản để đưa ra, ta nĩi nguồn gốc của thơng tin đã khơng được bảo tồn Sự tịan vẹn về nguồn gốc thơng tin trong một số ngữ cảnh cĩ ý nghĩa tương đương với sự đảm bảo tính khơng thê chối cãi (non-repudiation) của hệ thống thơng

tin Các cơ chế đảm bao su toan vẹn của thơng tin được chia thành 2 loại: các cơ

chế ngăn chặn (Prevention mechanisms) và các cơ chế phát hiện (Detection mechanisms) Cơ chế ngăn chặn cĩ chức năng ngăn cản các hành vi trái phép làm thay đổi nội dung và nguồn gốc của thơng tin Các hành vi này bao gồm 2 nhĩm: hành vi cố gắng thay đơi thơng tin khi khơng được phép truy xuất đến thơng tin và hành vi thay đổi thơng tin theo cách khác với cách đã được cho phép Ví dụ: một người ngồi cơng ty cố gắng truy xuất đến cơ sở dữ liệu kế tốn của một cơng ty và thay đổi dữ liệu trong đĩ Đây là hành vi thuộc nhĩm thứ nhất Trường hợp một nhân viên kế tốn được trao quyển quản lý cơ sở đữ liệu kế tốn của cơng ty, và đã dùng quyền truy xuất của mình để thay đổi thơng tin nhằm biển thủ ngân quỹ, đây

Trang 28

là hành vi thuộc nhĩm thứ hai Nhĩm các cơ chế phát hiện chỉ thực hiện chức năng

giám sát và thơng báo khi cĩ các thay đổi diễn ra trên thơng tin bằng cách phân tích

các sự kiện diễn ra trên hệ thống mà khơng thực hiện chức năng ngăn chặn các hành

vi truy xuất trái phép đến thơng tin Nếu như tính bí mật của thơng tin chỉ quan tâm đến việc thơng tin cĩ bị tiết lộ hay khơng, thì tính tồn vẹn của thơng tin vừa quan tâm tới tính chính xác của thơng tin và cả mức độ tin cậy của thơng tin Các yếu tố như nguồn gốc thơng tin, cách thức bảo vệ thơng tin trong quá khứ cũng như trong hiện tại đều là những yếu tố quyết định độ tin cậy của thơng tin và do đĩ ảnh hưởng đến tính tồn vẹn của thơng tin

1.2.3 Tính khả dụng

Tính khả dụng của thơng tin là tính sẵn sàng của thơng tin cho các nhu cầu truy xuất hợp lệ Ví dụ: các thơng tin về quản lý nhân sự của một cơng ty được lưu

trên máy tính, được bảo vệ một cách chắc chắn bằng nhiều cơ chế đảm bảo thơng

tin khơng bị tiết lộ hay thay đổi Tuy nhiên, khi người quản lý cần những thơng tin này thì lại khơng truy xuất được vì lỗi hệ thống Khi đĩ, thơng tin hồn tồn khơng

sử dụng được và ta nĩi tính khả dụng của thơng tin khơng được đảm bảo

Tính khả dụng là một yêu cầu rất quan trọng của hệ thống, bởi vì một hệ

thống tồn tại nhưng khơng sẵn sàng cho sử dụng thì cũng giống như khơng tổn tại

một hệ thống thơng tin nào Một hệ thống khả dụng là một hệ thống làm việc trơi

chảy và hiệu quả, cĩ khả năng phục hồi nhanh chĩng nếu cĩ sự cố xảy ra Trong

thực tế, tính khả dụng được xem là nên tảng của một hệ thống bảo mật, bởi vì khi hệ thống khơng sẵn sàng thì việc đảm bảo 2 đặc trưng cịn lại (bí mật và tồn vẹn) sẽ

trở nên vơ nghĩa

Hiện nay, các hình thức tấn cơng từ chối dịch vụ DoS (Denial of Service) va

DDoS (Distributed Denial of Service) được đánh giá là các nguy cơ lớn nhất đối với

sự an tồn của các hệ thống thơng tin, gây ra những thiệt hại lớn và đặc biệt là chưa

cĩ giải pháp ngăn chặn hữu hiệu Các hình thức tấn cơng này đều nhắm vào tính khả dụng của hệ thống

Trang 29

1.3 KET CHUONG 1

Trong chương này cung cấp cho chúng ta cái nhin téng quat vé web service web service sử dụng thơng điệp SOAP, RESTful web service sử dụng REST

Chúng ta đã tìm hiểu kiến trúc, các thành phần, và hoạt động của web service

sử dụng thơng điệp SOAP

REST định nghĩa một tập hợp các nguyên tắc kiến trúc mà chúng ta cĩ thê thiết kế các web service tập trung vào tài nguyên của hệ thống, bao gồm cách các trạng thái tài nguyên được xử lý và truyền qua giao thức HTTP bằng các ngơn ngữ khác nhau

Hiểu rõ kiến trúc và đặc điểm RESTful web service Nhận thấy những ưu điểm của RESTful web service trong việc xây dựng hệ thống các web service của cơ sở dữ liệu dùng chung ngành giáo dục tỉnh An Giang

Thuật ngữ bảo mật thơng tin cĩ nghĩa là bảo vệ thơng tin và hệ thống thơng

tin khỏi truy cập trái phép, sử dụng, tiết lộ, gián đoạn, sửa đổi hoặc phá hủy nĩ Một

hệ thống thơng tin bảo mật (Secure Information System) là một hệ thống mà thơng tin được xử lý trên nĩ phải đảm bảo được 3 đặc trưng như tính bí mật của thơng tin (Confidentiality), tinh toan ven cua thong tin (Integrity), tinh kha dung của thơng tin (Availability)

Trang 30

CHUONG 2: CAC CO CHE BAO MAT TRONG WEB SERVICE 2.1 QUAN LY DINH DANH

Một thực thể, cĩ thể là con người, tổ chức, thiết bị phan cứng hoặc phần

mềm ứng đụng, yêu cầu truy cập tài nguyên Tài nguyên cĩ thé 1a web service, trang

web Trừ khi tài nguyên được cơng khai và cĩ san cho tat ca moi người, một số loại

kiểm sốt truy cập sẽ được thực hiện bởi ứng dụng sở hữu các tài nguyên Đề thực thi kiểm sốt truy cập, thực thể phát hành yêu cầu đầu tiên phải được xác định và xác thực gọi là quản lý định danh

2.1.1 Xác thực và ủy quyền

Quản lý danh tính cĩ hai khía cạnh quan trọng: xác thực và ủy quyên

+ Xác thực: là quá trình khám phá danh tính của một thực thể thơng qua một

mã định danh và xác minh danh tính thơng qua việc xác thực các thơng tin được

cung cấp bởi cơ quan cĩ thâm quyền

« Ủy quyền: là quá trình xác định xem danh tính cĩ được phép thực hiện một hành động được yêu cầu hay khơng

Ứng dụng xác định thực thể hoặc người dùng thơng qua mã định danh hoặc ID người dùng Ví dụ: Bạn là người dùng đang cố gắng thiết lập danh tính với một ứng dụng Giả sử bạn thơng báo cho ứng dụng rằng mã nhận diện của bạn là Nguyen Van A (đây thực sự là định danh của tơi) Hệ thống cĩ thê thiết lập danh

tính cho bạn, dựa trên số nhận dạng bạn đã cung cấp Nhưng để trở thành một ứng dụng đáng tin cậy, nĩ phải xác nhận rằng bạn thực sự là người bạn yêu cầu Quá trình đĩ được gọi là xác thực Nĩ được thực hiện bằng cách chấp nhận chứng chỉ (thường là một mật khẩu) và xác nhận nĩ dựa vào mật khẩu được lưu trữ cùng với

ID người đùng trong cơ sở dữ liệu ứng dụng Với ý định là bạn sẽ khơng biết mật

khẩu của tơi và sẽ khơng thể đốn được nĩ, và do đĩ nỗ lực của bạn để xác thực

bằng cách sử dụng thơng tin đăng nhập của tơi sẽ khơng thành cơng bởi ứng đụng Đây là một trong những cơ chế được xây đựng cơ bản nhất của bảo mật ứng đụng

Người dùng cĩ thê được xác thực thơng qua ba loại thơng tin đăng nhập

Trang 31

- Dựa trên những gì người dùng biết, nhớ (knowledge); ví đụ: mật khẩu hoặc mã PIN - Dựa trên những gì người dùng sở hữu (ownership): ví dụ, chứng chỉ hoặc USB dongle - Dựa trên những gì thuộc về người dùng (nherence); ví du, dấu vân tay hoặc trình tự DNA

Một ứng dụng cĩ nhu cầu bảo mật cao hơn thực hiện một cơ chế xác thực dựa trên hai yếu tổ trên; loại cơ chế này được gọi là xác thực hai yếu tổ (TFA hoặc

2FA) Ví dụ về TFA là mạng cơng ty yêu cầu sử đụng mã thơng báo phần cứng

(hardware token) hoặc khĩa USB (USB dongle) cùng với mật khẩu Một ví dụ khác là ATM: Máy ATM yêu cầu thẻ ghi nợ của bạn và mã PIN khi thực hiện giao dịch Hiện nay cĩ một số ứng dụng thực hiện bảo mật ba yếu tổ

Khi một danh tính được xác thực được thiết lập, ứng dụng cĩ thể kiểm sốt

quyền truy cập vào các tài nguyên ứng dụng dựa trên danh tính này Quá trình này được gọi là ủy quyển Một ứng đụng đơn giản cĩ thê cho phép truy cập tài nguyên hồn tồn dựa trên danh tính Nhưng hầu hết các ứng dụng thực tế cho phép truy

cập dựa trên các thuộc tính, chang hạn như vai trị, được liên kết với danh tính

2.1.2 Bảo mật dựa trên vai trị

Bảo mật dựa trên vai trị là mơ hình bảo mật được sử dụng phơ biến nhất

trong các ứng dụng doanh nghiệp Lợi ích chính của việc sử dụng một mơ hình bảo mật dựa trên vai trị là sự dễ dàng quản trị an ninh Các quyên truy cập khơng được

trao cho một người dùng cá nhân, nhưng với một trừu tượng được gọi là một vai trị

Người dùng được chỉ định cho một hoặc nhiều vai trị, thơng qua đĩ người đùng sẽ cĩ quyền truy cập

Với mơ hình này, quản trị an ninh trở thành vấn đề quản lý các vai trị (thường ít người dùng hơn) bằng cách gán và bỏ gán vai trị cho người dùng Bằng cách gán quyền truy cập vào vai trị, quản trị viên cĩ thể gán củng quyên truy cập cho hàng trăm người dùng trong một thao tác Ngồi ra, bằng cách gán một người

Trang 32

dùng cho một vai trị, người đùng ngay lập tức nhận được tất cả quyển truy cập được xác định cho vai trị đĩ Cùng một cách đễ dàng quản trị cũng cĩ thể áp dụng cho các hoạt động bỏ gán

Bảo mật dựa trên vai trị đã tổn tại trong một thời gian dài trong NET

Framework, bat đầu với phiên bản 1.0

2.1.3 Bảo mật dựa trên xác nhận quyền sở hữu

Mơ hình nhận diện được đề cập cho đến nay tập trung vào một người dùng trình bày mã định danh và thơng tin đăng nhập vào một ứng dụng và ứng dụng thiết lập đanh tính cho người đùng Dựa trên thơng tin đăng nhập được trình bày, nếu ứng đụng cĩ thể xác thực rằng người dùng là những gì anh ta đang tuyên bố là, danh tính trở thành danh tính được xác thực Người dùng được phép cĩ quyên truy cập vào tài nguyên, dựa trên vai trị của người dùng

Một cách khác để mơ hình hĩa bảo mật dựa trên các xác nhận quyền sở hữu Khía cạnh cơ bản nhất dựa trên xác nhận quyền sở hữu là tập hợp các xác nhận

quyền sở hữu Yêu cầu chỉ là xác nhận quyên sở hữu - đĩ là tuyên bố rằng một thực

thể (một người dùng hoặc một ứng dụng) tự tạo ra Ví dụ các thơng tin về xác nhận

quyền sở hữu:

» Tên của người dùng là Abc

¢ E-mail cla Abc la abc@gmail.com

* Tudi của Abc là 30

+ Abc cĩ thê xĩa người đùng

So với mơ hình trước đĩ, trong đĩ người dùng trình bày thơng tin đăng nhập trực tiếp vào ứng dụng, trong mơ hình dựa trên xác nhận quyền sở hữu, người đùng chỉ trình bày các xác nhận quyền sở hữu chứ khơng phải thơng tin đăng nhập cho

ứng dụng Đối với một tuyên bố là cĩ giá trị thực tế, nĩ phải đến từ một thực thể mà

ứng dụng tin tưởng

Trang 33

Nền tảng của kiến trúc dựa trên yêu cầu là sự tin tưởng Nếu tơi tuyên bố rằng e-mail của tơi là abc(@gmail.com, mọi người sẽ biết ngay rằng tuyên bố của tơi cĩ hợp lệ hay khơng Một ứng dụng khơng cĩ trí thơng minh để đưa ra quyết định này, vì vậy nĩ phải đựa vào sự tin cậy Nếu tơi cung cấp cho một ứng dụng thơng

tin được tạo ra bởi một thực thể mà ứng dụng tin tưởng, thì ứng dụng sẽ tin tưởng

và chấp nhận yêu cầu đĩ Trong trường hợp này, ứng dụng dựa trên thực thể kia Loại ứng dụng này được gọi là ứng dụng Relying Party (RP)

Thực thể mà ứng dụng RP đựa vào được gọi là cơ quan cấp Cơ quan cấp phát hành các mã thơng báo bảo mật Mã thơng báo như một hộp chứa tập hợp các tuyên bố đề vận chuyền an tồn

Điểm cuối của cơ quan cấp quyền chấp nhận yêu cầu đối với mã thơng báo và các vấn đề tương tự được gọi là Security Token Service (STS) Khi người dùng yêu cầu mã thơng báo, cơ quan cấp quyển phải đảm bảo rằng người dùng đĩ là những gì họ cung cấp là đúng Nĩi cách khác, cơ quan cấp quyển phải xác thực người dùng dựa trên thơng tin đăng nhập Do đĩ, việc xác thực xảy ra ngay cả trong

bảo mật dựa trên yêu cầu, nhưng sự khác biệt là trách nhiệm xác thực được giao cho

cơ quan câp và khơng cịn với ứng dụng nữa

STS cĩ thể chọn giữ trách nhiệm xác thực trong chính nĩ (dựa trên cách nĩ được thiết kế) hoặc ủy quyền cho một thực thể khác được gọi là nhà cung cấp nhận

dang (IdP) IdP xác thực thơng tin đăng nhập của người dùng và truyền đạt tính hợp lệ của thơng tin đăng nhập trở lại STS Nếu thơng tin đăng nhập hợp lệ, STS sẽ phát hành mã thơng báo cĩ xác nhận quyền Người dùng gửi mã thơng báo cho ứng dụng

RP, xác thực mã thơng báo, trích xuất các xác nhận quyền, thiết lập danh tính dựa

trên các xác nhận quyên và sau đĩ kiểm sốt quyền truy cập dựa trên các xác nhận quyền sở hữu Bởi vì tuyên bố là nền tảng cho mơ hình này, nĩ được gọi là bảo mật dựa trên yêu câu

Trang 34

Security Token Service

| (STS)

—e-)

7] Client Relying party

———1-> application

Hình 2.1 Bảo mật dựa trên xác nhận quyền sở hữu [14]

Hình 2.1 thể hiện mơ hình bảo mật dựa trên xác nhận quyền sở hữu gồm cĩ các bước như sau:

- Khi người dùng chưa được xác thực yêu cầu một trang, trình duyệt của họ

được chuyển hướng đến trang nhà cung cấp nhận dạng (IdP)

- IdP yêu cầu người dùng trình bày thơng tin đăng nhập của họ, ví đụ: tên người dùng / mật khẩu

- IdP cung cấp một mã thơng báo trở lại mà được trả lại cho trình duyệt - Trinh duyệt hiện được chuyển hướng trở lại trang được yêu cầu ban đầu, xác

định xem mã thơng báo cĩ đáp ứng các yêu cầu để truy cập trang hay khơng

2.2 CÁC PHƯƠNG PHÁP XÁC THỰC VÀ ỦY QUYÈN

2.2.1 Xác thực cơ bản

Xác thực cơ bản (Basic Authentication) là một phan cua dac ta HTTP Nhu tén cho thay, nĩ là một lược đồ cơ bản hoặc đơn giản và hoạt động như sau [3]:

- Máy khách yêu cầu một tài nguyên trong máy chủ

- Nếu tài nguyên yêu cầu máy khách phải được xác thực, máy chủ sẽ gửi lại mã 401 - Mã trạng thái khơng được phép trong phản hồi và tiêu đề phản hồi WWW- Authenticate: Basic Tiêu đề phản hồi này cũng cĩ thể chứa realm, đĩ là chuỗi xác định đuy nhất một vùng trong máy chủ mà máy chủ cần chứng chỉ hợp lệ để xử lý yêu cầu thành cơng

Trang 35

- Máy khách hiện gửi tiêu dé ủy quyền Authorization: Basic “YmFkemk6U2VjcmV0U2F1Y2U =” chứa thơng tin đăng nhập Giá trị tiêu đề yêu cầu ủy quyền chỉ là một chuỗi mã hĩa base64 của ID người đùng và mật khẩu được phân tách bằng dấu hai chấm ở giữa và khơng được mã hĩa theo bất kỳ cách nào

- Nếu thơng tin đăng nhập hợp lệ, máy chủ sẽ gửi trả lời và mã trạng thái 200

- OK, như được minh họa trong Hình 2.2 GET /api/employees HTTP/1.1 Vv A HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic | server

Client GET /api/employees HTTP/1.1 (Basu64(sor i : password”) ) (ASP.NET Web API) Authorization: Basic YmFkcmk6U2VicmVOU2F1Y2U= Vv ^ HTTP/1.1 200 0K Content-Type: application/json; charset=utf-8 {"Department":“Revenue","Id":“456","Name":"Jane Q Public"}] Hình 2.2 Xác thực cơ bản 2.2.2 Xác thực thơng điệp

Xác thực thơng điệp (Digest Authentication) là một phần cua dac ta HTTP,

giống như xác thực cơ bản Khơng giống như xác thực cơ bản, Xác thực thơng điệp tương đối an tồn hơn để sử đụng với HTTP thuần túy Một điểm quan trọng cần lưu ý về Xác thực thơng điệp là mật khẩu thực khơng được gửi đến máy chủ Chỉ cĩ

một mã băm MDS hoặc một thơng báo được gửi đi Xác thực thơng điệp thay đổi độ

phức tạp của thơng báo Khơng giống như xác thực cơ bản, Xác thực thơng điệp phức tạp hơn và cần hỗ trợ từ phía máy khách cũng như người dùng cuối để làm

cho lược đỗ hoạt động hiệu quả Khách hàng cần tăng một bộ đếm nonce cho mọi

yêu cầu để ngăn chặn các cuộc tấn cơng phát lại Điều đĩ cĩ nghĩa là khách hàng cần phải theo đối các yêu cầu được thực hiện Ngồi ra, khách hàng cần cĩ khả năng tao ma bam MDS [3]

Trang 36

Transaction#1 GET /api/employees HTTP/1.1 = HTTP/1.0 401 Unauthorized WWW-Authenticate: Digest realm="RealmOfBadri", qop="auth", nonce="ded98b7102dd2f0e8b11 d0f600bfb0c093"

GET /api/employees HTTP/1.1 Transaction#2

Authorization: Digest username=“john", realm=" RealmOfBadri", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri=" api/employees", qop=auth, nc=00000001cnonce="0a4f113b ", esponse="6629fae49393a05397450978507c4ef1" Server 0lient HTTP/1.1 200 0K Content-Type: application/json; charset=utf-8 (ASP.NET Web API) {{"Department":"Enforcement”,"Id":"123","Name":"John Q Law"}", {'Department":“Revenue","Id":*456","Name":"Jane Q Public"}]

GET /api/employees HTTP/1.1 Transaction#3

Authorization: Digest username=“john", realm="RealmOfBadri",

nonce="dcd98b7 102dd2f0e8b11d0f600bfb0c093", uri="

/api/employees", qop=auth, ne=00000002, cnonce="0a4t113b ",

response="819d62c5167ae6f34160617522ebe9de"

> >

A HTTP/1.1 200 0K

Content-Type: application/json; charset=utf-8

I('Department":"Enforcement"," "Name":"John Law"}",

'Department":“Revenue","Id":*456","Name":"Jane 0 Public"}]

Hình 2.3 Xác thực thơng điệp (Digest Authentication)

Xác thực thơng điệp tương đối phức tạp Quy trình Xác thực thơng điệp bao gơm các bước sau:

- Máy chủ đáp ứng với một phản ứng 401 trái phép khi thấy rằng các thơng

tin khơng hợp lệ hoặc bị thiếu, như hình 2.3

- Trong tiêu đề WWW-Authenticate, máy chủ chỉ ra sơ đồ cĩ liên quan, đĩ là

so dé phân hủy và gửi một số được tạo ngẫu nhiên được gọi là nonce Nonce là một

số được sử dụng một lần Nonce được truyền cùng trong các yêu cầu tiếp theo cho đến khi nonce hết hạn Vào thời điểm đĩ, máy chủ gửi lại phản hồi 401 cùng với

một nonce mới Thời gian hết hạn cho một nonce được thiết lập để ngăn chặn các cuộc tấn cơng phát lại Với mục đích của ví dụ này, giả sử nonce là

dcd98b7102dd2f0e8b1 1d0f600bfb0c093

- Tham số khác được gửi cùng với nonce là gia tri Quality of Protection

(QOP) Như đã đề cập trước đĩ là một mã băm hoặc một thơng báo được gửi đến

máy chủ QOP về cơ bản là cơng thức đề băm Nĩ xác định cách các tham số khác

được kết hợp và băm để cĩ được giá trị cuối cùng Trong vi du QOP = "auth", biéu

Trang 37

thị chỉ xác thực Giá trị khác là "auth-int", biểu thị xác thực với bảo vệ tính tồn vẹn

- Hai gia tri cnonce, ne như trong hình 2.3 được tạo ra từ máy khách Cũng giống như máy chủ, nonce được gửi bởi máy chủ cho máy khách, cnonce là một nonce được tạo ra bởi máy khách và được gửi đến máy chủ Ne là bộ đếm thường bắt đầu với 00000001 Yêu cầu tiếp theo từ cùng một máy khách sẽ cĩ cùng một may chu nonce va nonce may khach, nhưng bây giờ ne sẽ là 00000002 Nĩ khơng cần phải luơn luơn tăng thêm 1, nhưng nĩ phải là lớn hơn ne trước đĩ

- Máy khách, khi nhận được tiêu dé WWW-Authenticate, biết dựa trên giá trị

QOP, nĩ phải tạo ra giá trị băm như thế nào Bởi vì nĩ là "auth" trong trường hợp

của ví dụ, nĩ tạo ra một cnonce là 0a4f113b Lần đầu tiên, nĩ sử dung ne la

00000001 Hàm băm được tính tốn thơng qua các bước sau đây, cho QOP là "auth" Các giá trị băm trong hình minh họa như sau

Như hình 2.3 thực hiện băm MDS như sau “jqhuman: RealmOfBadri: abracadabra” được băm thành aa71f01f351 “GET:/api/employees” được băm thành 939e7552ac Va aa71f01f351: ded98b7102dd2f0e8b 1 1d0f600bfb0c093: 0a4f113b: auth: 939e7552ac được băm ra kết quả là 6629fae49393a05397450978507c4ef1

- Mã băm MD5 cuối cùng hoặc thơng báo được tính tốn ở trên được máy khách gửi trong trường phản hồi của tiêu đề ủy quyên, như trong hình

- Máy chủ nhận tất cả các giá trị này và nhận tên người dùng từ giá trị tiêu đề yêu cầu Nĩ lấy mật khâu cho tên người dùng này từ kho lưu trữ thơng tin đăng

nhập Và nĩ cũng tự băm MDS theo đúng trình tự như liệt kê tại bước 5 Nếu mã

băm này trùng khớp với mã băm từ người dùng gửi thì thơng tin đăng nhập chính xác Và trả về mã xác thực là HTTP/1.1 200 OK cùng với thơng tin người đùng 2.2.3 Ủy quyền mở

Ủy quyền mở (OAuth) cho phép ứng đụng khách truy cập web API bằng một trong hai cách: thay mặt cho người dùng cuối bằng cách phối hợp tương tác phê duyệt giữa người dùng và ứng dụng web cơ bản, thường được gọi là OAuth ba bên

Trang 38

và bằng cách cho phép ứng dụng khách truy cập API web thay mặt cho ứng dụng khách, thường được gọi là OAuth hai bên Thành phần quan trọng của OAuth là mã thơng báo truy cập (Access Token) OAuth chỉ định cách ứng đụng khách cĩ thể yêu um thơn otruy pt y ủủydquyn nth tn oo

y ut nuyn truyc t nuyn cb ov [9] tr tron ut - Resource Owner (User) - nt onan n uwuic p quy n truy c ot nuyn cbov - Resource Server(APD- y ủ utr t nuyn cbov kh no pnhn t n_- otruy cv yu u

- Client (Application) -M t ng d ngc ntruyc ot nuyn cbo

- Authorization Server (API)- y ủ t on toon otruy p cho ngdn u t cchis hut nuyn ono cuy quy n t chis hut nuyn

Lun t n tn n n pWebAPIs dngmtkhuctachis hut

nuyn nh trong OAuth 2.0

Trang 39

- Máy chủ ủy quyền xác thực thơng tin đăng nhập và trả về mã thơng báo truy cập

- Để truy cập tài nguyên được bảo vệ, máy khách bao gồm mã thơng báo truy cập trong tiêu để cấp phép của yêu cầu HTTP

2.2.4 Mã thơng báo truy cập

Mã thơng báo truy cập (Access Token) chỉ là một chuỗi đại diện cho ủy quyền được cấp cho ứng dụng khách Vì mã thơng báo truy cập được cấp bởi máy chủ ủy quyển và được máy chủ tài nguyên sử dụng, nội dung của mã thơng báo

thường khĩ hiểu đối với ứng dụng khách Đặc tả OAuth 2.0 khơng xác định cách

mã thơng báo truy cập phải được cấu trúc hoặc định đạng cũng như khơng xác định cách mã thơng báo phải được xác thực Nĩ phụ thuộc vào máy chủ tài nguyên và máy chủ ủy quyền Mã thơng báo truy cập cĩ thể được tạo theo một số đặc điểm kỹ thuật như; ví dụ, mã thơng báo truy cập cĩ thể là mã thơng báo ưeb đơn giản (SWT)

hoặc Mã thơng báo Web JSON (JTWT) OAuth 2.0 khơng bắt buộc ký điện tử cĩ lợi cho việc truyền dữ liệu, do đĩ TLS bắt buộc đối với các mã thơng báo đĩ

2.2.5 Mã truy cập dưới dang Bearer Token

OAuth 2.0 về cơ bản chỉ định cách cho các loại máy khách khác nhau dé

nhận mã thơng báo truy cập từ máy chủ ủy quyền và hiển thị mã thơng báo tới máy chủ tài nguyên dé truy cập vào tài nguyên được bảo vệ, trong trường hợp của chúng là API web Trình bày mã thơng báo truy cập vào một API web cĩ thể được thực

hiện theo ba cách sau:

- Tiêu để HTTP, sử đụng tiêu để yêu cầu ủy quyền HTTP - Nội dung thư, sử đụng cơ quan thực thể yêu cầu HTTP - Chuỗi truy vấn, sử đụng URI yêu cầu HTTP

Với ba tùy chọn này, cách ưu tiên là sử dụng tiêu để ủy quyền HTTP vì nĩ cĩ thê được sử đụng nhất quán cho tất cả các phương thức HTTP và các kiểu nội dung

yêu cầu cia XML, JSON và các tiêu để khơng được lưu trữ hoặc ghi lại Trên thực

Trang 40

tế, các mã thơng báo web như SWT và JWT cố gắng giữ các mã thơng báo nhỏ gọn để vận chuyên trong tiêu đề yêu cầu ủy quyền HTTP Mã thơng báo SAML, là XML, khơng được thiết kế cho kích thước nhỏ hơn; đây là một trong những lý do các thẻ web được ưu tiên trong các web API RESTful

Mã thơng báo truy cập trong tiêu để yêu cầu ủy quyền HTTP được mơ tả như

sau

GET /api/employees/12345 HTTP/1.1

HOS: my server com

Authorization: Bearer DFJQNC694GisUrPVZap5pdyWLohF k==

2.3 MA HOA VA KY SO

2.3.1 Mã hĩa

Là quá trình chuyển đổi dữ liệu trong văn bản thuần túy và làm cho nĩ khơng

thể đọc được với tất cả mọi người ngoại trừ những người cĩ quyền đọc dữ liệu, với mục tiêu bảo mật

Ví dụ: Giả sử tơi muốn gửi một thơng điệp bí mật dành riêng cho Alice Tơi mã hĩa tin nhắn để chỉ cơ ấy mới cĩ thê giải mã và đọc đữ liệu

2.3.2 Ký số

Là quá trình mà chữ ký điện tử được tạo ra để chứng minh tính xác thực và tính tồn vẹn của dữ liệu Chữ ký hợp lệ cung cấp cho người nhận sự tự tin rằng dữ liệu nhận được thực sự là từ người gửi chính xác và dữ liệu đĩ khơng bị giả mạo

theo bat kỳ cách nào trong quá trình chuyền

Ví dụ: Tơi muốn gửi một tin nhắn cho Bob Tơi ký thơng điệp vì Bob quan

tâm đến tính xác thực của dữ liệu; đĩ là, anh ta muốn chắc chắn rằng thơng điệp là

từ tơi và khơng phải là kẻ mạo danh và rằng thơng điệp ban đầu của tơi khơng bị thay đổi trong quá trình truyền dữ liệu

Mã hĩa và ký tên khơng loại trừ lẫn nhau Một tin nhắn cĩ thể được mã hĩa

và ký điện tử Ví dụ: giả sử tơi muốn gửi một thơng điệp bí mật tới Charlie dé chỉ anh ấy mới cĩ thê đọc tin nhắn Tơi cũng muốn đảm bảo rằng Charlie chấp nhận