1 @Aspect
2 abstract c l a s s S e c u r i t y A s p e c t {
3 @Before ( " bean (∗BLogic ) "
4 public void c h e c k ( J o i n P o i n t j p ) { 5 O b j e c t t a r g e t = j p . g e t T a r g e t ( ) ; 6 C l a s s <? extends A b s t r a c t S e c u r i t y G u a r d > t a r g e t C l a s s = 7 ( C l a s s <? extends A b s t r a c t S e c u r i t y G u a r d >) t a r g e t . g e t C l a s s ( ) ; 8 S t r i n g className = t a r g e t C l a s s . getCanonicalName ( ) ; 9 S t r i n g u c I d = className . s u b s t r i n g ( 4 1 , 4 7 ) ; 10 A b s t r a c t S e c u r i t y G u a r d [ ] g u a r d s = 11 A b s t r a c t S e c u r i t y G u a r d . getGuards ( u c I d ) ; 12 f o r( A b s t r a c t S e c u r i t y G u a r d g : g u a r d s ) { 13 g . c h e c k ( ) ;// t h r o w u n a u t h o r i z e d e x c e p t i o n i f any 14 } 15 } 16 }
Trong phương thức check(), chúng ta thực hiện các kiểm tra cần thiết và tạo ngoại lệ truy cập (UnauthorizedException) khi người dùng hiện tại không được phép thực hiện hành động đó.
4.4. Một số chi tiết trong cài đặt chương trình
Chương trình mà chúng tôi đưa ra làm ví dụ minh họa là một hệ thống đã được xây dựng và không sử dụng phương pháp phân tich thiết kế an ninh hệ thống.
Để thực hiện ý tưởng minh họa, chúng tôi tiến hành thêm vào các thành phần (lớp) kiểm tra anh ninh mà không ảnh hưởng tới mã hiện tại của chương trình.
Để phục vụ việc cài đặt các dấu đặc trưng an ninh, chương trình tổ chức một bảng cơ sở dữ liệu (“security_concern”), có cấu trúc như bảng 4.4.
Tên cột Kiểu dữ liệu Giải thích
use_case_id varchar(10) Tên trường hợp sử dụng
sec_stereotype varchar(10) Dấu đặc trưng an ninh tương ứng request_parameter varchar(50) Cách lấy tham số từ yêu cầu HTTP
guard_bean varchar(120) Tên đối tượng kiểm tra trong Spring context
Bảng 4.4: Định nghĩa bảng CSDL mối quan tâm an ninh
Khi mối quan tâm an ninh được gọi qua @Aspect và @Before, phương thức check sẽ sử dụng bảng 4.4 để tìm xem trường hợp sử dụng đang được truy xuất tới thuộc về mối quan tâm an ninh nào để tiến hành gọi lớp kiểm tra an ninh tương ứng.
Trong ví dụ mà chúng tôi đưa ra dưới đây, chúng tôi thử kiểm tra với trường hợp mối quan tâm an ninh là việc truy xuất vào thông tin của công ty không liên quan. Giả sử bằng cách nào đó, người dùng biết được mã số hóa đơn (I/V) của hai công ty A và B và định truy xuất vào hóa đơn đó.
Tiến hành đăng nhập vào hệ thống bằng một người dùng thuộc hai trường hợp:
1. Người dùng (tên đăng nhập: abc) thuộc công ty 4, công ty 4 này thuộc về một kế hoạch vận chuyển trong đó có công ty 2 và công ty 5 (4 là thầu phụ của 2) (Hình 4.9). Trong trường hợp này, hệ thống cho phép công ty 4 được nhìn thấy hóa đơn của công ty 2 và 5, ví dụ: gõ thẳng đường dẫn chứa số I/V đó để vào hệ thống (Hình 4.10).
2. Người dùng (tên đăng nhập: other) thuộc công ty 7, công ty này không có liên quan gì tới 2 và 5. Nếu ta gõ thẳng đường dẫn chứa số I/V đó vào, thì hệ thống phải cho ra một ngoại lệ truy cập (Hình 4.11).
Phương pháp hướng đối tượng và phân tích thiết kế anh ninh hệ thống 63
Hình 4.9: Ví dụ kế hoạch vận chuyển có 5 công ty 5,2,8,6,4
Hình 4.11: Công ty 7 không thể xem được hóa đơn của công ty 2,5s
Kết quả kiểm tra cho thấy hệ thống họat động đúng như ý tưởng đã được chỉ ra trong các biểu đồ trường hợp sử dụng.
Chương 5 KẾT LUẬN
5.1. Những đóng góp của luận văn
Trong bản luận văn này, chúng tôi đã cố gắng nghiên cứu và đề xuất một quy trình giải pháp đơn giản, trên cơ sở phương pháp hướng đối tượng, thích hợp với các dự án cỡ vừa và nhỏ, đòi hỏi không nhiều thời gian phân tích thiết kế, cũng như không đòi hỏi quá nhiều công cụ và kiến thức, kinh nghiệm về UML.
Những đóng góp cơ bản của luận văn là:
1. Phân tích các mối quan tâm an ninh cơ bản: luận văn đã phân tích các mối
quan tâm an ninh cơ bản cho một hệ thống cung cấp dịch vụ trên Internet, để có một cái nhìn tổng quan về vấn đề an ninh.
2. Đề xuất bộ dấu đặc trưng an ninh: luận văn đã đề xuất một tập các ký hiệu dấu
đặc trưng («stereotype») để sử dụng thống nhất trong dự án. (adsbygoogle = window.adsbygoogle || []).push({});
3. Xây dựng quy trình phân tích thiết kế: luận văn đã xây dựng một quy trình để
áp dụng cho một dự án, từ bước phân tích tới thiết kế, cài đặt các mối quan tâm an ninh, mang tính ứng dụng cao.
4. Đưa ra cách cài đặt: luận văn đã đưa ra cách cài đặt các mối quan tâm an ninh
bằng AOP để minh họa ý tưởng đề xuất.
Những đóng góp của luận văn mangtính thực tiễn và tính ứng dụng, phù hợp với các dự án cỡ vừa, khi mà chúng ta không thể có nhiều nhân lực, thời gian cho các yêu cầu phi chức
năng (yêu cầu về an ninh là một yêu cầu phi chức năng).
Phần sau đây, chúng tôi sẽ thử thực hiện so sánh với một số công trình của các tác giả khác.
5.2. So sánh với một số công trình liên quan
Vấn đề phân tích, đặc tả an ninh hệ thống sử dụng UML thu được sự quan tâm của nhiều chuyên gia. Ở đây chúng tôi muốn thực hiện một so sánh nhỏ giữa giải pháp đề ra trong luận văn với một số giải pháp đã được các tác giả khác đề xuất.
Karine P. Peralta,Alex M. Orozco, Avelino F. Zorzo, Flavio M. Oliveira [6] đã
đề xuất một tập hợp các dấu đặc trưng («stereotype») cho phép đặc tả tất cả các tình huống an ninh trên Internet như đã trình bày ở phần 2.2.1. Đây là một đề xuất tổng thể, tuy nhiên, nó đòi hỏi người áp dụng phải có những kiến thức nhất định về UML, về OCL. Phạm vi giải quyết của các tác giả là rộng, nhưng không giải quyết cụ thể vấn đề bảo toàn an ninh giữa các thành phần trong hệ thống, mà tập trung vào phương pháp mô hình hóa và sinh các ca kiểm thử. Các tác giả cũng chưa đề cập tới phương pháp cài đặt các mối quan tâm an ninh.
Mouheb, Djedjiga and Talhi, Chamseddine and Lima, Vitor and Debbabi, Mourad
and Wang, Lingyu and Pourzandi, Makan [4] đã nghiên cứu một cách tổng thể để
đưa các mối quan tâm an ninh vào biểu đồ UML phân tích, từ đó đưa chúng vào các bản thiết kế. Các tác giả đã định nghĩa rất rõ ràng, chặt chẽ điểm giao, điểm cắt để thực hiện việc xen mối quan tâm an ninh vào thiết kế. Cách tiếp cận của các tác giả có hạn chế là các vấn đề an ninh được đề cập chung, tổng quát, và thiên về chứng minh tính chặt chẽ của mô hình lý thuyết.
Một số nghiên cứu khác tập trung phân tích những mối nguy cơ an ninh chung [1],
hoặc đưa ra một số chứng minh toán học chặt chẽ [5] để đưa các mối quan tâm an ninh vào biểu đồ UML. Các nghiên cứu này chủ yếu tập trung vào các vấn đề lý thuyết, và bài toán đặt ra của các tác giả cũng không giải quyết cụ thể vấn đề bảo toàn thông tin giữa các thành phần khác nhau trong cùng hệ thống.
Đánh giá so sánh Sau khi nghiên cứu một số công trình đề xuất của một số tác giả khác,
chúng tôi nhận thấy phần nhiều trong số đó nghiên cứu những vấn đề tổng quát, chứng minh lý thuyết, việc áp dụng trong thực tiễn đòi hỏi người áp dụng phải có nhiều kiến thức toán
Phương pháp hướng đối tượng và phân tích thiết kế anh ninh hệ thống 67
học, và do đó, trong các dự án cỡ vừa, việc triển khai các giải pháp đó sẽ không thuận lợi. Giải pháp đề xuất trong luận văn mang tính thực tiễn, thuận lợi triển khai trên thực tế, do không đòi hỏi nhiều nhân lực có kiến thức chuyên sâu về UML.
5.3. Những hạn chế của luận văn
Do thời gian nghiên cứu không dài, kinh nghiệm và khả năng của tác giả còn nhiều hạn chế, nên luận văn còn chưa hoàn thiện ở các điểm sau:
1. Chỉ giải quyết một vấn đề an ninh Như đã đề cập ở phần 2.2.1, một hệ thống
được xây dựng còn rất nhiều mối quan tâm an ninh khác, nhưng phạm vi luận văn chỉ đưa ra nghiên cứu và giải quyết vấn đề đảm bảo an toàn khi truy xuất dữ liệu giữa các thành phần khác nhau trong hệ thống.
2. Chưa sử dụng OCL để biểu diễn các chính sách an ninh Khi đưa ra bảng mô
tả chính sách an ninh (Bảng 4.3), chúng tôi chưa có đủ thời gian và khả năng để diễn đạt thành ngôn ngữ chính quy OCL. Điều này do thực tế số thiết kế viên, lập trình viên hiểu và vận dụng được OCL rất ít. Tuy nhiên, nếu biểu diễn đuợc dưới dạng OCL thì có thể xây dựng được các công cụ kiểm chứng mô hình và đề tài sẽ trở nên hoàn thiện hơn.
3. Chưa xây dựng được công cụ kiểm chứng mô hình Khi đưa ra mô hình UML
cùng với các dấu đặc trưng mới (bảng 4.1), chúng tôi chưa có đủ khả năng cũng như thời gian để xây dựng một công cụ kiểm chứng mô hình hoàn thiện, giúp việc kiểm chứng tính đúng đắn của mô hình đề xuất, và đảm bảo tính nhất quán giữa mô hình phân tích với mô hình thiết kế ở các bước tiếp theo.
4. Chưa có những chứng minh về lý thuyết Đề tài còn thiếu các phân tích về lý
thuyết (chứng minh về mặt toán học độ hoàn thiện của giải pháp), còn mang nặng tính thực hành, nghiêng về xây dựng các bước biểu diễn. Điều này xuất phát từ thực tế, là tác giả chưa có nhiều kinh nghiệm nghiên cứu lý thuyết mà chỉ có những kinh nghiệm xuất phát từ thực tế công tác. (adsbygoogle = window.adsbygoogle || []).push({});
5. Chưa cài đặt đầy đủ các tình huống Các tình huống đưa ra trong đề tài để cài
5.4. Các hướng nghiên cứu tiếp theo
Trên cơ sở các nghiên cứu hiện tại, các ý tưởng cơ sở này, chúng tôi thấy rằng có thể tiếp tục phát triển theo các hướng như sau:
1. Hoàn hiện quy trình Xây dựng các ý tưởng thành một quy trình hoàn thiện, giải
quyết vấn đề đặc tả các mối quan tâm an ninh thích hợp cho các hệ thống cỡ vừa và nhỏ.
2. Chứng minh lý thuyết Các ý tưởng của đề tài cần được chứng minh về lý thuyết
đảm bảo tính hoàn thiện và tính chặt chẽ khi áp dụng.
3. Xây dựng công cụ kiểm chứngXây dựng công cụ kiểm chứng mô hình để đảm bảo
tính thống nhất giữa mô hình phân tích và mô hình thiết kế.
4. Xây dựng công cụ sinh ca kiểm thử tự động Xây dựng công cụ sinh các ca kiểm
Chỉ mục
đặc trưng, stereotype, 14
biểu đồ hoạt động, activity diagram, 14 biểu đồ lớp, class diagram, 18
biểu đồ trường hợp sử dụng, use case dia- gram, 16
biểu đồ, diagram, 14
hồ sơ UML, UML profile, 14 hướng chức năng, 11
kiểm tra quyền theo vai trò, rbac, 23
Lập trình hướng khía cạnh, AOP, 54, 57
Mô hình đối phương, adversary model, 23
phân tích trên xuống, 11
phương pháp hướng đối tượng, 12
tác nhân, actor, 14
Tiếng Anh
[1] David Chizmadia. Security Risks in Systems of Distributed Objects, Components, and Services. Sixth workshop on distributed objects and components security, 2002.
[2] The Object Management Group. Unified Modeling Language Superstructure. Object Management Group, 2009.
[3] Jan J¨urjens. UMLsec Presenting the Profile. Sixth workshop on distributed objects and components security, 2002.
[4] Djedjiga Mouheb, Chamseddine Talhi, Vitor Lima, Mourad Debbabi, Lingyu Wang, and Makan Pourzandi. Weaving security aspects into UML 2.0 design models. AOM ’09. Proceedings of the 13th workshop on Aspect-oriented modeling, New York, NY, USA, 2009.
[5] Jaime Pavlich-mariscal, Laurent Michel, and Steven Demurjian. Enhancing UML to Model Custom Security Aspects [Position Paper]. Sixth workshop on distributed objects and components security, 2002.
[6] Karine P. Peralta, Alex M. Orozco, Avelino F. Zorzo, and Flavio M. Oliveira. Specifying Security Aspects in UML Models. Knowledge and Systems Engineering, International Conference on, 1999.
[7] Ninh-Thuan Truong and Jeanine Souquières. Verification of behavioural elements of UML models using B. Proceedings of the 2005 ACM Symposium on Applied Computing (SAC), Santa Fe, New Mexico, USA, March 13-17, 2005, 2005. (adsbygoogle = window.adsbygoogle || []).push({});
Tiếng Việt
[8] Thạc Bình Cường. Giáo trình phân tích và thiết kế hệ thống thông tin. Đại học Bách khoa Hà Nội, 1999.
[9] Đào Kiến Quốc. Phân tích và thiết kế hệ thống tin học hoá. Đại học quốc Gia Hà nội, 1999.
[10] Trung tâm an ninh mạng BKIS. Báo cáo đánh giá mức độ an ninh các website Việt nam. Báo cáo đánh giá mức độ an ninh các website Việt nam, 2010.
[11] Ngô Trung Việt. Phân tích và thiết kế hệ thống quản lý kinh doanh nghiệp vụ. Nhà xuất bản Thống kê, 1999.