You are on page 1of 24

TRƯỜNG ĐẠI HỌC KIẾN TRÚC HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN

CÔNG NGHỆ PHẦN MỀM


NHÓM 11_LỚP 19CN1

Người thực hiện:


1. Trần Đức Hải - 874820
2. Nguyễn Chí Tài
3. Trần Quốc Việt
4. Lương Thanh An
Lớp tín chỉ:
Giảng viên hướng dẫn: Nguyễn Hồng Thanh

Hà Nội, tháng 9 năm 2021


1
LỜI MỞ ĐẦU

Khi các hệ thống máy tính đã trở nên thân thuộc trong doanh nghiệp và cuộc
sống của mỗi cá nhân, các vấn đề do lỗi hệ thống và phần mềm ngày càng tăng. Lỗi
phần mềm máy chủ trong một công ty thương mại điện tử có thể dẫn đến mất mát lớn
về doanh thu và có thể là cả khách hàng cho công ty đó. Một lỗi phần mềm trong một
hệ thống điều khiển nhúng của ô tô có thể dẫn đến việc thu hồi chiếc xe đó và sữa
chữa rất tốn kém, trong trường hợp xấu nhất, nó có thể là một yếu tố góp phần gây ra
tai nạn. Việc máy tính của công ty bị nhiễm phần mềm độc hại đòi hỏi các hoạt động
dọn dẹp tốn kém để loại bỏ vấn đề và có thể dẫn đến mất mát hoặc hư hỏng dữ liệu
nhạy cảm. Bởi vì các hệ thống chuyên sâu về phần mềm rất quan trọng đối với các
chính phủ, các công ty, và các cá nhân, điều cốt yếu là phần mềm được sử dụng rộng
rãi phải đáng tin cậy. Phần mềm nên có sẵn khi được yêu cầu và phải hoạt động chính
xác và không có điều khoản phụ không mong muốn, chẳng hạn như tiết lộ thông tin
trái phép. Thuật ngữ 'độ tin cậy' được đề xuất bởi Laprie (1995) để bao hàm các thuộc
tính hệ thống liên quan của tính khả dụng, độ tin cậy, an toàn và bảo mật. Như tôi đã
thảo luận trong Phần 11.1, các thuộc tính này được liên kết chặt chẽ với nhau, vì vậy
cần có một thuật ngữ duy nhất bao hàm tất cả để chúng đều có ý nghĩa.
Độ tin cậy của các hệ thống hiện nay thường quan trọng hơn so với chi tiết các
chức năng của chúng vì những lý do sau:
1. Lỗi hệ thống ảnh hưởng đến một số lượng lớn người. Nhiều hệ thống bao
gồm chức năng hiếm khi được sử dụng. Nếu chức năng này không có trong hệ thống,
chỉ một một số lượng nhỏ người dùng sẽ bị ảnh hưởng. Lỗi hệ thống, ảnh hưởng đến
tính khả dụng của hệ thống, có khả năng ảnh hưởng đến tất cả người dùng của hệ
thống. Gặp lỗi có thể làm việc kinh doanh bình thường chở nên không thể.
2. Người dùng thường từ chối các hệ thống không đáng tin cậy, không an toàn.
Nếu người dùng tìm thấy rằng một hệ thống không đáng tin cậy hoặc không an toàn,
họ sẽ từ chối sử dụng nó. Hơn nữa, họ cũng có thể từ chối mua hoặc sử dụng các sản
phẩm khác từ cùng một công ty đã tạo ra hệ thống không đáng tin cậy đấy, bởi vì họ
tin rằng những sản phẩm này cũng có thể là không đáng tin cậy hoặc không an toàn.
3. Chi phí sửa lỗi hệ thống có thể rất lớn. Đối với một số ứng dụng, chẳng hạn
như lò phản ứng hệ thống điều khiển hoặc hệ thống định vị máy bay, chi phí sửa chữa
hệ có thể lớn hơn cả chi phí tạo ra hệ thống đó.
4. Các hệ thống không đáng tin cậy có thể gây mất thông tin. Dữ liệu rất khó để
thu thập và duy trì; nó thường có giá trị hơn nhiều so với hệ thống máy tính xử lý nó.
Chi phí khôi phục dữ liệu bị mất hoặc bị hỏng thường rất cao.
Như tôi đã thảo luận trong Chương 10, phần mềm luôn là một phần của một hệ thống
rộng lớn hơn. Nó thực thi trong một môi trường hoạt động bao gồm phần cứng mà
phần mềm đó thực thi, những người sử dụng phần mềm đó và tổ chức hoặc doanh
nghiệp với các quy trình mà phần mềm được sử dụng. Khi thiết kế một hệ thống đáng
tin cậy, bạn cần phải xem xét:
2
1. Lỗi phần cứng
Phần cứng hệ thống có thể bị lỗi do sai lầm trong việc thiết kế , bởi các thành phần bị
lỗi do lỗi sản xuất hoặc do các thành phần đã đạt đến giới hạn về tuổi thọ của chúng.
Hệ thống quan trọng
Một số loại hệ thống được gọi là "hệ thống quan trọng" trong đó lỗi hệ thống có thể
dẫn đến thương tích cho con người, thiệt hại cho môi trường, hoặc thiệt hại kinh tế lớn.
Ví dụ về các hệ thống quan trọng bao gồm các hệ thống nhúng trong các thiết bị y tế,
chẳng hạn như máy bơm insulin (quan trọng về an toàn), hệ thống định vị tàu vũ trụ
(quan trọng về sứ mệnh) và hệ thống chuyển tiền trực tuyến (quan trọng trong kinh
doanh).
Hệ thống quan trọng rất tốn kém để phát triển. Chúng không chỉ phải được phát triển
để rất hiếm khi xảy ra lỗi và chúng cũng phải bao gồm các cơ chế khôi phục để có thể
sử dụng khi các lỗi xảy ra.
http://www.SoftwareEngineering9.com/Web/Dependability/CritSys.html
2. Lỗi phần mềm
Phần mềm hệ thống có thể bị lỗi do lỗi trong đặc điểm kỹ thuật, thiết kế hoặc triển
khai.
3. Lỗi vận hành
Người dùng là con người có thể không thể sử dụng hoặc vận hành hệ thống một cách
chính xác. Khi phần cứng và phần mềm trở nên đáng tin cậy hơn, các lỗi trong vận
hành bây giờ, có lẽ, là nguyên nhân lớn nhất gây ra lỗi hệ thống.
Những hư hỏng này thường có mối liên hệ với nhau. Một thành phần phần cứng bị lỗi
có thể có nghĩa là người vận hành hệ thống phải đối phó với một tình huống bất ngờ và
khối lượng công việc bổ sung. Điều này khiến họ bị căng thẳng và những người bị
căng thẳng thường mắc sai lầm. Cái này có thể khiến phần mềm bị lỗi, có nghĩa là
người vận hành sẽ phải làm nhiều việc hơn, thậm chí nhiều căng thẳng hơn, và cứ tiếp
diễn như vậy.
Do đó, điều đặc biệt quan trọng là các nhà thiết kế của các hệ thống tích hợp phần
mềm đáng tin cậy phải có quan điểm về hệ thống tổng thể, thay vì tập trung vào một
khía cạnh của hệ thống chẳng hạn như phần mềm hoặc phần cứng của nó. Nếu phần
cứng, phần mềm và các quy trình hoạt động được thiết kế riêng biệt, không tính đến
các điểm yếu tiềm ẩn của các bộ phận khác trong hệ thống, khi đó sẽ có nhiều khả
năng xảy ra lỗi. xảy ra tại các giao diện giữa các phần khác nhau của hệ thống.

11.1 THUỘC TÍNH ĐỘ TIN CẬY

Tất cả chúng ta đều quen thuộc với vấn đề hệ thống máy tính bị lỗi. Với một lý do
không rõ ràng , máy tính của chúng ta đôi khi bị hỏng hoặc gặp sự cố theo một cách
nào đó. Các chương trình đang chạy trên những máy tính này có thể không hoạt động
3
như mong đợi và đôi khi có thể làm hỏng dữ liệu được quản lý bởi hệ thống. Chúng tôi
đã học cách sống chung với những lỗi này nhưng ít người trong chúng ta có thể hoàn
toàn tin tưởng vào máy tính cá nhân mà chúng ta thường sử dụng.
Độ tin cậy của hệ thống máy tính là một thuộc tính của hệ thống phản ánh độ tin cậy
của nó. Đáng tin cậy ở đây về cơ bản có nghĩa là mức độ người dùng cho rằng hệ
thống sẽ hoạt động như họ mong đợi và hệ thống sẽ không 'Lỗi' trong sử dụng thường
ngày. Nó không có ý nghĩa khi thể hiện độ tin cậy bằng số.

Độ tin cậy

TÍnh khả dụng Tính chuẩn xác Độ an toàn Tính bảo mật

Khả năng của hệ Khả năng của hệ thống Khả năng của hệ thống Khả năng của hệ
thống để cung cấp để cung cấp các dịch vụ hoạt động mà không gặp thống để bảo vệ nó
dịch vụ khi yêu cầu như chỉ định phải lỗi nghiêm trọng khỏi sự xâm nhập
vô tình hay cố ý
Hình 11.1: Các đặc trưng của độ tin cậy

Thay vào đó, chúng tôi sử dụng các thuật ngữ tương đối như "không đáng tin cậy","rất
đáng tin cậy" và “cực kỳ đáng tin cậy” để phản ánh mức độ tin cậy mà chúng ta có thể
có trong một hệ thống. Tất nhiên, đáng tin cậy và hữu ích không phải là điều giống
nhau. Tôi không nghĩ rằng trình xử lý văn bản mà tôi đã sử dụng để viết cuốn sách này
là một hệ thống rất đáng tin cậy. Đôi khi nó bị đóng băng và phải khởi động lại. Tuy
nhiên, vì nó rất hữu ích, Tôi đã chuẩn bị để chịu đựng những lỗi không thường xuyên
này. Tuy nhiên, để phản ánh sự thiếu tin tưởng của tôi vào hệ thống tôi lưu công việc
của mình thường xuyên và giữ nhiều bản sao lưu của nó. Tôi bù đắp cho sự thiếu tin
cậy của hệ thống bằng các hành động hạn chế thiệt hại có thể do lỗi hệ thống.
Có bốn đặc trưng chính đối với độ tin cậy, như thể hiện trong Hình 11.1
1. Tính khả dụng
Tính khả dụng của một hệ thống là xác suất mà nó được thiết lập và hoạt động bình
thường và có thể cung cấp các dịch vụ hữu ích cho người dùng vào bất kỳ thời điểm
nào.
2. Tính chuẩn xác
Tính xác thực của một hệ thống là xác suất, trên một khoảng thời gian mà hệ thống sẽ
cung cấp các dịch vụ một cách chính xác như mong đợi người dùng.
3. Độ an toàn
Độ an toàn của một hệ thống là sự đánh giá khả năng hệ thống sẽ gây ra thiệt hại cho
con người hoặc môi trường của nó.
4
4. Tính bảo mật
Tính bảo mật của một hệ thống là sự đánh giá xem nó có khả năng chống lại sự xâm
nhập vô ý hay cố ý như thế nào
Các thuộc tính của độ tin cậy được thể hiện trong Hình 11.1 là các thuộc tính phức tạp
có thể được chia nhỏ thành một số thuộc tính khác, đơn giản hơn. Ví dụ: Tính bảo mật
bao gồm "tính toàn vẹn" (đảm bảo rằng chương trình và dữ liệu của hệ thống không hư
hỏng) và 'tính bí mật' (đảm bảo rằng thông tin chỉ có thể được truy cập bởi người được
ủy quyền). Tính chuẩn xác bao gồm "tính đúng đắn" (đảm bảo hệ thống làm việc như
đã chỉ định), "độ chính xác" (đảm bảo thông tin được phân phối ở mức độ chi tiết thích
hợp) và "tính kịp thời" (đảm bảo rằng thông tin được phân phối khi nó được yêu cầu)
Tất nhiên, không phải tất cả các thuộc tính của độ tin cậy này đều có thể áp dụng cho
tất cả các hệ thống. Ví dụ như hệ thống bơm insulin, được giới thiệu trong Chương 1,
các đặc tính quan trọng nhất là tính khả dụng (nó phải hoạt động khi được yêu cầu),
Tính chuẩn xác (nó phải cung cấp đúng liều lượng của insulin), và độ an toàn (nó
không bao giờ được cung cấp một liều insulin nguy hiểm). Tính bảo mật không phải là
vấn đề vì máy bơm sẽ không duy trì thông tin bảo mật. Nó không được nối mạng và do
đó không thể bị tấn công. Đối với hệ thống dự báo thời tiết, tính khả dụng và tính
chuẩn xác là những đặc tính quan trọng nhất vì chi phí của sửa chữa có thể rất cao. Đối
với hệ thống thông tin bệnh nhân, tính bảo mật đặc biệt quan trọng vì dữ liệu cá nhân
nhạy cảm cần được duy trì.
Ngoài bốn thuộc tính của độ tin cậy chính này, bạn cũng có thể nghĩ về các thuộc tính
hệ thống giống như thuộc của tính độ tin cậy:
1. Khả năng sửa chữa
Hỏng hóc hệ thống là không thể tránh khỏi, nhưng sự gián đoạn do hỏng hóc có thể
được giảm thiểu nếu hệ thống có thể được sửa chữa nhanh chóng. Để điều đó xảy ra,
nó phải có khả năng chẩn đoán sự cố, truy cập thành phần bị lỗi, và thực hiện các thay
đổi để sửa chữa thành phần đó. Khả năng sửa chữa trong phần mềm được nâng cao khi
tổ chức sử dụng hệ thống có quyền truy cập vào mã nguồn và có các kỹ năng để thực
hiện các thay đổi đối với nó. Phần mềm có mã nguồn mở làm cho việc này dễ dàng
hơn nhưng việc sử dụng lại các thành phần có thể gây khó khăn hơn.
2. Khả năng duy trì
Khi hệ thống được sử dụng, các yêu cầu mới xuất hiện và điều quan trọng là phải duy
trì tính hữu ích của hệ thống bằng cách thay đổi nó để phù hợp với những yêu cầu mới.
Phần mềm có thể duy trì là phần mềm có thể được điều chỉnh một cách kinh tế để đối
phó với các yêu cầu mới và có xác suất thấp rằng việc thực hiện các thay đổi sẽ tạo ra
các lỗi mới vào hệ thống.
3. Khả năng sống sót
Một thuộc tính rất quan trọng đối với các hệ thống trên Internet là khả năng sống sót
(Ellison và cộng sự, 1999b). Khả năng sống sót là khả năng của một hệ thống tiếp tục
cung cấp dịch vụ trong khi bị tấn công và có khả năng làm việc trong khi một phần của
5
hệ thống bị vô hiệu hóa. Công việc về khả năng sống sót tập trung vào việc xác định
các thành phần chính của hệ thống và đảm bảo rằng họ có thể cung cấp một dịch vụ tối
thiểu. Ba chiến lược được sử dụng để nâng cao khả năng sống sót — khả năng chống
lại cuộc tấn công, nhận dạng cuộc tấn công và phục hồi khỏi thiệt hại do một cuộc tấn
công gây ra (Ellison và cộng sự, 1999a; Ellison và cộng sự, 2002). Tôi sẽ thảo luận chi
tiết hơn về vấn đề này trong Chương 14.
4. Khả năng chịu lỗi
Thuộc tính này có thể được coi là một phần của khả năng sử dụng và phản ánh mức độ
mà hệ thống đã được thiết kế để tránh các lỗi nhập liệu của người dùng và sửa chữa
nó. Khi lỗi người dùng xảy ra, hệ thống phải phát hiện những lỗi này trong khả năng
có thể và tự động sửa chúng hoặc yêu cầu người dùng nhập lại dữ liệu của họ
Khái niệm về độ tin cậy của hệ thống như một thuộc tính bao trùm đã được đưa ra bởi
vì các thuộc tính độ tin cậy về tính khả dụng, bảo mật, tính chuẩn xác và an toàn đều
liên kết với nhau. Hệ thống hoạt động an toàn thường phụ thuộc vào hệ thống khả
dụng và hoạt động chuẩn xác. Một hệ thống có thể trở nên không đáng tin cậy vì kẻ
xâm nhập đã làm hỏng dữ liệu của nó. Các cuộc tấn công từ chối dịch vụ vào một hệ
thống nhằm làm tổn hại đến tính khả dụng của hệ thống. Nếu một hệ thống bị nhiễm
vi-rút, thì bạn không thể tự tin về tính chuẩn xác hoặc độ an toàn của nó vì vi-rút có
thể thay đổi hành vi của nó.
Do đó, để phát triển phần mềm đáng tin cậy, bạn cần đảm bảo rằng:
1. Bạn tránh được việc đưa các lỗi ngẫu nhiên vào hệ thống trong quá trình sử dụng và
phát triển phần mềm.
2. Bạn thiết kế các quy trình xác minh và xác thực có hiệu quả trong việc khám phá lỗi
tồn đọng ảnh hưởng đến độ tin cậy của hệ thống.
3. Bạn thiết kế các cơ chế bảo vệ chống lại các cuộc tấn công từ bên ngoài có thể ảnh
hưởng đến tính khả dụng hoặc bảo mật của hệ thống.
4. Bạn thiết lập cấu hình hệ thống đã triển khai và phần mềm hỗ trợ của nó một cách
chính xác cho môi trường mà nó hoạt động.
Ngoài ra, bạn nên nghĩ rằng phần mềm của mình không hoàn hảo và lỗi phần mềm
hoàn toàn có thể xảy ra. Do đó, hệ thống của bạn nên bao gồm các cơ chế khôi phục
giúp bạn có thể khôi phục dịch vụ hệ thống bình thường nhanh nhất có thể.
Nhu cầu về khả năng chịu lỗi có nghĩa là các hệ thống đáng tin cậy phải bao gồm mã
dự phòng để giúp họ tự giám sát, phát hiện các trạng thái sai và phục hồi từ các lỗi
trước khi xảy ra lỗi. Điều này ảnh hưởng đến hiệu suất của hệ thống, như yêu cầu kiểm
tra bổ sung mỗi khi hệ thống thực thi. Do đó, các nhà thiết kế thường phải đánh đổi
hiệu suất và độ tin cậy. Bạn có thể cần phải bỏ kiểm tra ra khỏi hệ thống vì những điều
này làm chậm hệ thống. Tuy nhiên, rủi ro ở đây là một số hỏng hóc có thể xảy ra do lỗi
chưa được phát hiện.

6
Với việc thiết kế thêm, thực hiện và xác nhận bổ sung, làm tăng độ tin cậy của một hệ
thống cũng làm tăng đáng kể chi phí phát triển. Đặc biệt, chi phí là rất cao đối với các
hệ thống cực kỳ đáng tin cậy, chẳng hạn như hệ thống điều khiển quan trọng về độ an
toàn. Cũng như xác nhận rằng hệ thống đáp ứng các yêu cầu của nó, quá trình xác
nhận có thể phải chứng minh với cơ quan quản lý bên ngoài rằng hệ thống an toàn. Ví
dụ, hệ thống máy bay phải chứng minh với các cơ quan quản lý, chẳng hạn như Cơ
quan Hàng không Liên bang, rằng khả năng xảy ra sự cố hệ thống nghiêm trọng ảnh
hưởng đến độ an toàn của máy bay là cực kỳ thấp.
Hình 11.2 cho thấy mối quan hệ giữa chi phí và sự cải thiện gia tăng về độ tin cậy.
Nếu phần mềm của bạn không đáng tin cậy lắm, bạn có thể nhận được những cải thiện
đáng kể với chi phí tương đối thấp bằng cách sử dụng kỹ thuật phần mềm tốt hơn. Tuy
nhiên, nếu bạn đang sử dụng hệ thống tốt, thì chi phí cải thiện sẽ rất lớn, lớn hơn và lợi
ích từ cải tiến đó ít hơn. Ngoài ra còn có vấn đề kiểm tra phần mềm của bạn để chứng
minh rằng nó đáng tin cậy. Điều này phụ thuộc vào việc chạy nhiều thử nghiệm và
xem xét số lượng lỗi xảy ra. Khi phần mềm của bạn trở nên đáng tin cậy hơn, bạn ngày
càng thấy ít lỗi hơn. Do đó, cần rất nhiều thử nghiệm để thử và đánh giá xem có bao
nhiêu vấn đề còn tồn tại đọng phần mềm. Vì thử nghiệm rất tốn kém, điều này làm
tăng đáng kể chi phí của hệ thống có độ tin cậy cao.

Chi phí

Thấp Trung bình Cao Cực cao Cực kỳ cao


Độ tin cậy
Hình 11.2: biểu đồ Chi phí / Độ tin cậy

11.2 TÍNH KHẢ DỤNG VÀ ĐỘ CHUẨN XÁC

Tính khả dụng và độ tin cậy của hệ thống là những thuộc tính có liên quan chặt chẽ với
nhau mà cả hai đều có thể được biểu thị dưới dạng xác suất số. Tính khả dụng của một
hệ thống là xác suất rằng hệ thống sẽ được thiết lập và chạy để cung cấp các dịch vụ
này cho người dùng theo yêu cầu.

7
Độ tin cậy của hệ thống là xác suất mà các dịch vụ của hệ thống sẽ được phân phối
như được xác định trong đặc tả hệ thống. Nếu, trung bình, 2 đầu vào trong mỗi 1.000
gây ra lỗi, thì độ tin cậy, được biểu thị bằng tỷ lệ xuất hiện lỗi, là 0,002. Nếu tính khả
dụng là 0,999, điều này có nghĩa là trong một khoảng thời gian nào đó, hệ thống có sẵn
trong 99,9% thời gian đó.Độ tin cậy và tính khả dụng có liên quan chặt chẽ với nhau
nhưng đôi khi cái này quan trọng hơn cái kia. Nếu người dùng mong đợi dịch vụ liên
tục từ một hệ thống thì hệ thống có yêu cầu về tính khả dụng cao. Nó phải có sẵn bất
cứ khi nào có nhu cầu.
Tuy nhiên, nếu tổn thất do lỗi hệ thống là thấp và hệ thống có thể phục hồi nhanh
chóng sau đó các lỗi không ảnh hưởng nghiêm trọng đến người dùng hệ thống. Trong
các hệ thống như vậy, yêu cầu về độ tin cậy có thể tương đối thấp.Công tắc tổng đài
điện thoại định tuyến các cuộc gọi điện thoại là một ví dụ về hệ thống trong đó tính
sẵn sàng quan trọng hơn độ tin cậy. Người dùng mong đợi một âm quay số khi họ
chọn lên điện thoại, vì vậy hệ thống có yêu cầu về tính sẵn sàng cao. Nếu xảy ra lỗi hệ
thống trong khi kết nối đang được thiết lập, kết nối này thường có thể khôi phục nhanh
chóng. Trao đổi công tắc thường có thể đặt lại hệ thống và thử kết nối lại. Điều này có
thể được thực hiện rất nhanh chóng và người dùng điện thoại thậm chí có thể không
nhận thấy rằng một lỗi đã xảy ra. Hơn nữa, ngay cả khi cuộc gọi bị gián đoạn, hậu quả
thường không nghiêm trọng. Do đó, tính khả dụng hơn là độ tin cậy là yêu cầu chính
về độ tin cậy đối với loại hệ thống này.
Độ tin cậy và tính khả dụng của hệ thống có thể được định nghĩa chính xác hơn như
sau:
- Độ tin cậy: Xác suất hoạt động không bị lỗi trong một thời gian cụ thể,
trongmột môi trường nhất định, cho một mục đích cụ thể.
- Tính khả dụng: Xác suất để một hệ thống, tại một thời điểm, sẽ hoạt động và có
thể cung cấp các dịch vụ được yêu cầu.
Một trong những vấn đề thực tế trong việc phát triển các hệ thống đáng tin cậy là các
khái niệm về độ tin cậy và tính khả dụng đôi khi rộng hơn các định nghĩa hạn chế này.
Định nghĩa về độ tin cậy nói rằng môi trường trong đó hệ thống được sử dụng và mục
đích mà nó được sử dụng phải được tính đến. Nếu bạn đo lường độ tin cậy của hệ
thống trong một môi trường, bạn không thể cho rằng độ tin cậy sẽ tương tự nếu hệ
thống được sử dụng theo một cách khác.
Ví dụ: giả sử bạn đo lường độ tin cậy của trình xử lý văn bản trong môi trường văn
phòng nơi hầu hết người dùng không quan tâm đến hoạt động của phần mềm. Họ làm
theo hướng dẫn sử dụng và không cố gắng thử nghiệm với hệ thống. Nếu sau đó bạn
đo độ tin cậy của cùng một hệ thống trong môi trường đại học, thì độ tin cậy có thể
khá khác nhau. Tại đây, sinh viên có thể khám phá ranh giới của hệ thống và sử dụng
hệ thống theo những cách không mong muốn. Điều này có thể dẫn đến lỗi hệ thống
không xảy ra trong môi trường văn phòng hạn chế hơn. Các định nghĩa tiêu chuẩn này
về tính khả dụng và độ tin cậy không tính đến mức độ nghiêm trọng của sự thất bại
hoặc hậu quả của việc không có sẵn. Mọi người thường chấp nhận các lỗi hệ thống
nhỏ nhưng rất quan tâm đến các lỗi nghiêm trọng có chi phí do hậu quả. Ví dụ: các lỗi

8
máy tính làm hỏng dữ liệu được lưu trữ ít hơn có thể chấp nhận được so với các lỗi
làm đóng băng máy và điều đó có thể được giải quyết bằng cách khởi động lại máy
tính.Một định nghĩa chặt chẽ về độ tin cậy liên quan đến việc triển khai hệ thống với
đặc điểm kỹ thuật của nó. Đó là, hệ thống đang hoạt động một cách đáng tin cậy nếu
hành vi của nó phù hợp với được xác định trong đặc điểm kỹ thuật. Tuy nhiên, một
nguyên nhân phổ biến của sự không đáng tin cậy được cho là rằng đặc tả hệ thống
không phù hợp với mong đợi của người sử dụng hệ thống. Thật không may, nhiều
thông số kỹ thuật không đầy đủ hoặc không chính xác và các kỹ sư phần mềm phải
giải thích cách hệ thống hoạt động. Vì chúng không phải là miền , do đó, họ có thể
không thực hiện hành vi mà người dùng mong đợi. Nó cũng là tất nhiên là đúng, rằng
người dùng không đọc các thông số kỹ thuật của hệ thống. Do đó, họ có thể có kỳ
vọng không thực tế của hệ thống.
Tính khả dụng và độ tin cậy rõ ràng được liên kết với nhau vì lỗi hệ thống có thể làm
hỏng hệ thống. Tuy nhiên, tính khả dụng không chỉ phụ thuộc vào số lượng sự cố hệ
thống, mà còn vào thời gian cần thiết để sửa chữa các lỗi đã gây ra hỏng hóc.
Do đó, nếu hệ thống A bị lỗi mỗi năm một lần và hệ thống B bị lỗi mỗi tháng một lần
thì A sẽ Sau đó rõ ràng là đáng tin cậy hơn B. Tuy nhiên, giả sử rằng hệ thống A mất
ba ngày để khởi động lại sau khi bị lỗi, trong khi hệ thống B mất 10 phút để khởi động
lại. Sự có sẵn của hệ thống B trong năm (120 phút ngừng hoạt động) tốt hơn nhiều so
với hệ thống A (4.320 phút ngừng hoạt động). Sự gián đoạn do hệ thống không khả
dụng gây ra không được phản ánh trong chỉ số tính khả dụng đơn giản chỉ định phần
trăm thời gian mà hệ thống khả dụng. Các thời gian hệ thống bị lỗi cũng đáng kể. Nếu
hệ thống không khả dụng trong một giờ mỗi ngày từ 3 giờ sáng đến 4 giờ sáng, điều
này có thể không ảnh hưởng đến nhiều người dùng. Tuy nhiên, nếu cùng một hệ thống
không khả dụng trong 10 phút trong ngày làm việc, hệ thống không có sẵn có thể sẽ có
ảnh hưởng lớn hơn nhiều.
Thuật ngữ Miêu tả
Lỗi của con người Hành vi của con người dẫn đến việc đưa các lỗi vào một hệ
hoặc sai lầm thống. Vì, trong hệ thống thời tiết hoang dã, một lập trình
viên có thể quyết định rằng cách tính thời gian cho lần truyền
tiếp theo là thêm 1 giờ vào thời điểm hiện tại. Điều này hoạt
động trừ khi thời gian truyền giữa 23:00 và nửa đêm (nửa
đêm là 00:00 trong đồng hồ 24 giờ)
Lỗi hệ thống Một đặc tính của hệ thống phần mềm có thể dẫn đến lỗi hệ
thống. Lỗi bao gồm mã để thêm 1 giờ thời điểm truyền cuối
cùng, mà không cần kiểm tra nếu thời gian lớn hơn hoặc
bằng 23:00
Lỗi hệ thống Trạng thái hệ thống sai có thể dẫn đến hành vi hệ thống
không mong muốn bởi người dùng hệ thống. Giá trị của thời
gian truyền được đặt không chính xác (thay vì là 24.XX
hơn 00.XX) khi mã bị lỗi được thực thi.
Lỗi hệ thống Một sự kiện xảy ra tại một số thời điểm khi hệ thống phân
phối một dịch vụ như mong đợi của người dùng. Không có
dữ liệu thời tiết nào được truyền vì thời gian không hợp lệ
9
Hình 11.3 Thuật ngữ độ tin cậy
Các vấn đề về độ tin cậy và tính khả dụng của hệ thống chủ yếu do lỗi hệ thống. Một
số lỗi này là hậu quả của lỗi thông số kỹ thuật hoặc lỗi trong các lỗi khác các hệ thống
liên quan như hệ thống thông tin liên lạc. Tuy nhiên, nhiều thất bại là một hậu quả của
hành vi hệ thống sai lầm bắt nguồn từ các lỗi trong hệ thống. Khi thảo luận về độ tin
cậy, sẽ hữu ích khi sử dụng thuật ngữ chính xác và phân biệt giữa các thuật ngữ "lỗi",
"lỗi" và "thất bại". Tôi đã định nghĩa các thuật ngữ này trong
Hình 11.3 và đã minh họa từng định nghĩa với một ví dụ từ vùng hoang dã hệ thống
thời tiết. Khi một đầu vào hoặc một chuỗi các đầu vào khiến mã bị lỗi trong hệ thống
được thực thi, trạng thái sai được tạo ra có thể dẫn đến lỗi phần mềm. Hình 11.4,bắt
nguồn từ Littlewood (1990), cho thấy một hệ thống phần mềm dưới dạng ánh xạ của
một tập hợp đầu vào cho một tập hợp các đầu ra. Đưa ra một đầu vào hoặc chuỗi đầu
vào, chương trình phản hồi bằng sản xuất một đầu ra tương ứng. Ví dụ: được cung cấp
đầu vào của một URL, một trang web trình duyệt tạo ra một đầu ra là hiển thị trang
web được yêu cầu
Hầu hết các đầu vào không dẫn đến lỗi hệ thống. Tuy nhiên, một số đầu vào hoặc kết
hợp đầu vào, được hiển thị trong hình elip bóng mờ tức là trong Hình 11.4, gây ra lỗi
hệ thống hoặc đầu ra sai sót được tạo ra. Độ tin cậy của chương trình phụ thuộc vào số
lượng đầu vào hệ thống là thành viên của tập hợp các đầu vào dẫn đến đầu ra sai. Nếu
đầu vào trong tập hợp tức là được thực thi bởi các bộ phận được sử dụng thường xuyên
của hệ thống, khi đó các lỗi sẽ xảy ra thường xuyên. Tuy nhiên, nếu các đầu vào trong
tức là được thực thi bằng mã hiếm khi đã qua sử dụng thì người dùng sẽ rất ít khi gặp
lỗi. Bởi vì mỗi người dùng của một hệ thống sử dụng nó theo những cách khác nhau,
họ có những nhận thức khác nhau về độ tin cậy của nó.

Nguyên nhân đầu vào


Bộ đầu vào Ie
Kết quả đầu ra

Chương trình

Sai
Bộ đầu ra Oe Kết quả đầu ra

10
Hình 11.4: Bản đồ hệ thống đầu vào/đầu ra
Các lỗi ảnh hưởng đến độ tin cậy của hệ thống đối với một người dùng có thể không
bao giờ được tiết lộ dưới chế độ làm việc của người khác (Hình 11.5). Trong Hình
11.5, tập hợp các đầu vào sai tương ứng với hình elip có nhãn Ie trong Hình 11.4. Bộ
của đầu vào do Người dùng 2 tạo ra giao nhau với tập hợp đầu vào sai này. Người
dùng 2 sẽ do đó gặp một số lỗi hệ thống. Tuy nhiên, người dùng 1 và người dùng 3
không bao giờ sử dụng đầu vào từ bộ sai. Đối với họ, phần mềm sẽ luôn đáng tin
cậy.Độ tin cậy thực tế của một chương trình phụ thuộc vào số lượng đầu vào gây ra lỗi
đầu ra (lỗi) trong quá trình sử dụng bình thường của hệ thống bởi hầu hết người dùng.
Lỗi phần mềm điều đó chỉ xảy ra trong các tình huống ngoại lệ có rất ít ảnh hưởng
thực tế đến độ tin cậy của hệ thống. Do đó, việc loại bỏ các lỗi phần mềm có thể không
cải thiện đáng kể độ tin cậy chung của hệ thống.
Mills và cộng sự (1987) phát hiện ra rằng loại bỏ 60% lỗi trong phần mềm của họ dẫn
đến cải thiện độ tin cậy 3%. Adams (1984), trong một nghiên cứu của các sản phẩm
phần mềm IBM, lưu ý rằng nhiều lỗi trong sản phẩm chỉ có khả năng gây ra hỏng hóc
sau hàng trăm, hàng nghìn tháng sử dụng sản phẩm. Lỗi hệ thống không phải lúc nào
cũng dẫn đến lỗi hệ thống và lỗi hệ thống không nhất thiết dẫn đến lỗi hệ thống. Lý do
cho điều này là như sau:
1. Không phải tất cả mã trong một chương trình đều được thực thi. Mã có lỗi (ví
dụ: không thể khởi tạo một biến) có thể không bao giờ được thực thi vì cách mà
phần mềm được sử dụng.
2. Lỗi chỉ là thoáng qua. Một biến trạng thái có thể có giá trị không chính xác do
thực thi mã bị lỗi. Tuy nhiên, trước khi điều này được truy cập và gây ra lỗi hệ
thống, một số đầu vào hệ thống khác có thể được xử lý để đặt lại trạng thái về
giá trị hợp lệ.
3. Hệ thống có thể bao gồm các cơ chế phát hiện và bảo vệ lỗi. Này đảm bảo rằng
hành vi sai sót được phát hiện và sửa chữa trước khi các dịch vụ hệ thống bị ảnh
hưởng.

Người
Sai
dùng 1
Khả thi Đầu vào
Đầu vào
Người
dùng 2
Người
dùng 3

11
Hình 11.5: Cách sử dụng phần mềm

Một lý do khác tại sao các lỗi trong hệ thống có thể không dẫn đến lỗi hệ thống là:
trong thực tế, người dùng điều chỉnh hành vi của họ để tránh sử dụng đầu vào mà họ
biết là nguyên nhân chương trình bị lỗi. Người dùng có kinh nghiệm "làm việc xung
quanh" các tính năng phần mềm mà họ có được thấy là không đáng tin cậy. Ví dụ, tôi
tránh một số tính năng nhất định, chẳng hạn như đánh số tự động trong hệ thống xử lý
văn bản mà tôi đã sử dụng để viết cuốn sách này. Khi tôi sử dụng đánh số tự động, nó
thường bị sai. Sửa chữa các lỗi trong các tính năng không sử dụng làm cho không có
sự khác biệt thực tế đối với độ tin cậy của hệ thống. Khi người dùng chia sẻ thông tin
về các vấn đề và cách giải quyết, ảnh hưởng của các sự cố phần mềm sẽ giảm
Sự phân biệt giữa lỗi, lỗi và hư hỏng, được giải thích trong Hình 11.3, giúp xác định
ba cách tiếp cận bổ sung được sử dụng để cải thiện độ tin cậy của hệ thống:
1. Tránh lỗi Các kỹ thuật phát triển được sử dụng để giảm thiểu khả năng xảy ra
sai sót của con người và / hoặc mắc phải những sai lầm trước khi chúng dẫn đến
giới thiệu các lỗi hệ thống. Ví dụ về các kỹ thuật như vậy bao gồm tránh cấu
trúc ngôn ngữ lập trình dễ xảy ra lỗi, chẳng hạn như con trỏ và việc sử dụng
phân tích tĩnh để phát hiện sự bất thường của chương trình.
2. Phát hiện và loại bỏ lỗi Việc sử dụng các kỹ thuật xác minh và xác nhận làm
tăng khả năng các lỗi sẽ được phát hiện và loại bỏ trước khi hệ thống được sử
dụng. Kiểm tra và gỡ lỗi có hệ thống là một ví dụ về kỹ thuật phát hiện lỗi.
3. Khả năng chịu lỗi Đây là những kỹ thuật đảm bảo rằng các lỗi trong hệ thống
không dẫn đến lỗi hệ thống hoặc lỗi hệ thống không dẫn đến lỗi hệ thống. Các
kết hợp các phương tiện tự kiểm tra trong một hệ thống và sử dụng các thiết bị
dự phòng mô-đun hệ thống là ví dụ về kỹ thuật chịu lỗi.
Ứng dụng thực tế của các kỹ thuật này được thảo luận trong Chương 13, bao gồm các
kỹ thuật cho kỹ thuật phần mềm đáng tin cậy.

11.3 SỰ AN TOÀN

Các hệ thống quan trọng về an toàn là những hệ thống cần thiết là hoạt động của hệ
thống luôn an toàn; Đó là, hệ thống không bao giờ nên làm tổn thương con người hoặc
môi trường của hệ thống ngay cả khi hệ thống thất bại. Ví dụ về các hệ thống quan
trọng về an toàn bao gồm điều khiển và hệ thống giám sát trong máy bay, hệ thống
kiểm soát quy trình trong các nhà máy hóa chất và dược phẩm, và hệ thống điều khiển
ô tô.
Kiểm soát phần cứng của các hệ thống quan trọng về an toàn đơn giản hơn để thực
hiện và phân tích hơn là kiểm soát phần mềm. Tuy nhiên, bây giờ chúng tôi xây dựng
các hệ thống phức tạp đến mức chúng không thể được kiểm soát bởi phần cứng một
mình. Kiểm soát phần mềm là điều cần thiết vì nhu cầu quản lý số lượng lớn các cảm
12
biến và bộ truyền động với luật điều khiển phức tạp. Ví dụ, máy bay quân sự tiên tiến,
không ổn định về khí động học, yêu cầu điều chỉnh phần mềm điều khiển liên tục bề
mặt chuyến bay của chúng để đảm bảo rằng chúng không bị rơi.
Phần mềm quan trọng về an toàn rơi vào hai lớp:
1. Phần mềm quan trọng về an toàn chính (Primary safety-critical software) Đây
là phần mềm được nhúng như một bộ điều khiển trong một hệ thống. Sự cố của
phần mềm như vậy có thể gây ra sự cố phần cứng, dẫn đến thương tích của con
người hoặc thiệt hại môi trường. Phần mềm bơm insulin, được giới thiệu trong
Chương 1, là một ví dụ về một hệ thống an toàn quan trọng chính. Lỗi hệ thống
có thể dẫn đến chấn thương người dùng.
2. Phần mềm an toàn thứ cấp quan trọng (Secondary safety-critical software) Đây
là phần mềm có thể gián tiếp dẫn đến chấn thương. Một ví dụ về phần mềm như
vậy là một hệ thống thiết kế kỹ thuật hỗ trợ máy tính có trục trặc có thể dẫn đến
lỗi thiết kế trong đối tượng được thiết kế. Lỗi này có thể gây thương tích cho
con người nếu hệ thống thiết kế bị trục trặc. Một ví dụ khác về một hệ thống
quan trọng về an toàn thứ cấp là hệ thống quản lý chăm sóc sức khỏe tâm thần,
MHC-PMS. Sự thất bại của hệ thống này, theo đó một bệnh nhân không ổn
định có thể không được điều trị đúng cách, có thể dẫn đến bệnh nhân đó làm tổn
thương bản thân hoặc người khác.
Độ tin cậy của hệ thống và an toàn hệ thống có liên quan nhưng một hệ thống đáng tin
cậy có thể không an toàn và ngược lại. Phần mềm vẫn có thể hoạt động theo cách mà
hành vi hệ thống kết quả dẫn đến tai nạn. Có bốn lý do tại sao các hệ thống phần mềm
đáng tin cậy không nhất thiết phải an toàn:
1. Chúng ta không bao giờ có thể chắc chắn 100% rằng một hệ thống phần mềm
không có lỗi và lỗi. Lỗi không được phát hiện có thể không hoạt động trong
một thời gian dài và lỗi phần mềm có thể xảy ra sau nhiều năm hoạt động đáng
tin cậy.
2. Đặc điểm kỹ thuật có thể không đầy đủ ở chỗ nó không mô tả hành vi cần thiết
của hệ thống trong một số tình huống quan trọng. Một tỷ lệ cao các trục trặc hệ
thống (Boehm,1975; Endres, 1975; Lutz, 1993; Nakajo và Kume, 1991) là kết
quả của đặc điểm kỹ thuật chứ không phải là lỗi thiết kế. Trong một nghiên cứu
về các lỗi trong các hệ thống nhúng, Lutz kết luận: ...khó khăn với các yêu cầu
là nguyên nhân gốc rễ chính của các lỗi phần mềm an toàn, đã tồn tại cho đến
khi tích hợp và thử nghiệm hệ thống.
3. Sự cố phần cứng có thể khiến hệ thống hoạt động một cách không thể đoán
trước và trình bày phần mềm với một môi trường không lường trước được. Khi
các thành phần gần như thất bại vật lý, chúng có thể hoạt động thất thường và
tạo ra các tín hiệu nằm ngoài phạm vi có thể được xử lý
bởi phần mềm.

Thuật ngữ Định nghĩa


Tai nạn (hoặc rủi ro) Một sự kiện hoặc chuỗi sự kiện không có kế hoạch dẫn

13
[Accident (or mishap)] đến tử vong hoặc thương tích của con người, thiệt hại về
tài sản hoặc môi trường. Quá liều insulin là một ví dụ về
một tai nạn.

Mối nguy hiểm Một tình trạng có khả năng gây ra hoặc góp phần gây tai
[Hazaed] nạn. Một thất bại của cảm biến đo đường huyết là một ví
dụ về một mối nguy hiểm.

Thiê ̣t hại Một thước đo của sự mất mát do một tai nạn. Thiệt hại có
[Damage] thể bao gồm từ nhiều người bị giết do tai nạn đến thương
tích nhẹ hoặc thiệt hại tài sản. Thiệt hại do quá liều insulin
có thể là chấn thương nghiêm trọng hoặc cái chết của
người sử dụng máy bơm insulin.

Mức độ nghiêm trọng Một đánh giá về thiệt hại tồi tệ nhất có thể xảy ra do một
của mối nguy hiểm mối nguy hiểm cụ thể. Mức độ nghiêm trọng của mối
[Hazard severity] nguy hiểm có thể từ thảm khốc, nơi nhiều người bị giết,
đến nhỏ, nơi chỉ có kết quả thiệt hại nhỏ. Khi một cái chết
cá nhân là một khả năng, một đánh giá hợp lý về mức độ
nghiêm trọng của mối nguy hiểm là 'rất cao'.

Xác suất nguy hiểm Xác suất của các sự kiện xảy ra tạo ra một mối nguy hiểm.
[Hazard probability] Các giá trị xác suất có xu hướng tùy ý nhưng dao động từ
'có thể xảy ra' (giả sử 1/100 cơ hội nguy hiểm xảy ra) đến
'không hợp lý' (không có tình huống nào có thể tưởng
tượng được trong đó mối nguy hiểm có thể xảy ra). Xác
suất của một lỗi cảm biến trong bơm insulin dẫn đến quá
liều có lẽ là thấp.

Rủi ro Đây là thước đo xác suất hệ thống sẽ gây ra tai nạn. Nguy
[Risk] cơ được đánh giá bằng cách xem xét xác suất nguy hiểm,
mức độ nghiêm trọng của mối nguy hiểm và xác suất mối
nguy hiểm sẽ dẫn đến tai nạn. Nguy cơ quá liều insulin có
lẽ từ trung bình đến thấp.

Hình 11.6
4. Người vâ ̣n hành hê ̣ thống có thể tạo ra các đầu vào không chính xác riêng lẻ
nhưng, trong một số trường hợp, có thể dẫn đến sự cố hệ thống. Một ví dụ giai
thoại về điều này đã xảy ra khi một gầm máy bay bị sập trong khi máy bay đang
ở trên mặt đất. Rõ ràng, một kỹ thuật viên đã nhấn một nút hướng dẫn phần
mềm quản lý tiện ích nâng gầm xe. Phần mềm thực hiện hướng dẫn của thợ
máy một cách hoàn hảo. Tuy nhiên, hệ thống nên không được phép chỉ huy trừ
khi máy bay ở trên không.
Một từ vựng chuyên ngành đã phát triển để thảo luận về các hệ thống quan trọng về an
toàn và điều quan trọng là phải hiểu các thuật ngữ cụ thể được sử dụng. Hình 11.6 tóm

14
tắt một số định nghĩa về các thuật ngữ quan trọng, với các ví dụ được lấy từ hệ thống
bơm insulin.
Chìa khóa để đảm bảo an toàn là đảm bảo rằng tai nạn không xảy ra hoặc hậu quả của
tai nạn là tối thiểu. Điều này có thể đạt được theo ba cách bổ sung:
1. Hệ thống tránh nguy hiểm (Hazard avoidance) được thiết kế để tránh các mối
nguy hiểm. Ví dụ, một hệ thống cắt yêu cầu một người vận hành sử dụng hai
tay để nhấn separate buttons simultaneously avoids the hazard of the operator’s
hands being in the blade pathway.
2. Hê ̣ thống phát hiê ̣n và loại bỏ mỗi nguy (Hazard detection and removal) Được
thiết kế để các mối nguy hiểm được phát hiện và loại bỏ trước khi chúng dẫn
đến tai nạn. Ví dụ, một hệ thống nhà máy hóa chất có thể phát hiện áp suất quá
mức và mở van cứu trợ để giảm các áp lực này trước khi xảy ra vụ nổ.
3. Hê ̣ thống hạn chế thiê ̣t hại (Damage limitation The system) Có thể bao gồm các
tính năng bảo vệ giảm thiểu thiệt hại có thể xảy ra do tai nạn. Ví dụ, một động
cơ máy bay thường bao gồm bình chữa cháy tự động.Nếu hỏa hoạn xảy ra, nó
thường có thể được kiểm soát trước khi gây ra mối đe dọa cho máy bay.
Tai nạn thường xảy ra khi nhiều thứ đi sai cùng một lúc. Một phân tích về các vụ tai
nạn nghiêm trọng (Perrow, 1984) cho thấy rằng hầu như tất cả chúng là do sự kết hợp
của các lỗi trong các phần khác nhau của hệ thống. Sự kết hợp không lường trước
được của các lỗi hệ thống con dẫn đến các tương tác dẫn đến lỗi hệ thống tổng thể. Ví
dụ, sự thất bại của một hệ thống điều hòa không khí có thể dẫn đến quá nóng, sau đó
khiến phần cứng hệ thống tạo ra tín hiệu không chính xác. Perrow cũng gợi ý rằng
không thể dự đoán tất cả các kết hợp thất bại có thể xảy ra. Do đó, tai nạn là một phần
không thể tránh khỏi của việc sử dụng các hệ thống phức tạp.
Một số người đã sử dụng điều này như một lập luận chống lại kiểm soát phần mềm.
Do sự phức tạp của phần mềm, có nhiều tương tác hơn giữa các phần khác nhau của hệ
thống. Điều này có nghĩa là có thể sẽ có nhiều sự kết hợp của các lỗi có thể dẫn đến lỗi
hệ thống.
Tuy nhiên, các hệ thống điều khiển bằng phần mềm có thể theo dõi một loạt các điều
kiện hơn so với các hệ thống cơ điện. Chúng có thể được điều chỉnh tương đối dễ
dàng. Họ sử dụng phần cứng máy tính, có độ tin cậy vốn có rất cao và nhỏ về mặt vật
lý và nhẹ. Các hệ thống điều khiển bằng phần mềm có thể cung cấp các khóa liên động
an toàn tinh vi. Chúng có thể hỗ trợ các chiến lược kiểm soát làm giảm lượng thời gian
mọi người cần dành trong môi trường nguy hiểm. Mặc dù kiểm soát phần mềm có thể
giới thiệu nhiều cách hơn trong đó một hệ thống có thể đi sai, nó cũng cho phép giám
sát và bảo vệ tốt hơn và do đó có thể góp phần cải thiện an toàn hệ thống.
Trong mọi trường hợp, điều quan trọng là phải duy trì cảm giác về tỷ lệ về an toàn hệ
thống. Không thể làm cho một hệ thống an toàn 100% và xã hội phải quyết định xem
hậu quả của một tai nạn thường xuyên có xứng đáng với những lợi ích đến từ việc sử
dụng các công nghệ tiên tiến hay không. Đây cũng là một quyết định xã hội và chính
trị về cách triển khai các nguồn lực quốc gia hạn chế để giảm rủi ro cho toàn bộ người
dân.
15
11.4 BẢO MẬT

Bảo mật là một thuộc tính của hệ thống phản ánh khả năng tự bảo vệ của hệ thống từ
các cuộc tấn công bên ngoài, có thể là vô tình hoặc cố ý. Các cuộc tấn công bên ngoài
này có thể thực hiện được vì hầu hết các máy tính đa năng hiện nay đều được nối
mạng và là do đó người ngoài có thể tiếp cận .
Thuật ngữ Định Nghĩa
Tài Sản Một thứ gì đó có giá trị cần được bảo vệ. Nội dung có thể là
chính hệ thống phần mềm hoặc dữ liệu được sử dụng bởi hệ
thống đó.
Sự phơi nhiễm Mất mát hoặc tổn hại có thể xảy ra đối với hệ thống máy tính.
Điều này có thể làm mất mát hoặc hư hỏng dữ liệu, hoặc có
thể mất thời gian và công sức nếu cần khôi phục sau vi phạm
bảo mật.
Lỗ hổng Một điểm yếu trong hệ thống dựa trên máy tính có thể bị lợi
dụng để gây mất mát hoặc tổn hại.
Xâm nhập Khai thác lỗ hổng bảo mật của hệ thống. Nói chung, đây là từ
bên ngoài hệ thống và một nỗ lực có chủ ý để gây ra một số
chết tiệt
Sự đe dọa Các trường hợp có khả năng gây ra tổn thất hoặc tổn hại. Bạn
có thể nghĩ về những điều này như một lỗ hổng hệ thống bị
tấn công.
Quyền điều khiển Một biện pháp bảo vệ làm giảm lỗ hổng của hệ thống. Mã
hóa là một ví dụ về
một biện pháp kiểm soát làm giảm lỗ hổng của hệ thống kiểm
soát truy cập yếu.

Ví dụ về các cuộc tấn công có thể là cài đặt vi rút và ngựa Trojan, sử dụng trái phép
các dịch vụ hệ thống hoặc trái phép sửa đổi hệ thống hoặc dữ liệu của nó. Nếu bạn
thực sự muốn có một hệ thống an toàn, tốt nhất là không để kết nối nó với Internet.
Sau đó, các vấn đề bảo mật của bạn được giới hạn để đảm bảo rằng người dùng được
ủy quyền không lạm dụng hệ thống. Tuy nhiên, trên thực tế, có những lợi ích to lớn từ
việc truy cập mạng đối với hầu hết các hệ thống lớn, vì vậy việc ngắt kết nối Internet
không hiệu quả về chi phí.
Đối với một số hệ thống, bảo mật là khía cạnh quan trọng nhất của độ tin cậy của hệ
thống. Các hệ thống quân sự dành cho thương mại điện tử và các hệ thống liên quan
đến việc xử lý và trao đổi thông tin bí mật phải được thiết kế sao cho chúng đạt được
mức độ bảo mật cao. Ví dụ, nếu hệ thống đặt chỗ của hãng hàng không có sẵn, điều
này gây ra sự bất tiện và một số chậm trễ trong việc xuất vé. Tuy nhiên, nếu hệ thống
không an toàn thì kẻ tấn công có thể xóa tất cả các đặt chỗ và thực tế sẽ không thể tiếp
tục hoạt động hàng không bình thường.
Cũng như các khía cạnh khác của độ tin cậy, có một thuật ngữ chuyên ngành liên quan
đến bảo mật. Một số thuật ngữ quan trọng được thảo luận bởi Pfleeger (Pfleeger và
Pfleeger 2007) được định nghĩa trong Hình 11.7. Hình 11.8 lấy các khái niệm bảo mật
16
được mô tả trong Hình 11.7 và cho thấy chúng liên quan như thế nào đến tình huống
sau được lấy từ MHC-PMS
Nhân viên phòng khám đăng nhập vào MHC-PMS bằng tên người dùng và mật
khẩu. Hệ thống yêu cầu mật khẩu phải dài ít nhất tám chữ cái nhưng cho phép đặt bất
kỳ mật khẩu nào mà không cần kiểm tra thêm. Một tên tội phạm phát hiện ra rằng một
ngôi sao thể thao được trả lương cao đang được điều trị các vấn đề về sức khỏe tâm
thần. Anh ta muốn truy cập bất hợp pháp vào thông tin trong hệ thống này để có thể
tống tiền ngôi sao.
Thuật ngữ Ví dụ
Tài sản Hồ sơ của từng nạn nhân đang tiếp nhận hoặc đã được điều
trị
Sự phơi nhiễm Tổn thất tài chính có thể xảy ra từ những nạn nhân trong
tương lai không tìm cách điều trị vì họ không tin tưởng nơi
sửa chữa để duy trì dữ liệu của họ. Tổn thất tài chính từ
hành động pháp lý của ngôi sao thể thao. Thua danh tiếng.
Lỗ hổng Hệ thống mật khẩu yếu khiến người dùng dễ dàng đặt mật
khẩu có thể đoán được. Id người dùng giống như tên.
Xâm nhập Mạo danh người dùng được ủy quyền
Sự đe dọa Người dùng trái phép sẽ có quyền truy cập vào hệ thống
bằng cách đoán thông tin đăng nhập (tên đăng nhập và mật
khẩu) của người dùng được ủy quyền.
Quyền điều khiển Hệ thống kiểm tra mật khẩu không cho phép mật khẩu
người dùng là tên riêng hoặc từ thường được đưa vào từ
điển.

Bằng cách đóng giả là một người họ hàng có liên quan và nói chuyện với các nhân
viên trong nơi sửa chữa , anh ta khám phá ra cách truy cập vào hệ thống và thông tin
cá nhân về các nhân viên. Bằng cách kiểm tra các huy hiệu tên, anh ta phát hiện ra
tên của một số người được phép truy cập. Sau đó, anh ta cố gắng đăng nhập vào hệ
thống bằng cách sử dụng những tên này và đoán một cách có hệ thống các mật khẩu
có thể có (chẳng hạn như tên trẻ em).
1. Các mối đe dọa đối với tính bảo mật của hệ thống và dữ liệu của nó. Những
điều này có thể tiết lộ thông tin cho những người hoặc chương trình không được
phép có quyền truy cập vào thông tin đó.
2. Các mối đe dọa đối với tính toàn vẹn của hệ thống và dữ liệu của nó. Những
mối đe dọa này có thể làm hỏng hoặc làm hỏng phần mềm hoặc dữ liệu của nó.
3. Các mối đe dọa đối với tính khả dụng của hệ thống và dữ liệu của nó. Các mối
đe dọa này có thể hạn chế quyền truy cập vào phần mềm hoặc dữ liệu của nó
đối với những người dùng được ủy quyền.
Tất nhiên, những mối đe dọa này phụ thuộc lẫn nhau. Nếu một cuộc tấn công làm cho
hệ thống không khả dụng thì bạn sẽ không thể cập nhật thông tin thay đổi theo thời
gian. Điều này có nghĩa là tính toàn vẹn của hệ thống có thể bị xâm phạm. Nếu một
cuộc tấn công thành công và tính toàn vẹn của hệ thống bị xâm phạm thì nó có thể

17
phải được gỡ xuống để sửa chữa sự cố. Do đó tính khả dụng của hệ thống bị giảm
xuống.
Trên thực tế, hầu hết các lỗ hổng trong hệ thống công nghệ xã hội là do lỗi của con
người chứ không phải do các vấn đề kỹ thuật. Mọi người chọn mật khẩu dễ đoán hoặc
viết mật khẩu của họ ở những nơi mà họ có thể được tìm thấy. Quản trị viên hệ thống
mắc lỗi khi thiết lập tệp cấu hình hoặc kiểm soát truy cập và người dùng không cài đặt
hoặc sử dụng phần mềm bảo vệ. Tuy nhiên, như tôi đã thảo luận trong Phần 10.5,
chúng ta phải rất cẩn thận khi phân loại vấn đề là lỗi người dùng. Các vấn đề của con
người thường phản ánh các quyết định thiết kế hệ thống kém, ví dụ như thay đổi mật
khẩu thường xuyên (để người dùng viết ra mật khẩu của họ) hoặc các cơ chế cấu hình
phức tạp.
Các biện pháp kiểm soát mà bạn có thể đặt để tăng cường bảo mật hệ thống có thể so
sánh với các biện pháp kiểm soát về độ tin cậy và an toàn:
1. Tránh lỗ hổng Kiểm soát nhằm đảm bảo rằng các cuộc tấn công không thành
công. Chiến lược ở đây là thiết kế hệ thống sao cho tránh được các vấn đề về bảo
mật. Ví dụ, các hệ thống quân sự nhạy cảm không được kết nối với các mạng công
cộng nên việc truy cập từ bên ngoài là không thể. Bạn cũng nên nghĩ về mã hóa
như một biện pháp kiểm soát dựa trên sự tránh né. Bất kỳ truy cập trái phép nào
vào dữ liệu được mã hóa có nghĩa là kẻ tấn công không thể đọc được. Trong thực
tế, rất tốn kém và mất thời gian để bẻ khóa mã hóa mạnh.
2. Xâm nhập Phát hiện và vô hiệu hóa cuộc tấn công Các điều khiển nhằm phát hiện
và đẩy lùi các cuộc tấn công. Các biện pháp kiểm soát này liên quan đến việc bao
gồm chức năng trong hệ thống giám sát hoạt động của nó và kiểm tra các dạng hoạt
động bất thường. Nếu chúng được phát hiện thì có thể thực hiện hành động như tắt
các bộ phận của hệ thống hạn chế quyền truy cập vào một số người dùng nhất định,
v.v.
3. Hạn chế phơi nhiễm và phục hồi Các biện pháp kiểm soát hỗ trợ khôi phục sau các
sự cố. Những điều này có thể bao gồm từ các chiến lược sao lưu tự động và phản
chiếu thông tin đến các chính sách bảo hiểm bao gồm các chi phí liên quan đến một
cuộc tấn công thành công vào hệ thống.
Nếu không có mức độ bảo mật hợp lý, chúng ta không thể tự tin vào độ tin cậy và an
toàn sẵn có của hệ thống. Các phương pháp xác nhận độ tin cậy và bảo mật khả dụng
giả định rằng phần mềm hoạt động giống như phần mềm đã được cài đặt ban đầu. Nếu
hệ thống đã bị tấn công và phần mềm đã bị xâm phạm theo một cách nào đó (ví dụ:
nếu phần mềm đã được sửa đổi để bao gồm sâu) thì các đối số về độ tin cậy và an toàn
không còn được giữ.
Các lỗi trong quá trình phát triển hệ thống có thể dẫn đến các lỗ hổng bảo mật. Nếu
một hệ thống không phản hồi với các đầu vào không mong muốn hoặc nếu giới hạn
mảng không được kiểm tra thì kẻ tấn công có thể khai thác những điểm yếu này để
giành quyền truy cập vào hệ thống. Các sự cố bảo mật lớn như sâu Internet ban đầu
(Spafford 1989) và sâu Code Red hơn 10 năm sau (Berghel 2001) đã lợi dụng cùng

18
một lỗ hổng. Các chương trình trong C không bao gồm kiểm tra giới hạn mảng nên có
thể ghi đè một phần bộ nhớ bằng mã cho phép truy cập trái phép vào hệ thống.

NHỮNG ĐIỂM CHÍNH


 Sự cố của các hệ thống máy tính quan trọng có thể dẫn đến thiệt hại lớn về kinh
tế.
 Độ tin cậy của hệ thống máy tính là một thuộc tính hệ thống phản ánh mức độ
tin cậy của người dùng đối với hệ thống. Các khía cạnh quan trọng nhất của độ
tin cậy là độ an toàn và bảo mật độ tin cậy sẵn có.
 Tính khả dụng của hệ thống là xác suất hệ thống có thể cung cấp dịch vụ cho
người dùng khi được yêu cầu. Độ tin cậy là xác suất mà các dịch vụ hệ thống sẽ
được phân phối như đã chỉ định.
 Độ tin cậy cảm nhận được liên quan đến xác suất xảy ra lỗi trong vận hành sử
dụng. Một chương trình có thể chứa các lỗi đã biết nhưng người dùng vẫn có
thể cảm nhận được là đáng tin cậy. Họ không bao giờ được sử dụng các tính
năng của hệ thống bị ảnh hưởng bởi lỗi.
 Tính an toàn của hệ thống là một thuộc tính của hệ thống phản ánh khả năng
hoạt động bình thường hoặc bất thường của hệ thống mà không gây thương tích
cho con người hoặc thiệt hại cho môi trường.
 Bảo mật phản ánh khả năng hệ thống tự bảo vệ trước các cuộc tấn công từ bên
ngoài. Các lỗi bảo mật có thể dẫn đến mất khả năng sẵn sàng làm hỏng hệ thống
hoặc dữ liệu của hệ thống hoặc rò rỉ thông tin cho những người không được
phép.
 Nếu không có mức độ bảo mật hợp lý, độ tin cậy và an toàn sẵn có của hệ thống
có thể bị tổn hại nếu các cuộc tấn công bên ngoài làm hỏng hệ thống. Nếu một
hệ thống không đáng tin cậy thì rất khó để đảm bảo an toàn hoặc bảo mật cho
hệ thống vì chúng có thể bị xâm phạm do lỗi hệ thống

ĐỌC THÊM
Sự phát triển của đảm bảo thông tin. Một bài báo xuất sắc thảo luận về sự cần thiết
phải bảo vệ thông tin quan trọng trong một tổ chức khỏi các vụ tai nạn và tấn công. (R.
Cummings IEEE Computer 35 (12) Tháng 12 năm 2002.)
httpdx.doi.org10.1109MC.2002.1106181. Thiết kế Hệ thống Máy tính Quan trọng về
An toàn. Đây là một phần giới thiệu tốt về lĩnh vực hệ thống tới hạn an toàn, trong đó
thảo luận về các khái niệm cơ bản về các mối nguy và rủi ro. Dễ tiếp cận hơn cuốn
sách của Dunns về các hệ thống quan trọng về an toàn. (WR Dunn IEEE Computer 36
(11) Tháng 11 năm 2003.) httpdx.doi.org10.1109MC.2003.1244533. Bí mật và dối trá
Bảo mật kỹ thuật số trong một thế giới có mạng. Một cuốn sách rất đáng đọc về bảo
mật máy tính tiếp cận chủ đề từ góc độ công nghệ xã hội. Các cột Schneiers về các vấn
đề bảo mật nói chung (URL bên dưới) cũng rất tốt. (B. Schneier John Wiley Sons
2004.

19
BÀI TẬP
1. Gợi ý sáu lý do tại sao độ tin cậy của phần mềm lại quan trọng trong hầu hết
các hệ thống công nghệ xã hội.
2. Các kích thước quan trọng nhất của độ tin cậy hệ thống là gì ?
3. Tại sao chi phí đảm bảo độ tin cậy lại tăng theo cấp số nhân khi yêu cầu về độ
tin cậy tăng lên.
4. Đưa ra lý do cho câu trả lời của bạn đề xuất các thuộc tính đáng tin cậy nào có
khả năng quan trọng nhất đối với các hệ thống sau:
a. Máy chủ Internet do ISP cung cấp với hàng nghìn khách hàng
b. Một con dao được điều khiển bằng máy tính được sử dụng trong phẫu
thuật lỗ khóa
c. Hệ thống điều khiển định hướng được sử dụng trong phương tiện phóng
vệ tinh
d. Hệ thống quản lý tài chính cá nhân dựa trên Internet
5. Xác định sáu sản phẩm tiêu dùng có khả năng được kiểm soát bởi hệ thống
phần mềm quan trọng về an toàn.
6. Độ tin cậy và độ an toàn là các thuộc tính liên quan nhưng đáng tin cậy riêng
biệt. Mô tả sự khác biệt quan trọng nhất giữa các thuộc tính này và giải thích tại
sao một hệ thống đáng tin cậy lại có thể không an toàn và ngược lại.
7. Trong một hệ thống sửa chữa được thiết kế để cung cấp các biện pháp sửa chữa
lỗi, hãy đề xuất một nguy cơ có thể phát sinh và đề xuất một tính năng phần
mềm có thể được sử dụng để đảm bảo rằng mối nguy được xác định không dẫn
đến lỗi. Trong thuật ngữ bảo mật máy tính giải thích sự khác biệt giữa một cuộc
tấn công và một mối đe dọa.
8. Sử dụng MHC-PMS làm ví dụ xác định ba mối đe dọa đối với hệ thống này
(ngoài mối đe dọa được trình bày trong Hình 11.8). Đề xuất các biện pháp kiểm
soát có thể được thực hiện để giảm cơ hội tấn công thành công dựa trên các mối
đe dọa này.
9. Là một chuyên gia về bảo mật máy tính, bạn đã được tiếp cận bởi một tổ chức
vận động cho quyền của các nạn nhân bị tra tấn và được yêu cầu giúp tổ chức
này truy cập trái phép vào hệ thống máy tính của một công ty Mỹ. Điều này sẽ
giúp họ xác nhận hoặc phủ nhận rằng công ty này đang bán thiết bị được sử
dụng trực tiếp trong việc tra tấn tù nhân chính trị. Thảo luận về các tình huống
khó xử về đạo đức mà yêu cầu này đặt ra và cách bạn sẽ phản ứng với yêu cầu
này.

NGƯỜI GIỚI THIỆU


Adams EN (1984). Tối ưu hóa dịch vụ phòng ngừa của các sản phẩm phần mềm. IBM
J. Res Dev. 28 (1) 214.
Berghel, H. (2001). sự kiện sâu máy tính mã đỏ. Comm. ACM, 44 (12), 15–19
Boehm BW McClean RL và Urfig DB (1975). Một số kinh nghiệm về hỗ trợ tự động
để thiết kế phần mềm đáng tin cậy quy mô lớn. IEEE Trans. về Kỹ thuật phần
mềm. ĐN-1 (1) 12533.

20
Ellison R. Linger R. Lipson H. Mead N. và Moore A. (2002). Cơ sở của Kỹ thuật Hệ
thống Sống sót. Crosstalk Tạp chí Công nghệ Phần mềm Quốc phòng 12 1015.
Ellison RJ Fisher DA Linger RC Lipson HF Longstaff TA và Mead NR (1999a). Khả
năng sống sót Bảo vệ các hệ thống quan trọng của bạn. Máy tính Internet IEEE 3 (6)
5563.
Ellison RJ Linger RC Longstaff T. và Mead NR (1999b). Phân tích hệ thống mạng có
thể tồn tại Một nghiên cứu điển hình. Phần mềm IEEE 16 (4) 707.
Endres A. (1975). Phân tích các lỗi và nguyên nhân của chúng trong các chương trình
hệ thống. IEEE Trans. về Kỹ thuật phần mềm. SE-1 (2) 1409
Laprie J.-C. (1995). Các khái niệm máy tính đáng tin cậy Giới hạn thách thức. FTCS-
25 Hội nghị chuyên đề IEEE lần thứ 25 về Máy tính chịu lỗi Pasadena Calif. IEEE
Press.
Littlewood B. (1990). Mô hình tăng trưởng độ tin cậy của phần mềm. Trong Sổ tay Độ
tin cậy Phần mềm. Rook P. (biên tập). Amsterdam Elsevier. 401412.
Lutz RR (1993). Phân tích các lỗi yêu cầu phần mềm trong các hệ thống nhúng quan
trọng về an toàn. RE'93 San Diego Calif IEEE.
Mills HD Dyer M. và Linger R. (1987). Kỹ thuật phần mềm phòng sạch. Phần mềm
IEEE 4 (5) 1925
Nakajo T. và Kume H. (1991). Phân tích lịch sử tình huống về mối quan hệ nguyên
nhân-lỗi phần mềm. IEEE Trans. trên phần mềm Eng. 18 (8) 8308.
Perrow C. (1984). Tai nạn Thông thường Sống với Công nghệ Rủi ro Cao. Sách Cơ
bản của New York.
Pfleeger CP và Pfleeger SL (2007). Bảo mật trong Máy tính phiên bản thứ 4. Boston
AddisonWesley.
Spafford E. (1989). Cuộc khủng hoảng và hậu quả của Worm trên
Internet. Comm. ACM 32 (6) 67887.

21
MỤC LỤC
LỜI MỞ ĐẦU................................................................................................................... 2
11.1 Thuộc tính độ tin cậy...............................................................................................3
11.2 Tính khả dụng và độ chuẩn xác..............................................................................7
11.3 Sự an toàn...............................................................................................................12
11.4 Bảo mật................................................................................................................... 15
NHỮNG ĐIỂM CHÍNH................................................................................................19
ĐỌC THÊM...................................................................................................................19
BÀI TẬP......................................................................................................................... 19
NGƯỜI GIỚI THIỆU....................................................................................................20

22
23

You might also like