ch ng 2 cÁc tactichiep/kientrucpm/chuong2.pdf · 2016-11-24 · khoa khoa học & kỹthuật...

Khoa Khoa học & Kỹ thuật Máy tính

Trường ĐH Bách Khoa Tp.HCM© 2015

Môn : Kiến trúc phần mềm

Chương 2 : Các tacticSlide 1

2.1 Định nghĩa thuật ngữ2.2 Các tactics giải quyết tính sẳn sàng ₫ể dùng2.3 Các tactics giải quyết tính dễ sử dụng (Usability)2.4 Các tactic về tính thay ₫ổi ₫ược (Modifiability)2.5 Các tactic giải quyết hiệu suất2.6 Các tactic giải quyết an ninh2.7 Các tactic giải quyết tính có thể kiểm thử ₫ược2.8 Kết chương

Chương 2

CÁC TACTIC





2.1 Định nghĩa thuật ngữ

Tacticta ₫ạt ₫ược các tiêu chí chất lượng thông qua các quyết ₫ịnh thiết kế.Vậy các quyết ₫ịnh thiết kế nào cần thiết cho việc ₫ạt ₫ược 1 chất lượng cụ thể ?Tactic là 1 quyết ₫ịnh thiết kế mà ảnh hưởng ₫ến việc kiểm soát sự ₫áp ứng 1 thuộc tính chất lượng.Chiến lược kiến trúc là tập các tactics ₫ược chọn.





2.1 Định nghĩa thuật ngữ

gói các tacticscác tactic có thể tinh chế các tactic khácsự dư thừa ₫ược tinh chế từ dư thừa dữ liệu và dư thừa code

thí dụ1 tactic giải quyết tính sẳn sàng ₫ể dùng sẽ dẫn ₫ến sự dư thừa.Ẩn chứa : ta cũng cần sự ₫ồng bộ giữa các nhân bản ₫ể ₫ảm bảo copy dư thừa có thể ₫ược dùng nếu bản gốc bị hỏng.





2.2 Các tactics giải quyết tính sẳn sàng ₫ể dùng

Độ lệch của lỗi (Failure)₫ộ lệch giữa thực tế chạy so với hành vi chức năng kỳ vọngcó thể ₫ược quan sát bởi người dùng hệ thống phần mềm

Độ lệch của lỗi và nguyên nhân gây lỗi (fault) : fault : sự kiện cóthể gây ra ₫ộ lệch của lỗiCác tactics giải quyết tính sẳn sàng ₫ể dùng :

giữ fault ₫ừng ₫ể nó thành ₫ộ lệch của lỗithực hiện các sửa chữa có thể.






Tính sẵn sàng ₫ể dùng (Availability)

Phát hiện

Ping/EchoHeartBeatException

Sửa chữa & chuẩn bị phục hồi

VotingThừa chủ ₫ộngThừa thụ ₫ộngDùng secour

Recovery-Reintroduction

bóng ma₫ồng bộ hóa trạng tháicheckpoint/Rollback

Phòng ngừa

Không phục vụGiao tácGiám sát process

Fault Fault bị che

Đã sửa chữa






Phát hiện fault : Ping/Echothành phần 1 tạo 1 ping cho thành phần 2thành phần 1 chờ 1 echo từ thành phần 2trả lời trong khoảng thời gian qui ₫ịnhCó thể dùng cho kiến trúc gồm 1 nhóm các thành phần : chúng cótrách nhiệm hỗ tương trên 1 tác vụCó thể dùng cho kiến trúc client/server : kiểm thử server và ₫ường liên lạcsự phân cấp các phần tử phát hiện fault sẽ cải tiến việc dùng băng thông.






Phát hiện fault : Heartbeat (nhịp tim)Theo ₫ịnh kỳ, thành phần 1 phát thông báo heartbeat.thành phần 2 lắng nghe thông báonếu không có heartbeat

thành phần 1 ₫ược giả ₫ịnh là hỏngcảnh bảo cho thành phần 3 ₫ể sửa fault

thông báo heartbeat cũng có thể chứa dữ liệu.






Phát hiện fault : Exceptionscác loại fault : omission, crash, timing, responsekhi nhận biết 1 loại fault, 1 exception ₫ược tạo ra : kết quả là fault ₫ược nhận biếtTrình xử lý exception

thi hành trong cùng process mà tạo ra exceptionthường thực hiện 1 chuyển dịch ngữ nghĩa của fault ra 1 dạng dễ xử lý.






Phục hồi sau fault : Votingcác process chạy trên các processor dư thừa nhận thông tin vào như nhau và tính toán ₫ể tạo kết quả (kỳ vọng như nhau)kết quả ₫ược gởi tới voter.Nếu voter phát hiện hành vi lệch lạc của 1 processor nào ₫ó -> voter coi nó bị hỏng.Phương pháp ₫ược dùng ₫ể sửa chữa

hoạt ₫ộng lỗi của giải thuật₫ộ hư hỏng của processor






Phục hồi sau khi hỏng : sự dư thừa chủ ₫ộng (active redundancy)tất cả các thành phần dư thừa ₫ều ₫áp ứng với sự kiện 1 cách ₫ồng thời -> chúng có cùng trạng thái.chỉ dùng 1 ₫áp ứng từ 1 thành phần nào ₫ó.downtime : thời gian chuyển sang thành phần ₫ược cập nhật khác (ms)₫ược dùng trong cấu hình client/server (hệ thống database) : ₫áp ứng nhanh là quan trọngSự ₫ồng bộ hóa : tất cả thông báo tới 1 thành phần ₫ều phải ₫ược gởi tới tất cả thành phần dư thừa còn lại.






Phục hồi sau khi hỏng : sự dư thừa thụ ₫ộng (passive redundancy)thành phần chính có nhiệm vụ :

₫áp ứng với sự kiện.thông tin cho các thành phần còn lại (standby state) các updates mà chúng phải làm.

Khi Fault xảy ra : hệ thống kiểm tra xem backup có ₫ủ mới (fresh) không trước khi phục hồi dịch vụ.thường ₫ược dùng trong các hệ thống ₫iều khiểnchuyển ₫ổi ₫ịnh kỳ thành phần chính sẽ gia tăng tính sẵn sàng ₫ểdùng.






Phục hồi sau khi hỏng : phần tử dự phòng (spare)Platform tính toán dự phòng ở trạng thái standby ₫ược cấu hình ₫ểthay thế nhiều thành phần hỏng hóc khác nhau :

phải reboot ₫ể dùng lại cấu hình (mới) của phần mềmkhi failure xảy ra, ta khởi tạo lại trạng thái cho nó.

₫ịnh kỳ ghi checkpoint về trạng thái hệ thống và các tháy ₫ổi trạng thái lên thiết bị vĩnh cửu (disk).downtime : tính theo phút






Tái tạo fault : hoạt ₫ộng bóng mathành phần hỏng hóc trước ₫ây có thể ₫ược chạy trong chế ₫ộshadow.

trong 1 khỏang thời gian₫ể ₫ảm bảo nó tối thiểu hành vi của các thành phần ₫ang vận hành.trước khi phục hồi nó ₫ể vận hành tiếp.






Tái tạo fault : ₫ồng bộ hóa lại trạng tháidư thừa chủ ₫ộng hay thụ ₫ộng : thành phần ₫ược phục hồi cập nhật trạng thái của mình trước khi trở lại làm việc.Cập nhật phụ thuộc vào :

downtimekích thước cập nhậtsố thông báo ₫ược ₫òi hỏi ₫ể cập nhật : tốt nhất là 1, nhiều sẽdẫn tới ₫ộ phực tạp của phần mềm.






Tái tạo fault : checkpoint/rollbackcheckpoint

ghi trạng thái còn ₫úng (nhất quán).₫ược thực hiện ₫ịnh kỳ hay khi ₫áp ứng với sự kiện ₫ặc biệt

hữu dụng khi hệ thống hỏng không thường xuyên với trạng thái không nhất quán có thể phát hiện ₫ược. Hệ thống ₫ược phục hồi bằng :

checkpoint của trạng thái nhất quán ngay trước.nhật ký các transactions xảy ra từ khi chúng bắt ₫ầu hoạt ₫ộng






Phòng ngừa faultBỏ không phục vụ

₫ể cấm các failure tiên ₫oán trước, ta xóa bỏ thành phần liên quanthí dụ boot lại thành phần ₫ể cấm sự thiếu hụt bộ nhớlàm tự ₫ộng hay thủ công

Transaction : các bước tuần tự ₫ược bó lại nhau sao cho toàn bộbó có thể ₫ược undo 1 lần.giám sát process : nếu process hỏng bị phát hiện thì process giám sát sẽ xóa process không làm việc và tạo mới 1 instance khác thay thế : phải ₫ược khởi tạo với trạng thái phù hợp như trong tactic dùng phần tự dự phòng.





2.3 Các tactics giải quyết tính dễ sử dụng (Usability)

tính có thể dùng liên quan ₫ến :hệ thống hỗ trợ cho user những thứ gìngười dùng thực hiện tác vụ mong muốn dễ dàng như thế nào.

các tacticthời gian chạy : hỗ trợ user trong suốt thời gian thi hành của hệthốngtại thời ₫iểm thiết kế : hỗ trợ nhà phát triển interface+ bản chất lặp của việc thiết kế interface+ liên quan tới các tactic giải quyết tính có thể hiệu chỉnh






các tactic tại thời ₫iểm chạyCác phản hồi của user về hệ thống ₫ang làm gìcung cấp cho user khả năng thực hiện các lệnh liên quan ₫ến tính dễ dùng :

CancelUndoTích hợphiển thị nhiều góc nhìn






tính dễ sử dụng

Các tactic tại thời ₫iểm chạy

chủ ₫ộng hệ thống

Các tactic tại thời ₫iểm thiết kế

Tách giao tiếp user

yêu cầu của user

Cung cấp phản hồi và hỗ trợphù hợp cho user

chủ ₫ộng user





2.4 Các tactic về tính thay ₫ổi ₫ược (Modifiability)

mục tiêu: kiểm soát thời gian và chi phí của sự thay ₫ổi nào ₫ótrong việc hiện thực, kiểm thử, hiệu chỉnh và phân phối.tập các tactic

Khoanh vùng các thay ₫ổi : giảm số module bị ảnh hưởng bởi 1 thay ₫ổiphòng ngừa các hiệu ứng dây chuyền : hạn chế việc thay ₫ổi tới các module bị khoanh vùng.trì hoản thời ₫iểm kết nối các module lại : kiểm soát thời gian phân phối và chi phí.






Tính thay ₫ổi ₫ược

Khoanh vùng các thay ₫ổi

Nhất quán ngữ nghĩadự ₫oán các thay ₫ổitổng quát hóa moduledịch vu chung trừu tượng

Ngừa các hiệu ứng dây chuyền

Ẩn thông tinDuy trì giao tiếp tồn tạihạn chế ₫ường liên lạcdùng ptử trung gian

Trì hoản thời ₫iểm liên kết

₫ăng ký tại td chạyfile cấu hìnhĐa xạThay thế thành phầnĐính vào các gt ₫ã có

Các thay ₫ổi tới

Đã thay ₫ổi, kiểm thử, phân phối

trong thời gian và kinh phíxác ₫ịnh






Khoanh vùng các thay ₫ổi : duy trì tính nhất quán ngữ nghĩaTính nhất quán ngữ nghĩa : mối quan hệ giữa các trách nhiệm trong 1 module.Mục tiêu : ₫ảm bảo tất cả trách nhiệm này làm việc cùng nhau cho dù có hay không sự dựa dẫm quá nhiều vào những module khác.Cách ₫ạt mục tiêu : thiết kế các module với các trách nhiệm trong sự nhất quán ngữ nghĩa.






Khoanh vùng các thay ₫ổi : dịch vụ chung trừu tượngTactic con của tính nhất quán ngữ nghĩacung cấp các dịch vụ chung thông qua các module ₫ặc biệtTính dùng lại và tính thay ₫ổi ₫ược

Sự thay ₫ổi tới các dịch vụ chung ₫ược làm chỉ 1 lần thay vìtrong từng module dùng chúng.Các thay ₫ổi trơng các module dùng dịch vụ chung không ảnh hưởng ₫ến các user khác.






Khoanh vùng các thay ₫ổi : tiên ₫oán các thay ₫ổi ₫ược chờ ₫ợiviệc chú ý tập các thay ₫ổi mường tượng cung cấp cách thức ₫ánh giá việc gán các trách nhiệm.Các câu hỏi :

₫ối với 1 thay ₫ổi : sự phân rã mà ta ₫ề nghị có hạn chế tập các module cần thay ₫ổi ?Về cơ bản, các thay ₫ổi khác nhau có ảnh hưởng trên cùng các module ?

Mục tiêu : tối thiểu hóa ảnh hưởng của các thay ₫ổi.






Khoanh vùng các thay ₫ổi : tổng quát hóa module chức năngtổng quát hóa 1 module bằng cách làm cho nó thực hiện 1 lớp rộng các chức năng dựa vào kiểu thông tin nhập.Thông tin nhập : ₫ịnh nghĩa ngôn ngữ cho module

làm các thông số nhập là hằnghiện thực module như 1 trình thông dịch và làm các thông sốnhập như là các chương trình trong ngôn ngữ thông dịch ₫ó.

module tổng quát hơnThích nhất là làm các thay ₫ổi theo yêu cầu bằng cách hiệu chỉnh ngôn ngữ nhập.






Phòng ngữa các hiệu ứng lan truyềnKhoanh vùng các thay ₫ổi / hạn chế các thay ₫ổi trên các module bị khoanh vùng.

Có 1 số module bị tác ₫ộng trực tiếp : ₫ó là các module có các trách nhiệm cần ₫ược ₫iều chỉnh ₫ể thực hiện ₫ược sự thay ₫ổi.Có 1 số module bị tác ₫ộng gián tiếp bởi sự thay ₫ổi : ₫ó là các module có các trách nhiệm vẫn không ₫ổi nhưng sự hiện thực cần ₫ược thay ₫ổi ₫ể phù hợp với các module bị tác ₫ộng trực tiếp.






Các hiệu ứng lan truyềnHiệu ứng lan truyền từ 1 thay ₫ổi :

sự cần thiết thay ₫ổi các module không bị tác ₫ộng trực tiếp bởi nó.₫iều này xảy ra vì các module ₫ược ₫ề cập phụ thuộc ít nhiều vào các module liên quan trực tiếp ₫ến sự thay ₫ổi.






Các kiểu phụ thuộcTa giả sử :

module A thay ₫ổi ₫ể thực hiện sự thay ₫ổi nào ₫ó.module B bị thay ₫ổi chỉ vì module A thay ₫ổi.

Có nhiều kiểu phụ thuộc : cú pháp, ngữ nghĩa, tuần tự, identity of interface, location of A, quality of service, existence of A, resource behavior of A.






Sự phụ thuộc cú phápcủa data :

B dùng dữ liệu ₫ược tạo bởi Akiểu và ₫ịnh dạng dữ liệu trong cả 2 module A và B cần ₫ược nhất quán nhau.

của dịch vụ :B cầu cứu dịch vụ của Achữ ký các dịch vụ ₫ược cung cấp bởi A cần nhất quán với kỳvọng của B.






Sự phụ thuộc ngữ nghĩacủa data :

B dùng dữ liệu ₫ược tạo bởi Angữ nghĩa dữ liệu ₫ược tạo ra bởi module A và ₫ược dùng bởi B cần ₫ược nhất quán với kỳ vọng của B.

của dịch vụ :B cầu cứu dịch vụ của Angữ nghĩa các dịch vụ ₫ược cung cấp bởi A cần nhất quán với kỳ vọng của B.






Sự phụ thuộc tuần tựcủa data :

B dùng dữ liệu ₫ược tạo bởi AB phải nhận dữ liệu ₫ược tạo ra bởi A theo trình tự cố ₫ịnh biết trước.

của ₫iều khiển :A phải ₫ược thi hành trước trong khoảng thời gian ràng buộc xác ₫ịnh.






Sự ₫ồng nhất về interface của AA phải có nhiều interface sử dụngB dùng 1 trong chúngĐể B ₫ược dịch và thi hành ₫úng, sự ₫ồng nhất của interface phải nhất quán với các kỳ vọng của B.






Các sự phụ thuộc khácvị trí chạy của A : phải nhất quán với kỳ vọng của Bchất lượng dịch vụ/data ₫ược cung cấp bởi A : các tính chất liên quan ₫ến chất lượng phải nhất quán với kỳ vọng của B.sự tồn tại của A : Để B thi hành ₫ược, A phải tồn tại ₫ể sẳn sàng phục vụ.Hành vi tài nguyên của A : phải nhất quán với các kỳ vọng của B.






Các tactic ₫ể phòng ngừa hiệu ứng lan truyềnẨn thông tinduy trì các interface tồn tạihạn chế các ₫ường liên lạcdùng phần tử trung gian






Ẩn thông tinPhân rã các trách nhiệm ra những phần nhỏ hơn và chọn thông tin nào ₫ể ẩn và thông tin nào ₫ể public.thông tin public có thể dùng ₫ược thông qua interface xác ₫ịnhMục tiêu : ngăn các thay ₫ổi trong 1 module và ngừa các thay ₫ổi lan truyền từ module này sang module khác.

kỹ thuật cũ nhất từ việc cấm các thay ₫ổi lan truyềnliên quan mạnh tới tiên ₫oán các thay ₫ổi chờ ₫ợi (ta dùng các thay ₫ổi này làm cơ sở cho việc phân rã).






Duy trùy các interface luôn tồn tạiCú pháp của B phụ thuộc vào interface của A : duy trì interface của A sẽ làm B không thay ₫ổi.Sự ổn ₫ịnh interface : tách interface với sự hiện thực nóCách hiện thực tactic

thêm interfacethêm adaptercung cấp stub cho A






Hạn chế các ₫ường liên lạchạn chế số module dùng chung data với A (A cần thay ₫ổi)

hạn chế số module mà dùng dữ liệu do A cung cấphạn chế số module mà cung cấp dữ liệu cho A dùng.

-> giảm ₫ược hiệu ứng lan truyền- sản xuất/tiêu dùng dữ liệu sẽ tạo ra sự phụ thuộc.






Dùng phần tử trung gianB phụ thuộc A theo các cách khác hơn ngữ nghĩa :

có thể tạo ra phần tử trung gian ₫ể quản lý sự phụ thuộcdata (cú pháp), dịch vụ (cú pháp), vị trí của A, sự tồn tại của A






Trì hoản thời gian liên kếtsự quyết ₫ịnh liên kết A vào hệ thống thực thi ở những thời ₫iểm khác nhau.Liên kết tại thời ₫iểm chạy :

hệ thống ₫ã chuẩn bị ₫ể làm việc liên kết này.tất cả bước kiểm thử và phân tán ₫ã hoàn thành rồihỗ trợ người dùng ₫ầu cuối/admin làm các thiết lập hay cung cấp input mà ảnh hưởng ₫ến hành vi.






Các tactic mà ảnh hưởng tại thởi ₫iểm load/chạy₫ăng ký tại thời gian chạy : hoạt ₫ộng plug-and-play, nỗ lực hơn ₫ể quản lý việc ₫ăng kýfile cấu hình : thiết lập các thông số tại thời ₫iểm bắt ₫ầu₫a xạ : liên kết muộn các lời gởi thông ₫iệpThay thế thành phần : liên kết tại thời ₫iểm loadsự ₫ính vào các giao thức ₫ã ₫ịnh nghĩa : liên kết tại thời ₫iểm chạy các process ₫ộc lập.





2.5 Các tactic giải quyết hiệu suất

Mục tiêu : tạo ₫áp ứng với sự kiện tới hệ thống trong khoảng thời gian ràng buộc.event : ₫ơn hay dòng (stream) : thông báo ₫ến, hết giờ, sự thay ₫ổi trạng thái có ý nghĩa,...Độ trễ : khoảng thời gian từ lúc sự kiện xảy ra tới lúc có ₫áp ứng với nó.sự kiện ₫ến : hệ thống xử lý nó hay giam việc xử lý.






Hiệu suất

Xin tài nguyên

Tăng hiệu quả tínhGiảm chí phí tínhQuản lý tốc ₫ộ eventKiểm soát ần số lấy mẫu

Quản lý tài nguyên

Tạo sự ₫ồng thờiQuản lý các copyTăng tài nguyên có sẵn

Trọng tài tài nguyên

Chính sách lập lịch

Các sựkiện tới Đã ₫áp ứng

trong thời gian xác ₫ịnh






Tactic xin tài nguyênNguồn gốc của việc xin gài nguyên : dòng sự kiện tớiCác tính chất xin :

thời gian giữa các sự kiện trong dòng tài nguyên (request vào dòng thường xuyên ra sao)mỗi request dùng ₫ược bao nhiêu % của từng tài nguyên

Tactic giảm ₫ộ trễgiảm tài nguyên cần dùnggiảm số sự kiện ₫ược xử lý






Giảm số tài nguyên cần dùnggia tăng sự kiệu quả tính toán

việc xử lý liên quan ₫ến giải thuật -> cải tiến giải thuậtcó thể trao ₫ổi tài nguyên với process khác

giảm chi phí tính toánnếu không có request nào cần tài nguyên -> cần giảm thiểu nhu cầu tính toán của nó.loại bỏ các phần tử trung gian






Giảm số sự kiện ₫ược xử lýquản lý tốc ₫ộ xảy ra sự kiện : giảm tần số lấy mẫu cho việc giám sát các biến môi trườngkiểm soát tần số lấy mẫu : nếu không cần kiểm soát sự xuất hiện của các sự kiện ₫ược tạo ra từ ngoài thì các request ₫ợi có thể ₫ược lấy mẫu ở tần số thấp hơn (có thể mất request)hạn chế thời gian thi hành : giới hạn cận trên thời gian thi hành ₫ược dùng cho mỗi sự kiệnhạn chế kích thước hàng ₫ợi : kiểm soát số max các sự kiện ₫ến hàng ₫ợi.






Quản lý tài nguyêntạo ra sự ₫ồng thời : xử lý các request ₫ồng thời

các dòng sự kiện khác nhau ₫ược xử lý trên các thread khác nhau (tạo thêm thread khi cần)cân bằng tải

duy trì nhiều copy của 1 dữ liệu và sự tính toán : cache và ₫ồng bộhóagia tăng tài nguyên sẳn sàng dùng : nếu các processor và mạng nhanh hơn, thì sẽ có thêm processor và bộ nhớ






Trọng tài phân xử tài nguyênTranh chấp tài nguyên -> cần lập lịch dùng tài nguyênmục tiêu kiến trúc :

hiểu các tính chất của mỗi việc dùng tài nguyên và chọn lựa lịch thích hợphiểu tiêu chí có thể mâu thuẩn trong việc lập lịch và hiệu ứng của tactic ₫ược chọn

chính sách lập lịchgán quyền ưu tiêndispatching






Lập lịchcho cái gì ? mạng, buffer, processortiêu chí cạnh tranh nhau trong lập lịch

dùng tài nguyên tối ưu₫ộ quan trọng của requesttối thiểu số tài nguyên ₫ược dùngtối thiểu ₫ộ trễtối ₫a hiệu năngphòng ngừa tình trạng bảo hòa ₫ể ₫ảm bảo sự công bằng

dispatching có thể xảy ra chỉ khi tài nguyên ₫ược gán ₫ang sẵn sàng

pre-empty có thể xảy ra






Các chính sách lập lịchFIFO : Ok nếu tất cả request có cùng ₫ộ quan trọng và dùng cùng 1 khoảng thời gian thi hành.dựa vào quyền ưu tiên cố ₫ịnh. Quyền ưu tiên dựa vào :

₫ộ quan trọng ngữ nghĩa (₫ặc thù của lĩnh vực)₫ều ₫ều tốc ₫ộ (stream tuần hòan, period 1 ngắn hơn)₫ều ₫ều deadline (deadline thời gian thực, deadline 1 ngắn nhất

dựa vào quyền ưu tiên ₫ộnground dobindeadline ngắn nhất ₫ược chọn ₫ầu tiên.

lập lịch tĩnh





2.6 Các tactic giải quyết an ninh

Mục tiêu : ngăn chặn tấn công, phát hiện tấn công, phục hồi sau tấn côngMổ xẻ sự phòng chống cho nhà cửa

khóa cửacảm biến ₫ối tượng di ₫ộngbảo hiểm






An ninh

Ngăn chặn tấn công

Xác nhận userCho phép userDuy trì data mậtDuy trì tính toàn vẹnHạn chế bùng nỗHạn chế truy xuất

Phát hiện tấn công

Phát hiện sự xâm nhập

Phục hồi sau tấn công

Nhận dạng

Tấn công

Hệ thống phát hiện, ngăn chặn

hay phục hồi sau tấn công

Phục hồixem Availability

Audit trail






Ngăn chặn tấn côngXác nhận người dùng : dùng account, password, password chỉdùng 1 lần, xác nhận số, id sinh trắc học.cho phép ngời dùng : dùng các mẫu kiểm soát việc truy xuất (ACL)duy trì ₫ộ mật dữ liệu : mã hóa dữ liệu và ₫ường liên lạcduy trì tính toàn vẹn : checksum, hash ₫ưa ₫ến helphạn chế sự bùng nổ : số dịch vụ hạn chế trên mỗi hosthạn chế việc truy xuất : bức tường lửa, DMZ






Phát hiện tấn cônghệ thống phát hiện sự xâm phạm

so sánh mẫu lưu lượng trên mạng với databasemisuse -> mẫu ₫ược so sánh với các mẫu tấn công ₫ã biết trong quá khứ.bất thường -> mẫu ₫ược so với chính baseline quá khứ của nóthanh lọc : protocol, cờ TCP, kích thước payload, ₫ịa chỉ, chỉsố port.phải có : cảm biến ₫ể phát hiện tấn công, người quản lý việc liên hợp các cảm biến, database chứa sự kiện ₫ể phân tích, tool ₫ể phân tích và lập báo cáo offline, console kiểm soát ₫ểhiệu chỉnh các hoạt ₫ộng phát hiện xâm phạm






Các phần tử phát hiện sự xâm phạmcảm biến ₫ể phát hiện xâm phạmngười quản lý việc liên hợp các cảm biếndatabase chứa sự kiện ₫ể phân tích sautool ₫ể phân tích và lập báo cáo offlineconsole kiểm soát ₫ể hiệu chỉnh các hoạt ₫ộng phát hiện xâm phạm.






Phục hồi sau khi bị tấn côngcác tactic ₫ể phục hồi trạng thái

phục hồi về trạng thái nhất quán từ trạng thái không nhất quán : tactic giải quyết tính sẵn sàng ₫ể dùngcopy dư thừa dữ liệu quản trị hệ thống : password, ACL, dịch vụ "domain name", dữ liệu cá nhân người dùng

các tacitc ₫ể nhận dạng kẻ tấn côngcho các mục ₫ích ngăn chặn và trừng phạtduy trì "audit trail"






Audi trailbản copy mỗi giao tác tác ₫ộng tới dữ liệu trong hệ thống + thông tin nhận dạngcó thể dùng ₫ể

theo dõi các hoạt ₫ộng của 1 kẻ tấn cônghỗ trợ sự không thể từ chối : cung cấp sự hiển nhiên về 1 request cụ thể ₫ã ₫ược thực hiện.hỗ trợ việc phục hồi hệ thống

các mục tiêu tấn công thông thường : nên ₫ược duy trì trong thứ tựtin cậy





2.7 Các tactic giải quyết tính có thể kiểm thử ₫ược

mục tiêu : cho phép kiểm thử dễ dàng hơn khi 1 vài tăng cường vềphần mềm ₫ã hoàn thành.việc tăng cường tính có thể kiểm thử ₫ược không phải quá lớn lao nhưng rất có giá trị : 40% chi phí phát triển phần mềmkiểm thử hệ thống ₫ang chạy (không phải ₫ang thiết kế)công cụ kiểm thử :

SW mà cung cấp input cho SW cần kiểm thử và thu bắt kết quảmục tiêu là tìm fault.






tính có thể kiểm thử ₫ược

Quản lý I/O

Record/PlaybackTách interface/hiện thựcCác thủ tục/interface truy xuất ₫ặc biệt

Giám sát bên trong

Các phần tử monitor ₫ược xây dựng sẵn

Hoàn thành sự tăng cường nào

₫óPhát hiệncác fault






Các tactic I/O : record/playbackliên quan ₫ến

việc thu bắt thông tin ₫i ngang qua interfacedùng nó như input cho tool kiểm thử

thông tin ngang qua interface ở hoạt ₫ộng bình thườngxuất từ 1 thành phần, input tới thành phần khác₫ược lưu trong kho+ cho phép ₫ầu vào kiểm thử cho 1 thành phần+ cho kết quả xuất kiểm thử ₫ể so sánh sau ₫ó.






Các tactic I/O : tách interface với hiện thựccho phép việc thay thế hiện thực cho nhiều mục ₫ích kiểm thửkhác nhau

làm stub của hiện thực ₫ể hệ thống ₫ược kiểm thử mà không cần có thành phần thật.thay thế 1 thành phần ₫ặc biệt ₫ể thành phần ₫ược thay thếhoạt ₫ộng như tool kiểm thử cho phần còn lại của hệ thống.

tactic cũng ₫ưa ₫ến tính có thể hiệu chỉnh ₫ược






Các tactic I/O : ₫ặc biệt hóa ₫ường truy xuất/interfcaecó các interface kiểm thử ₫ặc biệt : thu bắt/₫ặc tả các giá trị khác nhau cho các thành phần

thông qua tool kiểm thử1 cách ₫ộc lập từ việc thi hành bình thường

các ₫ường truy xuất ₫ặc biệt/interface : nên ₫ược giữa tách biệt từchức năng ₫òi hỏiphân cấp các interface kiểm thử

các testcase có thể ₫ược áp dụng vào bất kỳ mức kiến trúc nàochức năng kiểm thử phải "in place" ₫ể quan sát các ₫áp ứng






Tactic giám sát bên trongcác phần tử giám sát xây dựng sẵn

thành phần có thể duy trì trạng thái, tải hiệu suất, khả năng, an ninh,... có thể ₫ược truy xuất thông qua interface (interface vĩnh cữu hay tạm ₫ược tạo ra cho kiểm thử).ghi sự kiện khi trạng thái cần giám sát ₫ược kích hoạt+ chí phí/nổ lực kiểm thử thêm nữa+ ₫ộ có thể thấy ₫ược gia tăng.





2.8 Kết chương

Chương này ₫ã giới thiệu các tactics ₫ể giải quyết các yêu cầu phi chức năng chính yếu của phần mềm như tính sẵn sàng ₫ể sửdụng, tính dễ sử dụng, tính thay ₫ổi ₫ược, tính hiệu quả, tính cóthể kiểm thử, an ninh.

ch ng 2 cÁc tactichiep/kientrucpm/chuong2.pdf · 2016-11-24 · khoa khoa học & kỹthuật...

Documents