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

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 progra

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

Tai naavli!! Ban co the xoa dong chu nav!!! LT/049876058071000000

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ả

Thái Hoàng Vũ

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 hoàn thành tốt khóa học này

Tran trong!

Tac gia Thai Hoang Vii

1

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

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.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.1 Mã hóa 22 252 2222221222122122112212222222222222222222 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

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

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

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

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

iv

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

VI

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.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 soát truy CẬP :eanssense 50

Vii

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)

Vili

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 toà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ó

Những năm qua, ngành giáo đục An Giang đã thực hiện rất tốt các hướng dẫn về nhiệm vụ công nghệ thông tin do Bộ GDĐT ban hành cũng như là các kế hoạch ứng dụng công nghệ thông tin trong hoạt động của cơ quan nhà nước của UBND tỉnh Với mục tiêu đây mạnh công tác ứng dụng CNTT trong công tác quản

lý điều hành của ngành giáo dục tỉnh An Giang Năm 2016, Tỉnh đã triển khai dé tai

“Nghiên cứu thiết kế và xây dựng hệ thống cơ sở dữ liệu dùng chung ngành giáo

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

toà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 toà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à ngoà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

dung chung nganh giao duc tinh An Giang

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:

- Web service cho phép client va server tương tác được với nhau ngay cả trong những môi trường khác nhau

- 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

- 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 toà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)

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

giao thức thực hiện nhiệm vụ này là XML-RPC, SOAP và REST

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 Ngoài ra, để các dịch vụ có tính an toản, toà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 hoàn toà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ã

nguôn mở

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

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

nghĩa một số thành phần cho biết các thông tin này, cho phép các client truy tìm và nhận những thông tin được yêu cầu khi sử dụng web service Cấu trúc UDDI bao gồm:

- 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

Hình 1.3 Cấu trúc thông điệp SOAP [16]

- 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

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

Applicantion Client: Ứng dụng phía Client sử dụng web service xây dựng riêng cho mình

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 hoá 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 toán đó

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

10

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ó

11

- 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ụ:

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 hoàn chỉnh chứa ba phan chính xác định rõ mục đích của yêu cầu đó:

12

- 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

độ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 toà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

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ữ hoàn toà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 ngoà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ể

15

- Độ 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

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

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 toà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ủ

16

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 toà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 toà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, ngoà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ã hoá (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

17

Ngoà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 toà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 toà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 toàn vẹn của thông tin phải được đánh giá trên hai mặt: toà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 toá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 toà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 toá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 toà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 ngoài công ty cố gắng truy xuất đến cơ sở dữ liệu kế toá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ế toán được trao quyển quản lý cơ sở đữ liệu kế toá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

18

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 toà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 toà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 hoàn toà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à toà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 toà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

19

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)

20

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 soá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 soá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ể đoá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

21

- Dựa trên những gì người dùng biết, nhớ (knowledge); ví đụ: mật khẩu 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 soá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 hoàn toà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 Ngoài ra, bằng cách gán một người

22

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

23

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 toà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 soá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

24

Security Token Service

| (STS)

———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

25

- 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

| server

Client GET /api/employees HTTP/1.1 (Basu64(sor i : password”) ) (ASP.NET Web API)

Authorization: Basic YmFkcmk6U2VicmVOU2F1Y2U=

^

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 toà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 Ngoài ra, khách hàng cần có khả năng tao ma bam MDS [3]

26

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"

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"

> >

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

27

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 toà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 toá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 toá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

28

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]

- 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

password > _ EassWotdl 9 Authorization

- nn tn tkhu o y

- sy tntn nn ny ny wuyquy n

29

- 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

30

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 toà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

31