Quản lý rủi ro theo các tiêu chi NFP cho các dịch vụ web NFP (non functional property) aware risk management for web services

Kết quả , trang Web bản đồ ở trên có thể mở rộng tính năng của nó để cung cấp cho một dịch vụ Web mà các doanh nghiệp khác có thể sử dụng để đưa ra các định hướng cho các địa điểm về văn

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-LUẬN VĂN THẠC SỸ KHOA HỌC

QUẢN LÝ RỦI RO THEO CÁC TIÊU CHÍ NFP

CHO CÁC DỊCH VỤ WEB NFP (NON-FUNCTIONAL PROPERTY) - AWARE RISK MANAGEMENT FOR WEB SERVICES

NGÀNH: CÔNG NGHỆ THÔNG TIN

MÃ SỐ:………

PHẠM VĂN ĐỒNG

Người hướng dẫn khoa học: TS VŨ THỊ HƯƠNG GIANG

HÀ NỘI 2010

LỜI CAM ĐOAN

Tôi – Phạm Văn Đồng, học viên lớp Cao học CNTT 2007-2009 Trường Đại học Bách Khoa Hà Nội – cam kết Luận văn tốt nghiệp là công trình nghiên cứu của bản thân tôi dưới sự hướng dẫn của TS Vũ Thị Hương Giang, Viện CNTT-TT, Trường Đại học Bách Khoa Hà Nội

Các kết quả nêu trong Luận văn tốt nghiệp là trung thực, không sao chép toàn văn của bất kỳ công trình nào khác

Hà Nội, ngày 04, tháng 02, năm 2010 Học viên: Phạm Văn Đồng

Lớp : Cao Học CNTT 07-09

có thể hoàn thành luận văn này

Tôi xin chân thành cảm ơn tập thể các thầy, cô giáo trường Đại học Bách Khoa Hà Nội nói chung và Viện Công Nghệ Thông Tin và Truyền Thông nói riêng đã tận tình giảng dạy truyền đạt cho tôi những kiến thức, kinh nghiệm quý báu trong suốt những năm học vừa qua

Tôi cũng xin cảm ơn các giảng viên đồng nghiệp ở trường đại học Mỏ - Địa chất đã tạo điều kiện về thời gian để tôi có thể học tập và hoàn thành luận văn Cuối cùng, tôi xin chân thành cảm ơn gia đình, người thân đã hết lòng giúp

đỡ hỗ trợ về vật chất lẫn tinh thần giúp tôi yên tâm học tập và nghiên cứu trong suốt quá trình học tập và thực hiện luận văn

MỤC LỤC

LỜI CAM ĐOAN 2

LỜI CẢM ƠN 3

MỤC LỤC 4

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

DANH MỤC CÁC BẢNG 8

DANH MỤC CÁC TỪ VIẾT TẮT 9

MỞ ĐẦU 10

1 Tính cấp thiết của đề tài 10

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

3 Nhiệm vụ nghiên cứu 10

4 Phương pháp nghiên cứu 11

5 Phạm vi nghiên cứu 11

6 Cấu trúc luận văn 11

CHƯƠNG 1 TỔNG QUAN VỀ DỊCH VỤ WEB 12

1.1 Khái niệm dịch vụ Web 12

1.2 Kiến trúc dịch vụ Web 15

1.3 Các công cụ xây dựng dịch vụ Web 16

1.3.1 XML– Extensible Markup Language 16

1.3.2 WSDL - Web Services Description Language 16

1.3.3.UDDI - Universal Description, Discovery and Intergration 19

1.3.4 SOAP - Simple Object Accesss Protocol 19

1.3.5 Tạo Web Service 22

1.4 Các lợi ích của dịch vụ Web 23

TỔNG KẾT CHƯƠNG 26

CHƯƠNG 2 QUẢN LÝ RỦI RO CHO CÁC DỊCH VỤ WEB 27

2.1 Giới thiệu 27

2.2 Khái niệm quản lý rủi ro 27

2.3 Các rủi ro của dịch vụ Web 28

2.4 Tích hợp quản lý rủi ro dịch vụ Web vào vòng đời phát triển hệ thống - SDLC (System Develop Life Circle) 29

2.5 Các vai trò chính của người tham gia quản lý rủi ro dịch vụ Web 30

2.6 Quy trình quản lý rủi ro cho dịch vụ Web 31

2.6.1 Đánh giá rủi ro cho dịch vụ Web 32

2.6.2 Giảm nhẹ rủi ro cho dịch vụ Web 49

2.6.3 Ước lượng và đánh giá 63

TỔNG KẾT CHƯƠNG 65

CHƯƠNG 3 CÁC TIÊU CHÍ NFP ĐỐI VỚI DỊCH VỤ WEB 66

3.1 Giới thiệu 66

3.2 An toàn (Security) 66

3.3 Chịu lỗi (Fault Tolerance) 67

3.4 Thực thi (Implementation) 69

3.5 Sẵn sàng (Availability) 71

3.6 Tin cậy (Reliability) 71

3.7 Phục hồi (Recovery) 72

3.8 Tương thao tác (Interoperability) 73

TỔNG KẾT CHƯƠNG 74

CHƯƠNG 4 QUẢN LÝ RỦI RO CHO DỊCH VỤ WEB THEO TIÊU CHÍ AN TOÀN 75

4.1 Giới thiệu 75

4.2 Quy trình quản lý rủi ro an toàn dịch vụ Web 76

4.3 Thiết lập ngữ cảnh (Context establishment) 78

4.3.1 Nghiên cứu tổng thể (General consideration) 78

4.3.2 Các tiêu chí cơ bản 78

4.3.3 Xác định phạm vi và các giới hạn 80

4.3.4 Vai trò của tổ chức đối với quản lý rủi ro an toàn dịch vụ Web 81

4.4 Đánh giá rủi ro an toàn dịch vụ Web 81

4.4.1 Mô tả về đánh giá rủi ro an toàn dịch vụ Web 81

4.4.2 Các bước đánh giá rủi ro 82

4.5 Xử lý rủi ro an toàn dịch vụ Web (WS Security Risk Treatment) 90

4.5.1 Mô tả tổng quát về xử lý rủi ro 90

4.5.2 Giảm nhẹ rủi ro (Risk Reduction) 92

4.5.3 Duy trì rủi ro (Risk retention) 93

4.5.4 Tránh rủi ro (Risk avoidance) 94

4.5.5 Chuyển đổi rủi ro (Risk transfer) 94

4.6 Chấp nhận rủi ro an toàn dịch vụ Web (WS security risk acceptance) 94

4.7 Truyền đạt rủi ro an toàn dịch vụ Web (WS security risk communication) 95

4.8 Theo dõi và xem lại rủi ro an toàn dịch vụ Web (WS security risk monitoring and review) 96

4.8.1 Theo dõi và xem lại các nhân tố rủi ro (Monitoring and review of risk factors) 96

4.8.2 Theo dõi, xem lại và cải tiến quản lý rủi ro (Risk management monitoring, reviewing and improving) 97

TỔNG KẾT CHƯƠNG 99

CHƯƠNG 5 XÂY DỰNG THỬ NGHIỆM CHƯƠNG TRÌNH QUẢN LÝ RỦI RO THỬ NGHIỆM THEO TIÊU CHÍ AN TOÀN ĐỐI VỚI CÁC DỊCH VỤ WEB 101

5.1 Khảo sát thực trạng quản lý rủi ro an toàn và chịu lỗi của dịch vụ Web tại một số cơ quan, doanh nghiệp ở Việt Nam 101

5.1.1 Mục đích khảo sát 102

5.1.2 Nội dung khảo sát 102

5.1.3 Kết quả khảo sát 102

5.2 Chương trình thử nghiệm quản lý rủi ro dịch vụ Web theo tiêu chí an toàn 105

5.2.1 Bước 1.1 Xác định phạm vi hệ thống 111

5.2.2 Bước 1.2 Tài liệu hệ thống 112

5.2.3 Bước 1.3 Thang đo đánh giá rủi ro 113

5.2.4 Bước 2.1 Xác định tài sản 114

5.2.5 Bước 3.1 Xác định yêu cầu 116

5.2.6 Bước 3.2 Định giá tài sản 117

5.2.7 Bước 4.1 Xác định các mối đe dọa và điểm yếu 118

5.2.8 Bước 4.2 Mức độ rủi ro 119

5.2.9 Bước 5.1 Các rủi ro của hệ thống 121

5.2.10 Bước 6.1 Tùy chọn xử lý rủi ro 122

5.2.11 Bước 6.2 Lựa chọn mục tiêu kiểm soát và các kiểm soát 124

5.2.12 Bước 6.3 Giảm nhẹ rủi ro 126

5.2.13 Bước 7.1 hướng dẫn tính ứng dụng của kiểm soát 127

5.2.14 Bước 8.1 Thực thi các kiểm soát đã chọn 129

TỔNG KẾT CHƯƠNG 131

KẾT LUẬN 132

1 Các nội dung đã hoàn thành trong luận văn 132

2 Các đóng góp khoa học 132

3 Hướng phát triển luận văn 133

TÀI LIỆU THAM KHẢO 135

TÓM TẮT LUẬN VĂN 136

THESIS SUMARY 137

PHỤ LỤC 1 KHẢO SÁT THỰC TRẠNG QUẢN LÝ RỦI RO AN TOÀN VÀ CHỊU LỖI DỊCH VỤ WEB: KHUNG CÂU HỎI BẮT BUỘC 138

PHỤ LỤC 2 KHẢO SÁT THỰC TRẠNG QUẢN LÝ RỦI RO AN TOÀN VÀ CHỊU LỖI DỊCH VỤ WEB: KHUNG CÂU HỎI TÙY CHỌN 151

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

Hình 1.1 Kiến trúc dịch vụ Web 15

Hình 1.2 Cấu trúc WSDL 17

Hình 1.3 Cấu trúc message SOAP 20

Hình 1.4 Các thành phần cần thiết trong một web service và mối quan hệ giữa các thành phần 23

Hình 2.1 Quy trình phương pháp đánh giá rủi ro 33

Hình 2.2 Các điểm hành động giảm nhẹ rủi ro 51

Hình 2.3 Biểu đồ phương pháp giảm nhẹ rủi ro (Risk Mitigation Methodology Flowchart) 54

Hình 2.4 Các kiểm soát kỹ thuật 56

Hình 2.5 Các kiểm soát đã thực thi và rủi ro dư thừa 63

Hình 3.1 Vòng đời thực thi dịch vụ Web 70

Hình 4.1 Quy trình quản lý rủi ro an toàn dịch vụ Web 76

Hình 4.2 Hành động xử lý rủi ro 91

Hình 5.1 Các chức năng chính của hệ thống 106

Hình 5.2 Thu thập thông tin hệ thống 107

Hình 5.3 Các rủi ro của hệ thống 108

Hình 5.4 Các quyết định quản lý rủi ro 109

Hình 5.5 Thực thi kiểm soát 110

Hình 5.6 Bước 1.1 Xác định phạm vi hệ thống 112

Nhiệm vụ: đưa ra các tài liệu được sinh ra bởi hệ thống 112

Bước 5: Nếu cần thiết, xóa bất kỳ tài liệu khỏi “Danh sách tài liệu đã chọn” bằng cách chọn tài liệu và nhấp vào nút "Xóa tài liệu" 112

Hình 5.7 Bước 1.2 Tài liệu hệ thống 113

Hình 5.8 Bước 1.3 Thang đo đánh giá rủi ro 114

Hình 5.9 Bước 2.1 Xác định tài sản 115

Hình 5.10 Bước 3.1 Xác định yêu cầu 116

Hình 5.11 Bước 3.2 Định giá tài sản 118

Hình 5.12 Bước 4.1 Xác định các mối đe dọa và điểm yếu 119

Hình 5.13 Bước 4.2 Mức độ rủi ro 121

Hình 5.14 Bước 5.1 Các rủi ro của hệ thống 122

Hình 5.15 Bước 6.1 Tùy chọn xử lý rủi ro 124

Hình 5.16 Bước 6.2 Lựa chọn mục tiêu kiểm soát và các kiểm soát 125

Hình 5.17 Bước 6.3 Giảm nhẹ rủi ro 127

Hình 5.18 Bước 7.1 hướng dẫn tính ứng dụng của kiểm soát 129

Hình 5.19 Bước 8.1 Thực thi các kiểm soát đã chọn 130

DANH MỤC CÁC BẢNG

Bảng 2.1 Tích hợp quản lý rủi ro vào trong SDLC 29

Bảng 2.2 Các tổn hại do con người: 37

Bảng 2.3 Vulnerability/Threat Pairs 39

Bảng 2.4 Tiêu chuẩn an toàn 42

Bảng 2.5 Xác định khả năng xảy ra 44

Bảng 2.6 Xác định độ lớn của tác động 46

Bảng 2.7 Ma trận mức độ rủi ro 47

Bảng 2.8 Tỷ lệ rủi ro và các hành động cần thiết 48

Bảng 4.1 Sự liên kết giữa hệ thống quản lý an toàn thông tin và quy trình quản lý rủi ro an toàn dịch vụ Web 78

DANH MỤC CÁC TỪ VIẾT TẮT

STT Từ viết tắt Giải nghĩa

1 FT Fault Tolerant

2 HTML Hyper Text Markup Language

3 GUI Graphical User Interface

4 NVP N- Version Programming

5 NFP Non – Functional Property

6 SOAP Simple Object Access Protocol

7 XML eXtensible Markup Language

8 W3C World Wide Web Consortium

9 WS Web Service

MỞ ĐẦU

1 Tính cấp thiết của đề tài

Quản lý rủi ro là một vấn đề quan trọng trong việc phát triển các ứng dụng

về công nghệ thông tin Với việc phát triển như vũ bão hiện nay của công nghệ Web thì việc giảm thiểu rủi ro khi khai thác các dịch vụ Web là một vấn đề cấp thiết Bên cạnh đó, việc duy trì các tiêu chí mô tả chất lượng dịch vụ (NFP) như bảo mật, chịu lỗi, v.v là một vấn đề rất được các nhà cung cấp dịch vụ quan tâm

Trên thế giới đã có nhiều nghiên cứu về quản lý rủi ro cũng như về các tiêu chí NFP (Non-Funtional Property) cho phần mềm nói chung và cho các dịch vụ nói riêng Tuy nhiên, hiện chưa có một nghiên cứu cụ thể về mối quan hệ tương hỗ giữa hai vấn đề này Do không đánh giá được mức độ ảnh hưởng của các tiêu chí NFP đến mức độ rủi ro khi khai thác các dịch vụ Web nên rất khó có thể đưa ra các mô hình quản lý rủi ro phù hợp cho các dịch vụ Web có các tiêu chí NFP khác nhau

3 Nhiệm vụ nghiên cứu

• Nghiên cứu về các dịch vụ web

• Nghiên cứu về quản lý rủi ro

• Tìm hiểu các tiêu chí NFP của các dịch vụ Web : chịu lỗi và an toàn

• Phân tích đánh giá sự ảnh hưởng của các tiêu chí trên đến việc quản lý rủi

ro đối với các dịch vụ web

• Khảo sát hiện trạng quản lý rủi ro về an toàn và chịu lỗi của dịch vụ Web tại các cơ quan, tổ chức, doanh nghiệp tại Việt Nam

• Xây dựng mô hình quản lý rủi ro phù hợp và cài đặt thử nghiệm

4 Phương pháp nghiên cứu

Phương pháp nghiên cứu là tìm hiểu rộng tất cả các nghiên cứu đã có trên thế giới về quản lý rủi ro an toàn dịch vụ Web Với những kiến thức đó ta sẽ tổng hợp, phân tích và đưa ra các đề xuất cụ thể Những đề xuất, kỹ thuật đó sẽ được kiểm nghiệm bằng cách xây dựng ứng dụng thử nghiệm chứng minh tính khả thi

và đúng đắn của nó

5 Phạm vi nghiên cứu

Phạm vi nghiên cứu nằm trong vấn đề quản lý rủi ro của dịch vụ Web theo các tiêu chí NFP Tập các tiêu chí NFP rất đa dạng và phức tạp Ngoài ra các kỹ thuật quản lý rủi ro cho dịch vụ Web còn là lĩnh vực khá mới mẻ ở Việt Nam Chính vì vậy mục tiêu của luận văn là đặt phạm vi nghiên cứu ở mức tìm hiểu và đưa ra những kiến thức nền tảng cho việc áp dụng kỹ thuật quản lý rủi ro cho dịch

vụ Web theo tiêu chí chịu lỗi và an toàn đưa ra được đầy đủ toàn diện được tất cả các tiêu chí NFP khác

6 Cấu trúc luận văn

Với mục tiêu như trên luận văn sẽ được trình bày theo bố cục như sau:

• Chương 1: Tổng quan về dịch vụ Web Chương này đặt vấn đề và trình bày một số khái niệm và các phương pháp, kỹ thuật chung trong xây dựng dịch

• Chương 4: Quản lý rủi ro cho dịch vụ Web theo tiêu chí an toàn Chương này đưa ra một quy trình giúp quản lý rủi ro an toàn dịch vụ Web

• Chương 5: Khảo sát thực trạng và xây dựng chương trình quản lý rủi ro thử nghiệm theo tiêu chí an toàn và chịu lỗi đối với dịch vụ Web Chương này nghiên cứu về tình hình quản lý rủi ro an toàn và chịu lỗi dịch vụ Web tại các cơ quan, tổ chức, và doanh nghiệp tại Việt Nam để hướng tới xây dựng một giải pháp quản lý rủi ro an toàn và chịu lỗi dịch vụ Web hiệu quả cho

các đơn vị đó Sau đó, luận văn xây dựng một ứng dụng thử nghiệm quy

trình quản lý rủi ro an toàn dịch vụ Web

CHƯƠNG 1 TỔNG QUAN VỀ DỊCH VỤ WEB

Hiện nay, dịch vụ Web đang phát triển mạnh mẽ và cung ứng cho các nhu cầu thiết yếu về nhiều mặt của đời sống xã hội như thương mại điện tử, e-learning, giải trí, quảng cáo … Vậy dịch vụ Web là gì? Dịch vụ Web có cấu trúc như thế nào? Dịch vụ Web gồm các thành phần nào? Các lợi ích cũng như rủi ro đối với dịch vụ Web là gì? Dịch vụ Web bị tấn công dưới các hình thức nào? Các nội dung đó sẽ được sáng tỏ trong chương này

1.1 Khái niệm dịch vụ Web

Có nhiều định nghĩa về dịch vụ Web, từ định nghĩa theo khoa học công nghệ đến định nghĩa một cách đơn giản Ví dụ, tổ chức W3C (World Wide Web Consortium) – tổ chức thiết lập chuẩn cho dịch vụ Web đưa ra định nghĩa: “Một dịch vụ Web là một hệ thống phần mềm được nhận dạng bởi một URI trong đó có các giao diện dùng chung và các kết nối được định nghĩa và mô tả qua XML Định nghĩa của W3C có thể được nhận biết qua một số hệ thống phần mềm Các hệ thống phần mềm này có thể tương tác với dịch vụ Web thông qua quy cách đã được định nghĩa, sử dụng thông điệp cơ sở XML truyền qua giao thức mạng” Một định nghĩa đơn giản và có lẽ hữu ích hơn đó là: “Một dịch vụ Web là một ứng dụng phần mềm, có thể truy cập được trên Web thông qua URL, nó được truy cập bởi các máy khách qua sử dụng giao thức XML cơ sở, như là Simple Object Access Protocol (SOAP), gửi và nhận thông tin qua các giao thức mạng, như là HTTP Các máy trạm truy cập một ứng dụng dịch vụ Web qua các giao diện và kết nối của ứng dụng đó – thể hiện qua sử dụng XML, như là một Web Services Definition Language (WSDL) file”

Dịch vụ Web là kết quả của cuộc cách mạng tất yếu của Web Đầu tiên, Web bao gồm nhiều site gồm các trang HTML đơn giản Sau đó, các ứng dụng Web động sinh ra các trang HTML giống nhau Ví dụ, một trang Web bản đồ ban đầu chỉ đưa ra các liên kết tĩnh để kết nối các thành phố và địa điểm Sau đó, trang Web này trở thành một ứng dụng bản đồ Web đưa ra các chỉ dẫn lái xe, bản đồ theo yêu cầu của khách hàng, và các vấn đề tương tự như thế Mặc dù đã mở rộng

về tính năng, các ứng dụng Web vẫn bị giới hạn bởi ràng buộc về tính năng GUI của các trang HTML Dịch vụ Web vượt qua giới hạn này, chúng chia tách trang Web hay ứng dụng từ các trang HTML và GUI của chúng Thay vào đó, dịch vụ được thể hiện trong XML và sẵn dùng thông qua Web bởi XML Kết quả , trang Web bản đồ ở trên có thể mở rộng tính năng của nó để cung cấp cho một dịch vụ Web mà các doanh nghiệp khác có thể sử dụng để đưa ra các định hướng cho các địa điểm về văn phòng của các doanh nghiệp đó, tích hợp với hệ thống định vị toàn cầu, và các vấn đề tương tự như vậy

Dịch vụ Web, hay đơn giản hơn là các dịch vụ, xây dựng trên nền kiến thức lấy từ nhiều môi trường tính toán phân tán đã có (như là CORBA và Java Remote Method Invocation) để cho phép trao đổi thông tin và thao tác của các phần giữa các ứng dụng đến các ứng dụng dịch vụ Web đưa ra một con đường chuẩn cho các ứng dụng mở rộng tính năng của nó trên nền Web hay trao đổi thông tin với các ứng dụng khác trên mạng mà không quan tâm đến sự thực thi của các ứng dụng, ngôn ngữ lập trình hay nền tảng máy tính

Dịch vụ Web có thể cung cấp một giải pháp cho một doanh nghiệp để mở rộng giao dịch, tăng tiện ích khi xử lý kinh doanh và để cải thiện kinh nghiệm về khách hàng của doanh nghiệp đó Bằng cách gộp các dịch vụ của doanh nghiệp với sự chào hàng của các đối tác, cả doanh nghiệp và đối tác có thể mở rộng khả năng và cơ sở kinh doanh WS không chỉ giúp tự động hóa xử lý kinh doanh mà

nó còn có thể tương tác với các dịch vụ bên ngoài như là thẻ tín dụng và các dịch

vụ vận chuyển Như vậy, khách hàng được mời chào tốt hơn: thêm nhiều lựa chọn cùng với nhiều tính năng mềm dẻo hơn

Dịch vụ Web dựa trên kiến trúc hướng dịch vụ, đó là kiến trúc đẩy mạnh tính tái sử dụng của phần mềm bằng cách tạo ra các lớp dịch vụ có thể tái sử dụng được Kiến trúc hướng đối tượng truyền thống đẩy mạnh tính tái sử dụng bằng cách sử dụng lại các lớp và các đối tượng Sau đó, kiến trúc hướng thành phần nhấn mạnh vào sử dụng các thành phần phần mềm như là các thực thể tái sử dụng Các thành phần này bao gồm một tập các lớp liên quan, các tài nguyên và các thông tin cấu hình Kiến trúc hướng thành phần duy trì một cách thức thiết kế hệ thống phần mềm mạnh mẽ; tuy nhiên, chúng không xác định các vấn đề phát sinh thêm trong các môi trường doanh nghiệp hiện tại Ngày nay, các môi trường doanh nghiệp là khá phức tạp do sử dụng vô số phần mềm và nền tảng phần cứng, trao đổi thông tin phân tán trên nền tảng mạng, tích hợp các ứng dụng doanh nghiệp … Kiến trúc hướng dịch vụ xác định các vấn đề này bằng cách sử dụng một dịch vụ như là một thực thể tái sử dụng Các dịch vụ có đặc trưng là thô cứng hơn các thành phần, và chúng tập trung vào tính năng được đưa ra qua các giao diện Các dịch vụ trao đổi thông tin với nhau và với máy khách đầu cuối thông qua các giao diện đã được định nghĩa và biết đến Quá trình trao đổi thông tin có phạm vi từ chuyển tin nhắn đơn giản giữa các dịch vụ cho đến các kịch bản phức tạp trong đó một tập các dịch vụ cùng nhau hoàn thành một mục tiêu chung Kiến trúc này cho phép các máy khách trên mạng có thể gọi các tính năng của dịch vụ thông qua các giao diện mở ra của dịch vụ

Trong kiến trúc hướng dịch vụ :

• Dịch vụ thực thi lớp business logic và đưa ra qua các giao diện

• Đăng ký – tại đó dịch vụ đưa ra giao diện của nó để cho phép máy khách sử dụng dịch vụ

• Các máy trạm: (bao gồm các máy có thể tự phục vụ) – khám phá dịch vụ bằng cách sử dụng đăng ký và truy cập dịch vụ trực tiếp thông qua các giao diện mở

Một thuận lợi lớn của kiến trúc hướng dịch vụ đó là nó cho phép sự pháp triển của các cặp ứng dụng (loosely-coupled application) đó là có thể phân tán và truy cập được thông qua mạng Để sử dụng kiến trúc này, chúng ta cần:

• Cơ chế cho phép các máy khách đăng ký và truy cập dịch vụ

• Cơ chế cho phép các dịch vụ khác nhau đăng ký và một cách thức cho các máy khách tìm kiếm đăng ký cho các dịch vụ Dịch vụ Web được dựa trên kiến trúc trong đó dịch vụ có thể được đặt trên mạng và vị trí của nó là trong suốt, qua đó các máy khách có thể tự động khám phá ra một phần dịch vụ mà họ muốn sử dụng

• Cơ chế cho các dịch vụ mở ra các giao diện thân thiện và một con đường để các máy khách truy cập vào các giao diện đó

Một điểm lưu ý quan trọng đó là dịch vụ Web hỗ trợ rất mạnh bằng cách ảo hóa toàn bộ các người chơi chính trong vũ đài Web (Web arena) Sự hỗ trợ ảo này bảo đảm rằng công nghệ dịch vụ Web đang hiện hữu và sự chấp nhận được của nó

sẽ trở nên rộng rãi Khác với các môi trường phân tán truyền thống, dịch vụ Web nhấn mạnh tính thao tác giữa các phần Dịch vụ Web không phụ thuộc vào một ngôn ngữ lập trình cụ thể nào, trong khi đó các môi trường truyền thống thường giới hạn ở một ngôn ngữ lập trình nào đó

Tương tự như vậy, do chúng có thể dễ dàng giới hạn bởi một số cơ chế vận chuyển, dịch vụ Web đưa ra tính khả chuyển hơn trong việc lựa chọn các cơ chế này Hơn nữa, không giống như các môi trường lập trình truyền thống, dịch vụ Web thường không giới hạn bởi các máy khách khác nhau hay nền tảng của máy chủ Nhờ vào XML, dịch vụ Web nhận được một số thuận tiện hơn, từ khi XML làm cho dịch vụ Web có thể sử dụng tài liệu thông qua môi trường không đồng nhất

Dịch vụ Web, bằng cách xây dựng dựa trên các chuẩn Web đã có, có thể được sử dụng mà không cần yêu cầu sự thay đổi bên trong nền tảng cơ sở của Web Tuy nhiên, trong khi chúng có thể thân thiện hơn các môi trường tính toán truyền thống, thì dịch vụ Web cũng không dự định sẽ tiện ích hơn trong việc xử lý thời gian và không gian

- Tầng mô tả dịch vụ (Service Description) với công nghệ chuẩn là WSDL và XML WSDL là một ngôn ngữ mô tả giao tiếp và thực thi dựa trên XML Web service sử dụng ngôn ngữ WSDL để truyền các tham số và các loại dữ liệu cho các thao tác, chức năng mà web service cung cấp

- Tầng dịch vụ (Service): cung cấp các chức năng của service

- Tầng đăng ký dịch vụ (Service Registry) với công nghệ chuẩn là UDDI UDDI dùng cho cả người dùng và SOAP server, nó cho phép đăng ký dịch vụ để người dùng có thể gọi thực hiện service từ xa qua mạng, hay nói cách khác một service cần phải được đăng ký để cho phép các client có thể gọi thực hiện

- Bên cạnh đó để cho các service 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 giúp tăng cường tính bảo mật, an toàn và toàn vẹn thông tin khi sử dụng dịch vụ

1.3 Các công cụ xây dựng dịch vụ Web

1.3.1 XML– Extensible Markup Language

XML do W3C đề ra và được phát triển từ SGML XML là một ngôn ngữ mô tả văn bản với cấu trúc do người sử dụng định nghĩa.Về hình thức XML có ký pháp tựa như HTML nhưng không tuân theo một đặc tả quy ước như HTML Người sử dụng hay các chương trình có thể quy ước định dạng các tag XML để giao tiếp với nhau.Thông tin cần truyền tải được chứa trong các tag XML,ngoài ra không chứa bất cứ thông tin nào khác về cách sử dụng hay hiển thị những thông tin ấy

Do web service là sự kết hợp của nhiều thành phần khác nhau, do đó web services

sử dụng các tính năng và đặc trưng của các thành phần này để giao tiếp với nhau

Vì vậy XML là một công cụ chính yếu để giải quyết vấn đề này Từ kết qủa này, các ứng dụng tích hợp vĩ mô tăng cường sử dụng XML Nhờ có khả năng tổng hợp này mà XML đã trở thành kiến trúc nền tảng cho việc xây dựng web service Web services tận dụng khả năng giải quyết vấn đề của các ứng dụng lớn trên các

hệ điều hành khác nhau cho chúng giao tiếp với nhau Yêu cầu này được đáp ứng với lập trình với Java, một ngôn ngữ viết một lần sử dụng mọi nơi là một chọn lựa thích hợp cho phát triển web services

1.3.2 WSDL - Web Services Description Language

WSDL định nghĩa cách mô tả web service theo cú pháp tổng quát XML, bao gồm các thông tin:

Một WSDL hợp lệ gồm có hai phần:

- Phần giao diện mô tả giao diện và giao thức kết nối

- Phần thi hành mô tả thông tin để truy xuất service

Cả 2 phần trên sẽ được lưu trong 2 tập tin XML, bao gồm:

- Tập tin giao diện service (cho phần 1)

- Tập tin thi hành service (cho phần 2)

Hình 1.2 Cấu trúc WSDL

1.3.2.1 Tập tin giao diện - Service Interface

WSDL mô tả 5 loại thông tin chính bao gồm: import, types, message, portType, binding

a Types:WSDL định nghĩa các kiểu dữ liệu của thông điệp gửi

WSDL định nghĩa bốn kiểu thao tác mà một cổng có thể hỗ trợ:

- One-way: cổng nhận một message, message đó là message nhập

- Request-response: cổng nhận một message và gửi một message phản hồi

- Solicit-response: cổng gửi một message và nhận về một message

- Notification: cổng gửi một message, message đó là message xuất

Mỗi kiểu thao tác có cú pháp biến đổi tùy theo: thứ tự của các message nhập, xuất

và lỗi

Ví dụ:

<wsdlDefinitions >

<wsdl:operation name="nmtoken" parameterOrder="nmtokens">

<wsdl:input name="nmtoken"? message="qname"/>

<wsdl:output name="nmtoken"? message="qname"/>

<wsdl:fault name="nmtoken" message="qname"/>*

- Mỗi một kết hợp tham chiếu đến một loại cổng; một kiểu cổng (portType)

có thể được sử dụng trong nhiều mối kết hợp Tất cả các thao tác định nghĩa bên trong kiểu cổng phải nằm trong phạm vi mối kết hợp

1.3.2.2 Tập tin thi hành - Service Implementation

WSDL mô tả 2 loại thông tin chính bao gồm: service và port

a Dịch vụ (Service): Nó sẽ thực hiện những gì đã được định nghĩa trong tập tin giao diện và cách gọi web services theo thủ tục và phương thức nào:

1.3.2.3 WSDL API

WSDL4J là một dự án nguồn mở , hiện tại có một WSDL Java API được gọi là WSDL4J Bộ WSDL4J cung cấp cho chúng ta các hàm API để thực hiện việc tạo WSDL dễ dàng hơn so với cách sử dụng trực tiếp cú pháp theo dạng tag như trên Tên gói chứa các API này là javax.wsdl

1.3.3.UDDI - Universal Description, Discovery and Intergration

Để 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 dịch vụ và biết được đối tượng cung cấp dịch vụ UDDI định nghĩa một số thành phần cho biết trước các thông tin này để cho phép các client truy tìm và nhận lại những thông tin yêu cầu sử dụng web services

Cấu trúc UDDI:

Cấu trúc UDDI gồm các thành phần:

- Trang trắng -White pages: chứa thông tin liên hệ và các định dạng chính yếu của web services, chẳng hạn tên giao dịch, địa chỉ, … Những thông tin này cho phép các đối tượng khác xác định được service

- Trang vàng -Yellow pages: chứa thông tin mô tả web services theo những chủng loại khác nhau Những thông tin này cho phép các đối tượng thấy web services theo từng chủng loại của 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 services Các đối tượng dựa vào đặc điểm của web services để tìm kiếm

- Loại dịch vụ - tModel: chứa các thông tin về loại dịch vụ sử dụng

Những UDDI registry hiện có:

- UDDI Business Registry: bộ đăng ký được bảo trì bởi Microsoft, IBM đặc điểm của bộ đăng ký này là nó phân tán về mặt vật lý

- IBM Test Registry: bộ đăng ký cho những người phát triển để thử nghiệm công nghệ và kiểm tra những service của họ

- Private registries IBM ships: bộ đăng ký UDDI cá nhân

1.3.4 SOAP - Simple Object Accesss Protocol

Đến đây chúng ta đã hiểu được web services là như thế nào, nó được công

bố và truy xuất ở đâu Nhưng chúng ta vẫn còn một vấn đề khá quan trọng đó là: làm thế nào chúng ta truy xuất dịch vụ khi tìm thấy? Câu trả lời là web servicves có thể truy xuất bằng một giao thức là Simple Object Access Protocol – SOAP Nói cách khác chúng ta có thể truy xuất đến UDDI registry bằng các lệnh gọi hoàn toàn theo kiểu SOAP

SOAP là một giao thức giao tiếp có cấu trúc như XML và mã hóa thành định dạng chung cho các ứng dụng trao đổi với nhau Ý tưởng bắt đầu từ Microsoft và phần mềm Userland, trải qua nhiều lần thay đổi, hiện tại là phiên bản SOAP 1.2 với nhiều ưu điểm vuợt trội hơn bản SOAP 1.1 SOAP được

xem như là cấu trúc xương sống của các ứng dụng phân tán xây dựng từ nhiều ngôn ngữ, hệ điều hành khác nhau

1.3.4.1 Đặc trưng SOAP

SOAP có những đặc trưng sau:

- SOAP được thiết kế đơn giản và dễ mở rộng

- Tất cả các message SOAP đều được mã hóa sử dụng XML

- SOAP sử dùng giao thức truyền dữ liệu riêng

- Không có garbage collection phân tán, và cũng không có cơ chế tham chiếu Vì thế SOAP client không giữ bất kỳ một tham chiếu đầy đủ nào về các đối tượng ở xa

- SOAP không bị ràng buộc bởi bất kỳ ngôn ngữ lập trình nào hoặc công nghệ nào

Vì những đặc trưng này, nó không quan tâm đến công nghệ gì được sử dụng để thực hiện miễn là người dùng sử dụng các message theo định dạng XML Tương

tự, service có thể được thực hiện trong bất kỳ ngôn ngữ nào, miễn là nó có thể xử

lý được những message theo định dạng XML

1.3.4.2 Cấu trúc một message theo dạng SOAP

Cấu trúc một message theo dạng SOAP được mô tả như hình dưới đây:

Hình 1.3 Cấu trúc message SOAP

Message theo dạng SOAP là một văn bản XML bình thường bao gồm các phần

- 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à phản hồi

- Phần tử phát sinh lỗi (Fault) cung cấp thông tin lỗi xảy ra trong qúa trình xử

lý thông điệp

Trong trường hợp đơn giản nhất, phần thân của SOAP message gồm có:

- Tên của message

- Một tham khảo tới một thể hiện service

- Một hoặc nhiều tham số mang các giá trị và mang các tham chiếu Có 3 kiểu thông báo:

o Request messages: với các tham số gọi thực thi một service

o Response messages với các tham số trả về, được sử dụng khi đáp ứng yêu cầu

o Fault messages báo tình trạng lỗi

1.3.4.3 Những kiểu truyền thông

SOAP hỗ trợ hai kiểu truyền thông khác nhau:

- Remote procedure call (RPC): cho phép gọi hàm hoặc thủ tục qua mạng Kiểu này được khai thác bởi nhiều web service và có nhiều trợ giúp

- Document: được biết như kiểu hướng message: kiểu này cung cấp một lớp thấp của sự trừu tượng hóa, và yêu cầu người lập trình nhiều hơn khi làm việc

Các định dạng message, tham số, và lời gọi đến các API thì tương ứng trong RPC

và document là khác nhau Nên việc quyết định chọn cái nào tùy thuộc vào thời gian xây dựng và sự phù hợp của service cần xây dựng

- Những kiểu phức tạp, có hai loại là struct và array

Tất cả các phần tử và những định danh có trong mô hình dữ liệu SOAP thì được định nghĩa bằng namespace SOAP-ENC

1.3.4.5 Mã hóa

Trong những môi trường tính toán phân tán, mã hóa định nghĩa làm sao giá trị của dữ liệu trong ứng dụng có thể được dịch từ khuôn dạng nghi thức Khuôn dạng nghi thức cho những web service là XML, giả sử ở đây chúng ta giả thiết rằng service requestor và service provider phát triển trong Java Vì vậy, mã hóa SOAP là trong môi trường thực thi để làm thế nào chuyển đổi từ cấu trúc dữ liệu Java sang SOAP XML và ngược lại Một ánh xạ định nghĩa là mối quan hệ giữa một phần tử XML, một lớp Java, và một trong những loại mã hóa giới thiệu ở trên Một ánh xạ chỉ rõ làm cách nào, để khi đã mã hóa mà một phần tử XML đầu vào vẫn chuyển đổi được tới một lớp Java và ngược lại.Chúng ta quan tâm tới hai

thi SOAP nào cũng phải có một bảng chứa những mục ánh xạ, gọi là SOAPMappingRegistry

Nếu một kiểu dữ liệu được giả thiết sẽ được sử dụng dưới một loại mã hóa nhất định, thì một ánh xạ tương ứng phải tồn tại trong bộ đăng ký (registry) của môi trường thực thi SOAP đó Đa số các kiểu Java chuẩn cũng như JavaBeans đều mặc định là được hỗ trợ

Những kiểu dữ liệu không chuẩn (do tự định nghĩa) thì cần ánh xạ trên cả server và client

1.3.5 Tạo Web Service

Để tạo một web service chúng ta cần xây dựng các tầng cần thiết trong kiến trúc web service hay nói cách khác là xây dựng và thiết lập các thành phần trong các tầng đó, cụ thể là các thành phần SOAP, WSDL, UDDI, XML, trong đó:

- SOAP là giao thức nằm giữa tầng vận chuyển và tầng mô tả thông tin về dịch vụ, SOAP cho phép người dùng triệu gọi một service từ xa thông qua một message XML

- WSDL là một ngôn ngữ mô tả giao tiếp và thực thi dựa trên XML Web service sử dụng ngôn ngữ WSDL để truyền các tham số và các loại dữ liệu cho các thao tác, các chức năng mà web service cung cấp

- UDDI dùng cho cả người dùng và ̣ SOAP server, nó cho phép đăng ký dịch

vụ để người dùng có thể gọi thực thi các hàm, các chức năng của web service hay nói cách khác một service cần phải được đăng ký để cho phép các client có thể gọi thực hiện

- Bên cạnh đó chúng ta cũng phải quan tâm đến việc làm sao để cho các service có tính an toàn, toàn vẹn và bảo mật thông tin trong web services nhất là các service liên quan đến giao dịch thương mại và tài chính Chúng

ta sẽ tìm hiểu nội dung này trong các phần tiếp theo

Sơ đồ dưới đây cho chúng ta thấy rõ hơn về các thành phần cần thiết trong một web service và mối quan hệ giữa các thành phần

Hình 1.4 Các thành phần cần thiết trong một web service và mối quan hệ giữa các thành phần

1.4 Các lợi ích của dịch vụ Web

WS đang được phổ biến dựa vào các lợi ích mà chúng cung cấp Ở đây liệt kê một số lợi ích chính của WS:

• Tương thao tác giữa các phần trong môi trường không đồng nhất – Có

lẽ lợi ích chính của mô hình WS là nó cho phép các dịch vụ phân tán khác nhau có thể chạy trên nhiều nền tảng phần mềm, kiến trúc khác nhau và cho phép chúng có thể được viết lại bằng các ngôn ngữ lập trình khác nhau Khi các doanh nghiệp phát triển, theo thời gian, họ thêm các hệ thống và giải pháp yêu cầu thường xuyên các nền tảng khác nhau và thường không trao đổi thông tin với nhau Sau đó, do yêu cầu của sự đồng nhất hay sự dùng thêm các ứng dụng khác, việc cần thiết là gắn kết các chức năng tách biệt này Sức mạnh lớn nhất của WS là khả năng của WS trong việc cho phép

xử lý giữa các phần trong môi trường không đồng nhất Ngay sau khi các

hệ thống khác nhau được cho phép WS thì chúng có thể được sử dụng các dịch vụ để thao tác giữa các phần

• Các dịch vụ kinh doanh trên Web – Một doanh nghiệp có thể sử dụng

WS để thúc đẩy các thuận lợi của Web và các tính năng của nó Ví dụ, một doanh nghiệp có thể tạo ra các danh mục sản phẩm và hàng hóa tồn kho sẵn sàng cho các nhà cung cấp thông qua WS để đạt được sự quản lý theo dây chuyền cung cấp tốt hơn

• Sự tích hợp với các hệ thống đã có – Hầu hết các doanh nghiệp đều có

một lượng dữ liệu lưu trữ khổng lồ tại các hệ thống thông tin doanh nghiệp,

và cái giá để thay thế các hệ thống này là không hề nhỏ WS cho phép các

nhà phát triển ứng dụng doanh nghiệp tái sử dụng các tài sản thông tin đã

có này WS cung cấp cho các nhà phát triển một con đường chuẩn để truy cập tầng Middle-tier, và tích hợp chúng với các ứng dụng khác Thêm vào

đó, vì các dịch vụ này được cung cấp nhất quán nên các nhà phát triển không cần học các mô hình hay kiểu lập trình mới khi mà cần tích hợp

• Tự do lựa chọn – Các chuẩn WS đã mở ra một thị trường lớn cho các tool,

sản phẩm và công nghệ Điều này đưa cho các doanh nghiệp sự đa dạng trong chọn lựa và họ có thể lựa chọn cấu hình phù hợp nhất đối với yêu cầu ứng dụng của họ Các nhà phát triển có thể tăng cường năng suất của họ, thay vì phát triển giải pháp của chính họ, họ có thể lựa chọn từ các thành phần ứng dụng đã có sẵn trên thị trường Hơn nữa, các tool cung cấp khả năng nhanh gọn và dễ dàng hơn trong việc chuyển từ một cấu hình này sang cấu hình khác theo yêu cầu WS cũng cho phép tiêu chuẩn hóa các tool, do đó các tool phát triển có thể được các tool mới kế thừa, từ các nhà cung cấp máy chủ hay các nhà phát triển tool thứ 3

• Hỗ trợ nhiều loại máy khách – Khi đối tượng chính của WS là tăng cường

tính năng thao tác giữa các phần, mở rộng các ứng dụng và dịch vụ đã tồn tại, thì WS cũng tăng phạm vi để vươn tới các loại máy khách khác nhau Điều này không quan tâm đến nền tảng của các máy khách: không vấn đề

gì khi mà các máy trạm được xây dựng dựa trên nền tảng Java hay Microsoft hay thậm chí là nó dựa trên nền tảng không dây Trước mắt, một

WS có thể giúp bạn mở rộng ứng dụng và dịch vụ tới một tập lớn các loại máy khách

• Năng suất lập trình – Để tăng năng suất trong kinh tế thông tin, yêu cầu

khả năng phát triển và triển khai các ứng dụng theo thời gian Các ứng dụng phải được ra thật nhanh từ khuôn mẫu đến sản phẩm và bắt buộc phải tiếp tục mở ra ngay cả sau khi chúng đã được đặt vào trong sản phẩm Năng suất được tăng lên khi đội phát triển ứng dụng có một chuẩn để truy cập các dịch vụ yêu cầu bởi các ứng dụng đa tầng và chuẩn để hỗ trợ được sự đa dạng của các máy khách WS, bằng cách tạo ra một chuẩn lập trình chung, trợ giúp tăng cường năng suất lập trình Theo sự xuất hiện của WS, các nhà phát triển lập trình trong môi trường tính toán phân tán đã dựa vào tập gồm nhiều loại khác nhau các công nghệ không thường xuyên tương thích Các nhà phát triển nỗ lực để gắn kết các hệ thống đầu cuối khác nhau, như là cả các hệ thống quản lý dữ liệu chuẩn và tùy chọn, và các xử lý giao dịch, với các công nghệ Web truyền thống, nhưng đã có quan hệ với vô số các mô hình lập trình Bởi vì WS giới thiệu một chuẩn thông dụng trên Web, các nhà cung cấp, trong sự quan tâm đến việc chống đỡ cạnh tranh, đã phù hợp hơn trong việc phát triển các tool và công nghệ tốt hơn Các tool và công nghệ này sẽ thu hút các nhà phát triển vì chúng nhấn mạnh việc tăng năng suất lập trình

Phát triển các ứng dụng cũng trở nên phức tạp hơn bởi yêu cầu rằng một ứng dụng riêng biệt hỗ trợ một kiểu riêng biệt máy khách hay một vài kiểu đồng thời

Do đó WS đưa ra khả năng thao tác giữa các phần, đơn giản hóa khía cạnh này của tiến trình phát triển ứng dụng.

TỔNG KẾT CHƯƠNG

Chương này đã đưa ra những nghiên cứu cơ bản về dịch vụ Web Dịch vụ Web là sự kết hợp các máy tính cá nhân với các thiết bị khác, các cơ sở dữ liệu và các mạng máy tính để tạo thành một cơ cấu tính toán ảo mà người sử dụng có thể làm việc thông qua các trình duyệt mạng

Dịch vụ Web dựa trên kiến trúc hướng dịch vụ, đó là kiến trúc đẩy mạnh tính tái sử dụng của phần mềm bằng cách tạo ra các lớp dịch vụ có thể tái sử dụng được Kiến trúc hướng đối tượng truyền thống đẩy mạnh tính tái sử dụng bằng cách sử dụng lại các lớp và các đối tượng Sau đó, kiến trúc hướng thành phần nhấn mạnh vào sử dụng các thành phần phần mềm như là các thực thể tái sử dụng Chương này cũng đã nêu rõ những lợi ích của dịch vụ Web Cụ thể đó là:

• Tương thao tác giữa các phần trong môi trường không đồng nhất

• Các dịch vụ kinh doanh trên Web

• Khả năng tích hợp với các hệ thống đã có

• Tự do lựa chọn

• Hỗ trợ nhiều loại máy khách

• Tăng năng suất lập trình

Vì mục tiêu của chúng ta là quản lý rủi ro đối với các dịch vụ Web nên chương tiếp theo sẽ nghiên cứu đề xuất quy trình quản lý rủi ro đối với dịch vụ Web

CHƯƠNG 2 QUẢN LÝ RỦI RO CHO CÁC DỊCH VỤ WEB

2.1 Giới thiệu

Các tổ chức sử dụng các hệ thống để xử lý thông tin nhằm có được hỗ trợ tốt hơn cho các nhiệm vụ của các tổ chức đó, quản lý rủi ro đóng một vai trò quyết định trong việc bảo vệ tài nguyên thông tin của các tổ chức

Quy trình quản lý rủi ro hiệu quả là nhân tố quan trọng của một chương trình an toàn thông tin thành công Mục đích chính của quy trình quản lý rủi ro của một tổ chức nên để bảo vệ tổ chức và các khả năng của tổ chức đó để thực hiện được nhiệm vụ của nó, chứ không chỉ là bảo vệ các tài sản thông tin của tổ chức

đó Do đó, quy trình quản lý rủi ro không nên được xem như là một chức năng công nghệ được đưa ra bởi các chuyên gia công nghệ thông tin, những người quản

lý và vận hành hệ thống công nghệ thông tin, mà còn như là một chức năng quản

lý chủ yếu của tổ chức

2.2 Khái niệm quản lý rủi ro

Có nhiều khái niệm về rủi ro tùy theo từng lĩnh vực khác nhau Chúng ta xét đến khái niệm rủi ro của dịch vụ Web, tại đây, rủi ro là những nguy cơ mà dịch

vụ Web có thể bị gây hại Các rủi ro này tác động gây ra tính nguy hiểm, tính dễ bị tấn công của quá trình sử dụng dịch vụ Web, tính đến cả hai mặt xác suất xảy ra và ảnh hưởng của rủi ro Quản lý rủi ro dịch vụ Web là một quy trình bao gồm nhận dạng rủi ro, đánh giá rủi ro, và làm từng bước để giảm thiểu rủi ro đến một mức có thể chấp nhận được

Quản lý rủi ro dịch vụ Web bao gồm 3 quá trình: đánh giá rủi ro (risk assessment), giảm nhẹ rủi ro (risk mitigation), định giá và đánh giá lại các rủi ro (risk evaluation and assessment)

Quản lý rủi ro dịch vụ Web là quy trình cho phép các nhà quản lý IT cân bằng giữa các thao tác, chi phí kinh kế của sự bảo vệ và lợi ích qua bảo vệ dịch vụ Web để hỗ trợ tổ chức hoàn thành các nhiệm vụ của họ Quy trình này là không duy nhất đối với các môi trường dịch vụ Web, mà nó đa dạng trong việc ra quyết định trong mọi lĩnh vực của cuộc sống hiện tại Lấy ví dụ trong trường hợp của việc an toàn nhà ở Rất nhiều người quyết định triển khai một hệ thống an toàn nhà

ở và trả phí hàng tháng cho nhà cung cấp dịch vụ để cho các hệ thống này được theo dõi giúp bảo vệ tốt hơn các tài sản của họ Chắc chắn là các chủ nhà đã ước lượng giá cả của việc cài đặt hệ thống bảo vệ và theo dõi với giá trị được bảo vệ của các đồ đạc trong nhà và sự an toàn của gia đình

Người đứng đầu trong đơn vị của tổ chức phải chắc chắn rằng tổ chức có đầy đủ các tính năng cần thiết để hoàn thành các công việc của nó Người chịu trách nhiệm cho các công việc phải xác định khả năng an toàn mà các dịch vụ Web bắt buộc phải có để đưa ra mức độ hỗ trợ mong muốn trong quá trình đối mặt với các mối nguy hiểm trong thế giới thực Hầu hết các tổ chức có một ngân sách hạn hẹp cho an toàn IT; do đó, việc chi tiêu cho an toàn IT phải được xem trước

kỹ lưỡng như là các quyết định khác Một phương pháp quản lý rủi ro có cấu trúc tốt, khi được sử dụng hiệu quả có thể giúp cho việc quản lý nhận ra các kiểm soát thích hợp để đưa ra các tính năng an toàn thông tin cần thiết

2.3 Các rủi ro của dịch vụ Web

Rủi ro là sự kết hợp giữa mức độ nguy hiểm và tần xuất xảy ra hoặc có thể xảy ra Rủi ro = Mức độ nguy hiểm x Tần xuất có thể xảy ra

Một dịch vụ Web có thể gặp nhiều rủi ro theo liệt kê dưới đây:

• Rủi ro về mặt vật lý, như lửa, nước, phá hủy thiết bị …

• Các sự kiện tự nhiên về khí hậu, địa chấn, lũ lụt …

• Thiếu các dịch vụ cần thiết như mất điện, hỏng hóc của các thiết bị viễn thông …

• Nhiễu loạn do bức xạ như bức xạ điện từ, bức xạ nhiệt, xung điện từ …

• Gây hại thông tin như chặn các tín hiệu, gián điệp từ xa, ăn cắp tài liệu, ăn cắp thiết bị, can thiệp vào phần cứng, can thiệp vào phần mềm …

• Hỏng hóc kỹ thuật như các hỏng hóc, sự cố của thiết bị, sự cố phần mềm …

• Các hành động không cho phép như sử dụng thiết bị trái phép, sao chép phần mềm, xử lý dữ liệu trái phép …

• Gây hại các chức năng như lỗi khi sử dụng, lạm dụng quyền hạn …

Các rủi ro trên của một dịch vụ Web có thể bị gây ra bởi các nguồn dưới đây:

• Hacker, cracker

• Tội phạm máy tính

• Khủng bố

• Gián điệp công nghệ

• Người trong nội bộ

Khi xây dựng các ứng dụng trên nền tảng dịch vụ Web chúng ta cũng có thể gặp các rủi ro dưới đây:

• Mức độ kinh nghiệm an toàn thấp của một phần nhân viên phát triển phần mềm, điều đó dẫn đến ứng dụng có thể được viết ra mà không quan quan tâm đầy đủ đến an toàn hệ thống Trong tình huống đó, các cuộc tấn công gây tràn bộ đệm có thể dẫn đến phá hủy hệ thống

• Các vòng đời phát triển sản phẩm ngắn hạn, do đó thời gian phát triển tập trung toàn bộ vào việc thêm và thực thi các tính năng có thể nhìn thấy ngay hơn là tập trung vào kiểm tra và đảm bảo an toàn

• Các ứng dụng Internet có thể không được thực thi chính xác theo giao thức

và có thể chuyển thông tin mà thông tin đó có thể được sử dụng để gây hại cho hệ thống

• Trong tình huống một ứng dụng được thực thi chính xác theo giao thức, thì

sự phát triển mạnh mẽ của các giao thức mạng cũng gây ra các lỗ hổng trong chính các giao thức đó

• Các quản trị viên tạo lập và triển khai các ứng dụng trên các máy chủ Web của họ có tiềm ẩn các lỗi cấu hình với mỗi ứng dụng mà họ thêm vào

2.4 Tích hợp quản lý rủi ro dịch vụ Web vào vòng đời phát triển

hệ thống - SDLC (System Develop Life Circle)

Tối thiểu hóa mức độ ảnh hưởng tiêu cực đến một tổ chức và nhu cầu cần thiết cơ bản trong việc ra quyết định là các lý do chính của tổ chức để thực thi một quy trình quản lý rủi ro đối với dịch vụ Web Quản lý rủi ro hiệu quả bắt buộc phải được tích hợp toàn bộ vào trong SDLC Một SDLC của một dịch vụ Web có 5 pha: khởi tạo, phát triển, thi hành, duy trì (maintenance), và hủy bỏ Trong một số trường hợp, một dịch vụ Web có thể chiếm một vài pha trong cùng một thời điểm Tuy nhiên, phương pháp quản lý rủi ro trông giống như một pha SDLC trong đó quá trình đánh giá đang được kiểm soát Quản lý rủi ro dịch vụ Web là một quy trình lặp lại, nó có thể được thi hành trong mỗi một pha của SDLC và chỉ ra trong mỗi pha, quản lý rủi ro được thực hiện như thế nào

Bảng 2.1 Tích hợp quản lý rủi ro vào trong SDLC

Các pha SDLC Đặc điểm của pha SDLC Hỗ trợ từ các hoạt động quản

lý rủi ro dịch vụ Web

Pha 1 – Khởi

tạo Đưa ra sự cần thiết của dịch vụ Web và tài liệu hóa các

mục đích và phạm vi của hệ thống

Các rủi ro đã xác định được sử dụng để hỗ trợ phát triển các yêu cầu hệ thống, gồm cả các yêu cầu an toàn

dựng khác

Các rủi ro nhận ra được trong pha này có thể được sử dụng để

hỗ trợ việc phân tích an toàn dịch

vụ Web, điều này có thể đạt đến

độ cân bằng trong kiến trúc và thiết kế trong quá trình phát triển

hệ thống Pha 3 – Thực

Quy trình quản lý rủi ro dịch vụ Web hỗ trợ đánh giá sự thực thi của dịch vụ Web dựa vào các yêu cầu của hệ thống và môi

trường mô hình của nó Pha 4 – Hoạt

Pha 5 - Hủy bỏ Pha này có thể liên quan đến

sự sắp xếp của thông tin, bố trí của phần cứng, và phần mềm Các hoạt động có thể bao gồm: di chuyển, lưu trữ, loại bỏ hay phá hủy thông tin và giảm nhẹ các phần cứng và phần mềm

Các hoạt động quản lý rủi ro đang được thi hành đối với các thành phần hệ thống, nó sẽ được sẵn sàng hoặc thay thế để chắc chắn rằng phần cứng và phần mềm đang sẵn sàng hoạt động, các dữ liệu dư thừa được xử lý thích hợp, quá trình di trú hệ thống được kiểm soát an toàn và

• Giám đốc điều hành (Chief Information Officer - CIO) chịu trách nhiệm về

kế hoạch công nghệ thông tin, ngân sách và sự thực hiện tại một chi nhánh

có chứa các thành phần an toàn dịch vụ Web Các quyết định ở đây nên dựa vào một chương trình quản lý rủi ro hiệu quả

• Người quản lý thông tin và quản lý hệ thống (System and Information Owners) là người chịu trách nhiệm bảo đảm rằng các điều khiển thích hợp

đã chính xác hay chưa để hệ thống và dữ liệu của họ đạt được tính toàn vẹn, tin cẩn, và sẵn sàng có thể dùng được Thông thường người quản lý thông tin và quản lý hệ thống có trách nhiệm trong việc thay đổi các hệ thống công nghệ thông tin Do đó, họ thường phê duyệt các thay đổi trong hệ thống công nghệ thông tin (ví dụ: nâng cao hệ thống, các thay đổi chính trong phần cứng và phần mềm) Người quản lý thông tin và hệ thống phải

hiểu vai trò của họ trong quy trình quản lý rủi ro và hỗ trợ đầy đủ quy trình này

• Người quản lý chịu trách nhiệm cho các hoạt động kinh doanh và quy trình công nghệ thông tin (Business and Functional Managers) bắt buộc phải đóng một vai trò hiệu quả trong quy trình quản lý rủi ro Những người quản

lý là các cá nhân riêng lẻ với quyền lực và trách nhiệm về việc cân bằng các quyết định ban đầu để hoàn thành nhiệm vụ Sự liên quan của họ đến quy trình quản lý rủi ro cho phép đạt được an toàn thích hợp cho các dịch vụ Web, trong đó, nếu được quản lý thích hợp, không những sẽ mang lại sự hiệu quả của nhiệm vụ mà còn sử dụng tối thiểu các tài nguyên

• Người quản lý chương trình an toàn công nghệ thông tin và người chỉ huy

an toàn máy tính - ISSO (IT security program managers) chịu trách nhiệm

về khả năng an toàn của tổ chức, bao gồm cả quản lý rủi ro Do đó, họ đóng vai trò then chốt trong việc đưa ra một phương pháp thích hợp để trợ giúp nhận dạng, đánh giá và tổi thiểu hóa rủi ro của các hệ thống công nghệ thông tin hỗ trợ nhiệm vụ của tổ chức ISSO cũng đóng một vai trò trợ lý cốt yếu như là việc hỗ trợ người quản lý chính khẳng định được các thao tác này là cơ sở nền tảng để hoạt động

• Những người đang thực thi an toàn thông tin (IT Security Practitioners) (ví dụ: mạng máy tính, hệ thống, ứng dụng, quản trị cơ sở dữ liệu; các chuyên gia về máy tính; những người phân tích an toàn; những người tư vấn an toàn) là những người chịu trách nhiệm cho quá trình thực thi thích hợp của các yêu cầu an toàn trong các hệ thống công nghệ thông tin của họ Khi các thay đổi xuất hiện trong môi trường hệ thống công nghệ thông tin đã có (ví dụ: sự mở rộng khả năng kết nối mạng, thay đổi trong cơ sở hạ tầng đã có

và các chính sách của tổ chức, sự ra đời của các công nghệ mới), những người đang thực hiện an toàn thông tin phải hỗ trợ hay sử dụng quy trình quản lý rủi ro để nhận dạng và đánh giá các rủi ro tiềm năng mới và thực hiện các kiểm soát an toàn mới để bảo vệ các dịch vụ Web của họ

Nhân viên của tổ chức là những người sử dụng của các hệ thống công nghệ thông tin Sử dụng của các hệ thống công nghệ thông tin và dữ liệu dựa vào chính sách, hướng dẫn và luật lệ của tổ chức là yếu tố then chốt để giảm nhẹ rủi ro và bảo vệ các tài nguyên công nghệ thông tin của tổ chức Để tối thiểu hóa rủi ro đối với các hệ thống công nghệ thông tin, người sử dụng hệ thống và ứng dụng phải được huấn luyện về an toàn thông tin Do đó, những người huấn luyện an toàn công nghệ thông tin hay các chuyên gia về an toàn phải hiểu quy trình quản lý rủi

ro để họ có thể xây dựng một phương pháp dạy thích hợp và kết hợp chặt chẽ đánh giá rủi ro vào trong các chương trình dạy để truyền lại cho người dùng đầu cuối

2.6 Quy trình quản lý rủi ro cho dịch vụ Web

Quản lý rủi ro cho dịch vụ Web bao gồm 3 quá trình: đánh giá rủi ro (assessment), giảm nhẹ rủi ro (mitigation), định giá và đánh giá (evaluation & assessment)

2.6.1 Đánh giá rủi ro cho dịch vụ Web

Đánh giá rủi ro là bước đầu tiên trong quy trình quản lý rủi ro Kết quả của quy trình này giúp nhận dạng các kiểm soát thích hợp để giảm rủi ro trong quy trình giảm nhẹ rủi ro

Để xác định được khả năng có thể xảy ra của một sự kiện có hại trong tương lai, các mối đe dọa đến dịch vụ Web phải được phân tích cùng với tính dễ bị tấn công tiềm năng và các kiểm soát của dịch vụ Web

Phương pháp đánh giá rủi ro bao gồm 9 bước chính:

• Bước 1 – Mô tả hệ thống

• Bước 2 – Nhận dạng các mối đe dọa

• Bước 3 – Nhận dạng điểm yếu

• Bước 4 – Phân tích kiểm soát

• Bước 5 – Xác định khả năng xảy ra

• Bước 6 – Phân tích ảnh hưởng

• Bước 7 – Xác định rủi ro

• Bước 8 – Đưa ra kiểm soát

• Bước 9 – Tài liệu hóa kết quả

Các bước 2,3,4 và 6 có thể được đặt song song sau khi bước 1 đã hoàn thành Hình 2.9 mô tả các bước và đầu vào, đầu ra của các bước

Hình 2.1 Quy trình phương pháp đánh giá rủi ro

2.6.1.1 Bước 1: Mô tả hệ thống

Để đánh giá rủi ro cho dịch vụ Web, bước đầu tiên là xác định phạm vi cần đạt được Trong bước này, các giới hạn của dịch vụ Web được nhận biết, cùng với các tài nguyên và thông tin cấu thành hệ thống Mô tả dịch vụ Web, thiết lập phạm

vi của kết quả đánh giá rủi ro, vạch rõ các giới hạn về quyền hạn, và cung cấp các thông tin cần thiết (ví dụ: phần cứng, phần mềm, kết nối hệ thống, và người hỗ trợ) để xác định rủi ro

Phương pháp mô tả trong phần này có thể áp dụng để đánh giá các hệ thống tương quan với nhau

2.6.1.1.1 Các thông tin liên quan đến hệ thống

Nhận dạng rủi ro đối với dịch vụ Web yêu cầu sự am hiểu rõ ràng về môi trường xử lý của hệ thống Người quản lý đánh giá rủi ro dịch vụ Web phải thu thập thông tin liên quan đến hệ thống, các thông tin đó thường được phân loại như sau:

• Các yêu cầu về chức năng của dịch vụ Web

• Người dùng của hệ thống (ví dụ: người dùng hệ thống - người đưa ra các hỗ trợ kỹ thuật cho dịch vụ Web; người dùng ứng dụng – người sử dụng dịch

vụ Web để thực hiện các chức năng thương mại)

• Các chính sách an toàn hệ thống chủ yếu của dịch vụ Web(các chính sách của tổ chức, các yêu cầu liên bang, luật pháp, thực tiễn công nghệ)

• Kiến trúc an toàn hệ thống

• Cấu trúc liên kết mạng của hệ thống

• Bảo vệ các thông tin lưu trữ trong đó bảo vệ hệ thống và dữ liệu sẵn có, đảm bảo tính toàn vẹn và bảo mật

• Luồng thông tin gắn liền với dịch vụ Web (ví dụ: giao diện hệ thống, biểu

đồ tiến trình vào ra của hệ thống)

• Các điều khiển kỹ thuật được dùng đối với dịch vụ Web(ví dụ: sản phẩm an toàn đã có sẵn hay gắn thêm mà sản phẩm đó hỗ trợ nhận dạng và quản trị, điều khiển truy cập bắt buộc hay không bắt buộc, kiểm định, bảo vệ thông tin dư thừa, các phương pháp mã hóa)

• Các điều khiển quản lý sử dụng cho dịch vụ Web (ví dụ: các quy tắc hoạt động, kế hoạch an toàn)

• Các điều khiển hoạt động sử dụng đối với dịch vụ Web (ví dụ: an toàn nhân viên, sao lưu, sự việc xảy ra ngẫu nhiên, các thao tác thực hiện tiếp theo và phục hồi; bảo trì hệ thống; lưu trữ off-site; thiết lập tài khoản người dùng và

xóa bỏ các thủ tục; điều khiển sự phân chia các chức năng người dùng, như

là người dùng truy cập đặc quyền và người dùng truy cập thông thường)

• Môi trường an toàn vật lý của dịch vụ Web (ví dụ: dễ dàng an toàn, sử dụng trung tâm dữ liệu)

• Môi trường an toàn thực thi đối với môi trường xử lý dịch vụ Web (ví dụ: các điều khiển cho độ ẩm, nước, nguồn điện, ô nhiễm, nhiệt độ, và hóa chất)

Đối với các dịch vụ Web đang trong giai đoạn khởi đầu hay trong pha thiết

kế, thông tin dịch vụ Web có thể được nhận lấy từ các tài liệu thiết kế hay yêu cầu Đối với một dịch vụ Web đang phát triển, cần phải xác định các quy tắc và đặc tính bảo mật chính dự định cho dịch vụ Web tương lai Các tài liệu thiết kế hệ thống và kế hoạch an toàn có thể đưa ra thông tin hữu ích về an toàn của dịch vụ Web đang phát triển

Đối với một dịch vụ Web đã sẵn sàng để dùng, dữ liệu được tập hợp về dịch vụ Web từ môi trường sản xuất của nó, bao gồm dữ liệu về cấu hình hệ thống, kết nối, và các thủ tục và thực tiễn chưa đưa vào tài liệu hay đã tài liệu hóa Do đó,

mô tả dịch vụ Web có thể được dựa vào an toàn cung cấp bởi hạ tầng cơ sở đó hay

là các kế hoạch an toàn tương lai đối với dịch vụ Web

2.6.1.1.2 Kỹ thuật thu thập thông tin

Các kỹ thuật sau có thể dùng để thu thập các thông tin của dịch vụ Web ở trong giới hạn sử dụng của nó:

• Bảng câu hỏi Để thu thập các thông tin thích đáng, người đánh giá rủi ro có thể lập một bảng câu hỏi liên quan đến quản lý và các điều khiển hoạt động được định kế hoạch hay sử dụng đối với dịch vụ Web Bảng câu hỏi này nên được phân phát cho người quản lý – những người đang thiết kế và hỗ trợ dịch vụ Web Bảng câu hỏi cũng được sử dụng trong quá trình viếng thăm on-site và trong các cuộc phỏng vấn

• Phỏng vấn on-site Phỏng vấn đối với dịch vụ Web và người quản lý có thể cho phép người đánh giá rủi ro thu thập các thông tin hữu ích về dịch vụ Web (ví dụ: làm cách nào dịch vụ Web được thực thi và quản lý) Các cuộc viếng thăm on-site cũng cho phép người đánh giá rủi ro theo dõi và thu thập các thông tin về an toàn vật lý, an toàn về môi trường, và an toàn hoạt động của dịch vụ Web Đối với các hệ thống vẫn đang trong pha thiết kế, các cuộc viếng thăm on-site sẽ đối mặt với thu thập dữ liệu qua thực hành và có thể đưa ra cơ hội để đánh giá môi trường vật lý trong đó dịch vụ Web sẽ hoạt động

• Xem lại tài liệu Các tài liệu về chính sách (ví dụ: tài liệu lập pháp, chỉ thị), tài liệu về hệ thống (ví dụ: hướng dẫn người dùng hệ thống, hướng dẫn quản trị hệ thống, tài liệu thiết kế và yêu cầu hệ thống), và các tài liệu liên quan đến an toàn (ví dụ: báo cáo kiểm định trước kia, báo cáo đánh giá rủi

ro, kết quả kiểm tra hệ thống, kế hoạch an toàn hệ thống, các chính sách an

toàn) có thể đưa ra các thông tin tốt về kiểm soát an toàn đã được sử dụng

và lập kế hoạch đối với dịch vụ Web

• Sử dụng công cụ quyét tự động Các phương pháp kỹ thuật tiên phong có thể được sử dụng để thu thập thông tin hệ thống một cách hiệu quả Ví dụ, công cụ bản đồ mạng có thể nhận dạng các dịch vụ chạy trong một nhóm lớn các máy chủ và đưa ra cách thức nhanh chóng để xây dựng từng profile riêng lẻ của dịch vụ Web đích

Thu thập thông tin có thể được chỉ dẫn trong suốt quy trình quản lý rủi ro, từ bước

1 cho đến bước 9

2.6.1.2 Bước 2: Nhận dạng mối đe dọa

Mối đe dọa (threat) là khả năng đối với một nguồn đe dọa cụ thể thành công trong việc gây ra sự tổn hại (exploitation) với dịch vụ Web Tính dễ bị tổn hại là điểm yếu có thể xuất hiện bất ngờ hay bị khai thác Nguồn gây tổn hại không hiển thị ra các rủi ro khi không có các thành phần dễ gây tổn hại Để xác định được một mối đe dọa có khả năng xảy ra hay không, chúng ta cần xem xét các nguồn gây tổn hại, điểm yếu tiềm năng, và các kiểm soát đã có

2.6.1.2.1 Nhận dạng nguồn gây tổn hại

Mục tiêu của bước này là nhận dạng các nguồn gây tổn hại tiềm năng và liệt kê các nguồn đó sao cho chúng thích hợp với dịch vụ Web đang được đánh giá

Các nguồn gây tổn hại phổ biến:

• Tổn hại tự nhiên – Bão lụt, động đất, bão táp, lở đất, tuyết lở, bão điện từ,

và các nguồn khác tương tự như vậy

• Tổn hại từ phía con người – Các sự kiện gây ra bởi con người hay do con người cho phép, như là các hành động không chủ ý (vô ý trong nhập dữ liệu vào hệ thống) hay các hành động cố ý (tấn công mạng máy tính, tải lên mạng các phần mềm độc hại, truy cập trái phép vào các dữ liệu mật)

• Tổn hại từ môi trường – Nguồn điện không hoạt động dài hạn, ô nhiễm, hóa chất, dò rỉ chất lỏng

Một nguồn gây nguy hiểm được xác định trong tình huống nó gây hại cho dịch vụ Web Các nguồn gây hại thông thường là từ tự nhiên, con người, và môi trường

Khi đánh giá các nguồn gây hại, điều quan trọng là xem xét tất cả các nguồn gây hại tiềm ẩn có thể gây hại cho một dịch vụ Web và môi trường xử lý của nó Ví dụ, mặc dù với tuyên bố rằng nguồn gây hại của một dịch vụ Web trên một sa mạc có thể không bao gồm “lũ lụt” bởi vì sự kiện như vậy dường như không xảy ra, các tổn hại từ môi trường như là nổ đường ống có thể nhanh chóng gây ngập lụt phòng máy tính và gây tổn hại đến các tài sản và tài nguyên IT của tổ chức Con người có thể trở thành một nguồn gây tổn hại qua các hành động cố ý, như là các tấn công cố ý bởi những người độc ác hay các nhân viên bất mãn, hoặc các hành động vô tâm, như là việc cẩu thả hay sai lầm

Một cuộc tấn công cố ý có thể là một trong hai kiểu sau: (1) một cuộc tấn công cố tình làm hại để truy cập trái phép vào một dịch vụ Web (ví dụ: qua dự đoán mật khẩu) để làm hại hệ thống và tính toàn vẹn dữ liệu, tính sẵn sàng hay bảo mật dữ liệu, hoặc là (2) một việc tốt, tuy nhiên cố gắng để phá vỡ an ninh hệ thống một ví dụ cho kiểu thứ 2 của tấn công cố ý là viết một chương trình “con ngựa thành Troa” để đi vòng qua an ninh hệ thống khiến cho “gạo đã thành cơm”

2.6.1.2.2 Động cơ thúc đẩy và các hành động đe dọa

Động cơ thúc đẩy và các tài nguyên để thực hiện tấn công tạo ra các nguồn gây tổn hại nguy hiểm tiềm ẩn từ phía con người Bảng 3-1 đưa ra cái nhìn tổng quan về các nguồn gây nguy hiểm phổ biến từ con người hiện nay, các động cơ thúc đẩy khả dĩ, và các phương pháp hay hành động tổn hại mà họ có thể tạo ra cuộc tấn công

Thông tin này sẽ hữu ích cho các tổ chức nghiên cứu môi trường tổn hại từ con người của họ và tùy chỉnh các tuyên bố về tổn hại do con người Thêm vào đó, xem lại lịch sử các cuộc tấn công vào hệ thống ngân hàng; các báo cáo về vi phạm

an toàn; báo cáo sự việc; và các bài phỏng vấn với người quản trị hệ thống, và toàn

bộ người dùng trong suốt quá trình thu thập thông tin sẽ giúp nhận dạng các nguồn gây nguy hiểm từ con người, các nguồn đó có tiềm năng gây tổn hại cho dịch vụ Web và dữ liệu của nó

Bảng 2.2 Các tổn hại do con người:

Nguồn gây tổn hại Động cơ thúc đẩy Hành động gây tổn hại

• Truy cập trái phép vào hệ thống Tội phạm máy tính Sự phá hủy của thông

tin bất hợp pháp Kiếm tiền Thay đổi dữ liệu trái phép

(Terrorist) Tống tiền Phá hoại

Khai thác Trả thủ

điệp Giành lợi thế cạnh tranh

Gián điệp kinh tế

• Khai thác kinh tế chính trị

• Ăn cắp thông tin

• Xâm phạm đời tư cá nhân

• Social engineering

• Thâm nhập hệ thống

• Truy cập trái phép vào hệ thống Người trong nội bộ Tính hiếu kỳ • Tấn công từ một nhân viên

(được huấn luyện

Kiếm tiền Trả thù Các lỗi vô ý và chểnh mảng trong công việc (ví dụ: nhập dữ liệu lỗi, lỗi lập trình)

• Tống tiền

• Xem các thông tin riêng

• Lạm dụng máy tính

• Gian lận và trộm cắp

• Mua chuộc thông tin

• Giả mạo dữ liệu vào, dữ liệu mua chuộc

• Truy cập trái phép vào hệ thống

Sau khi đã nhận dạng được các nguồn gây tổn hại, để ngăn chặn được một cuộc tấn công thì cần yêu cầu ước lượng động cơ, các tài nguyên và khả năng của cuộc tấn công đó để quyết định khả năng có thể xảy ra hay không của việc sử dụng mối nguy hiểm tấn công vào điểm yếu của hệ thống

Báo cáo mối nguy hiểm, hay danh sách của các nguồn gây tổn hại tiềm ẩn, nên thích ứng với từng tổ chức riêng lẻ và môi trường của nó Nhìn chung, thông tin về các tổn hại tự nhiên (ví dụ: lụt lội, động đát, bão) nên có sẵn Các tổn hại như vậy đã được xác định bởi rất nhiều chính phủ và các tổ chức riêng lẻ Các công cụ dò tìm sự xâm nhập cũng đang trở nên thịnh hành hơn, và chính phủ và các tổ chức công nghiệp liên tục thu thập dữ liệu qua các sự kiện an toàn, qua đó cải thiện khả năng đánh giá các mối đe dọa Các nguồn của thông tin bao gồm:

• Intelligence agencies

• Federal Computer Incident Response Center (FedCIRC)

• Các phương tiện truyền thông đại chúng, đặc biệt là các nguồn trên Web như là http://www.securityfocus.com/,

http://www.securitywatch.com/home.html, http://www.securityportal.org/,

http://www.sans.org/

2.6.1.3 Bước 3: Nhận dạng điểm yếu dễ bị tấn công

Việc phân tích các mối đe dọa đến một dịch vụ Web bặt buộc phải có phân tích về các điểm yếu dễ bị tấn công liên quan đến môi trường hệ thống Mục tiêu của bước này là phát triển một danh sách các điểm yếu dễ bị tấn công của hệ thống

mà các điểm yếu đó có thể bị tấn công bởi các nguồn gây nguy hiểm tiềm ẩn Bảng 2.3 đưa ra các ví dụ về các khả năng gây tổn thương đến hệ thống

Bảng 2.3 Vulnerability/Threat Pairs

Khả năng gây tổn hại hệ

Các định danh (ID) của

Tường lửa của tổ chức

cho phép truy cập từ xa,

và ID khách được cho

phép tại một máy chủ

XYZ nào đó

Người dùng trái phép (hacker, nhân viên đã hủy hợp đồng, tội phạm máy tính, kẻ khủng bố)

Sử dụng kết nối từ xa đến máy chủ XYZ và xem các file của hệ thống qua ID khách

Tồn tại các truy cập trái phép vào các file nhạy cảm của hệ thống dựa vào các điểm yếu đã biết của

hệ thống Trung tâm dữ liệu sử

dụng bình phun nước để

cứu hỏa; vải nhựa để bảo

vệ phần cứng và các thiết

bị khỏi sự phá hủy của

nước – không được thay

thế vào hệ thống

Lửa, những người cẩu thả Bình phun nước được

kích hoạt trong trung tâm

dữ liệu

Các phương thức đề cập ở trên đối với nhận dạng các điểm dễ bị tổn thương của hệ thống là việc sử dụng của các nguồn gây tổn hại, sự thực thi của các kiểm tra an toàn hệ thống, và sự phát triển của bản liệt kê các yêu cầu an toàn

Cần chú ý đến các kiểu gây tổn thương và phương pháp cần thiết để xác định khi nào các sự xâm phạm hiện hữu, sẽ là luôn luôn thay đổi dựa vào trạng thái tự nhiên của hệ thống và các pha của nó trong SDLC:

• Nếu dịch vụ Web chưa được thiết kế, việc tìm kiếm các điểm yếu dễ gây tổn hại nên tập trung và các chính sách an ninh của hệ thống, các thủ tục an ninh trong kế hoạch, và các yêu cầu hệ thống, và các bản phân tích an toàn của các nhà cung cấp hay nhà phát triển

• Nếu dịch vụ Web đang thi hành, việc nhận dạng các điểm yếu dễ gây tổn thương đến hệ thống nên được mở rộng tính đến cả các thông tin đặc biệt, như là các tính năng an toàn mô tả trong tài liệu thiết kế an toàn hệ thống và các kết quả của việc kiểm tra và đánh giá cấp giấy chứng nhận cho hệ thống

• Nếu dịch vụ Web đang sẵn sàng hoạt động, quy trình xác định các điểm yếu

dễ gây tổn thương đến hệ thống nên phân tích về các tính năng an toàn dịch

vụ Web và các kiểm soát an toàn được sử dụng để bảo vệ hệ thống

2.6.1.3.1 Các nguồn dễ gây tổn thương đến hệ thống

Các nguồn dễ gây tổn thương về kỹ thuật và không kỹ thuật đến môi trường

xử lý của hệ thống có thể được xác định thông qua các kỹ thuật thu thập thông tin

đã mô tả trong phần trước Việc xem lại các nguồn gốc công nghệ khác (ví dụ: các trang Web của nhà cung cấp có lỗi và điểm yếu hệ thống) sẽ rất hữu ích để chuẩn

bị cho việc phỏng vấn và phát triển bảng câu hỏi hiệu quả để xác định các điểm yếu dễ gây tổn thương thích hợp đối với một dịch vụ Web riêng biệt (ví dụ: một phiên bản của một hệ điều hành nào đó) Mạng máy tính cũng là một nguồn thông tin khác trong đó các điểm yếu dễ gây tổn thương đã được các nhà cung cấp thông báo, cùng với các bản vá lỗi để giảm nhẹ hoặc loại trừ các lỗ hổng nói trên Tài liệu về các nguồn gây tổn hại nên được xem xét trong quá trình phân tích tổn hại dưới đây:

• Các tài liệu đánh giá rủi ro trước đó

• Danh sách các điểm yếu dễ bị tấn công của hệ thống, như là cơ sở dữ liệu NIST I-CAT (http://www.nist.gov )

• Các tư vấn an toàn thông tin, như là FedCIRC

• Các tư vấn của nhà cung cấp

• Đội cứu hộ máy tính thương mại và danh sách thông báo

• Các bản tin và các cảnh báo về điểm yếu cần đảm bảo thông tin cho các hệ thống quân đội

• Các phân tích an toàn phần mềm hệ thống

2.6.1.3.2 Kiểm tra an toàn dịch vụ Web

Các phương pháp tiên phong nhằm kiểm tra hệ thống nhân viên có thể được

sử dụng để nhận dạng các điểm yếu một cách hiệu quả, phụ thuộc và tính then chốt của hệ thống và các tài nguyên sẵn có (ví dụ: ngân quỹ, công nghệ sẵn có, con người đủ năng lực để thực hiện kiểm tra) Các phương pháp kiểm tra bao gồm:

• Công cụ dò tìm điểm yếu tự động

• Định giá và kiểm tra an toàn (ST&E)

• Kiểm tra sự thâm nhập hệ thống

Công cụ dò tìm điểm yếu tự động được sử dụng để dò tìm một nhóm các máy chủ hoặc mạng để biết được các dịch vụ dễ bị tấn công (ví dụ: hệ thống cho phép giao thức truyền file nặc danh, gửi thư chuyển tiếp) Tuy nhiên, chúng ta chú

ý rằng một số điểm yếu tiềm năng xác định bởi công cụ dò tìm tự động này có thể không đưa ra các điểm yếu dễ bị tấn công thực sự trong môi trường dịch vụ Web

Ví dụ, một số công cụ dò tìm đánh giá các điểm dễ gây tổn hại mà không xem xét đến môi trường và yêu cầu của site Một số điểm yếu được đánh đấu bởi các phần mềm dò tìm tự động thực tế có thể không dễ bị tấn công đối với một site riêng biệt