Security design patterns in software engineering

BAN CƠ YẾU CHÍNH PHỦ
HỌC VIỆN KỸ THUẬT MẬT MÃ
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Chủ đề: Security Design Patterns in
Software Engineering

Môn học
Giảng viên
Học viên thực hiện

: An toàn phần mềm
:
:

Hà Nội, 2021



MỤC LỤC
DANH MỤC TỪ VIẾT TẮT...........................................................................ii
DANH MỤC HÌNH VẼ.................................................................................iii
CHƯƠNG 1: TỔNG QUAN VỀ MẪU THIẾT KẾ PHẦN MỀM..................1
1.1.

Khái niệm, lịch sử hình thành các mẫu thiết kế phần mềm..............1

1.1.1. Khái niệm mẫu thiết kế phần mềm..............................................1
1.1.2. Lịch sử hình thành các mẫu thiết kế phần mềm.............................1
1.2.

Phân loại các mẫu thiết kế phần mềm...............................................3

1.3.

Vai trị, lợi ích của các mẫu thiết kế phần mềm................................7

1.3.1. Vai trò của các mẫu thiết kế phần mềm.......................................7
1.3.2. Lợi ích của các mẫu thiết kế phần mềm......................................7
CHƯƠNG II: CÁC MẪU THIẾT KẾ PHẦN MỀM AN TOÀN....................9
2.1.

Quản lý định danh.............................................................................9

2.2.

Quản lý truy cập..............................................................................12

2.2.1. Xác thực.....................................................................................12
2.2.2. Phân quyền.................................................................................13
2.2.3. Giới hạn truy cập.......................................................................14
2.2.4. Điều khiển truy cập dựa trên vai trị cơ sở.................................16
2.2.5. Phiên an tồn..............................................................................17
2.3.

Ghi log an tồn................................................................................19

2.4.

An tồn Client-Server.....................................................................20

2.4.1. Khu vực phi qn sự....................................................................20
2.4.2. Mã hóa thơng tin........................................................................23
2.4.3. Proxy trung gian.........................................................................24
2.4.4. Đường truyền an toàn................................................................26
TÀI LIỆU THAM KHẢO..............................................................................27


DANH MỤC TỪ VIẾT TẮT
ST
T
1
2
3
4
5
6

Từ viết tắt
PloP
GoF
SSL
API
PKI
DMZ

Cụm từ đầy đủ
Pattern Language of Programming Design
Gang of Four
Secure Sockets Layer
Application Programming Interface

Public Key Infrastructure
Demilitarized Zone


DANH MỤC HÌNH VẼ
Hình 2.1. Mẫu xác thực............................................................................................13
Hình 2.2. Mẫu giới hạn truy cập..............................................................................15
Hình 2.3. Mẫu điều khiển truy cập dựa trên vai trị cơ sở........................................16
Hình 2.4. Sơ đồ phác thảo việc sử dụng PHIÊN AN TOÀN kết hợp với PHÂN
QUYỀN............................................................................................................18
Hình 2.5. Khu vực DMZ..........................................................................................22
Hình 2.6. Mẫu mã hóa thơng tin..............................................................................23
Hình 2.7. Sơ đồ triển khai Integration Reverse Proxy...............................................2
Y


CHƯƠNG 1: TỔNG QUAN VỀ MẪU THIẾT KẾ PHẦN MỀM
1.1.
Khái niệm, lịch sử hình thành các mẫu thiết kế phần mềm
1.1.1. Khái niệm mẫu thiết kế phần mềm
Design Patterns[1] là các mẫu thiết kế được các lập trình viên sử dụng rộng
rãi. Mỗi mẫu "Design Patterns" là một giải pháp giải quyết tốt cho các lập trình
viên khi ở trường hợp nhất định. Để có thể làm giảm rủi ro, thời gian và cơng sức
thì design pattern sẽ là ý tưởng tốt khi sử dụng.
Một mẫu thiết kế là một cặp (vấn đề, lời giải) có thể áp dụng trong nhiều tình
huống ngữ cảnh khác nhau. Mỗi mẫu thường bao gồm các bộ phận: tên, nội dung,
vấn đề, lời giải (phải đủ tổng quát để có thể dùng trong nhiều tình huống), các hệ
quả mang lại và ví dụ áp dụng.
Design patterns là tập các giải pháp cho vấn đề phổ biến trong thiết kế các hệ
thống máy tính. Đây là tập các giải pháp đã được công nhận là tài liệu có giá trị,

những người phát triển có thể áp dụng giải pháp này để giải quyết các vấn đề tương
tự.
Giống như với các yêu cầu của thiết kế và phân tích hướng đối tượng (nhằm
đạt được khả năng sử dụng các thành phần và thư viện lớp), việc sử dụng các mẫu
cũng cần phải đạt được khả năng tái sử dụng các giải pháp chuẩn đối với vấn đề
thường xuyên xảy ra. Christopher Alexander nói rằng : “Mỗi một mẫu mô tả một
vấn đề xảy ra lặp đi lặp lại trong môi trường và mô tả cái cốt lõi của giải pháp để
cho vấn đề đó. Bằng cách nào đó bạn đã dùng nó cả triệu lần mà khơng làm giống
nhau hai lần”.
1.1.2. Lịch sử hình thành các mẫu thiết kế phần mềm
Ý tưởng dùng mẫu xuất phát từ ngành kiến trúc[2], Alexander, Ishikawa,
Silverstein, Jacobson, Fiksdahl-King và Angel (1977) lần đầu tiên đưa ra ý tưởng
dùng các mẫu chuẩn trong thiết kế xây dựng và truyền thông. Họ đã xác định và lập
dữ liệu các mẫu có liên quan để có thể dùng để giải quyết các vấn đề thường xảy ra
trong thiết kế các cao ốc. Mỗi mẫu này là một cách thiết kế, chúng đã được phát
triển hàng trăm năm như là các giải pháp cho các vấn đề mà người ta làm trong lĩnh
vực xây dựng thường gặp. Các giải pháp tốt nhất có được ngày hơm nay là qua một
q trình sàng lọc tự nhiên. Mặc dù ngành cơng nghệ phần mềm khơng có lịch sử
phát triển lâu dài như ngành kiến trúc, xây dựng nhưng công nghệ phần mềm là
1


một ngành công nghiệp tiên tiến, tiếp thu tất cả những gì tốt đẹp nhất từ các ngành
khác. Mẫu được xem là giải pháp tốt để giải quyết vấn đề xây dựng hệ thống phần
mềm. Mẫu được xem là đạt chuẩn về an tồn để có thể áp dụng vào các hệ thống
một cách đúng đắn.
Suốt những năm đầu 1990, thiết kế mẫu được thảo luận ở các hội thảo
workshop, sau đó người ta nỗ lực để đưa ra danh sách các mẫu và lập dữ liệu về
chúng. Những người tham gia bị dồn vào việc cần thiết phải cung cấp một số kiểu
cấu trúc ở một mức quan niệm cao hơn đối tượng và lớp để cấu trúc này có thể

được dùng để tổ chức các lớp. Đây là kết quả của sự nhận thức được rằng việc
dùng các kỹ thuật hướng đối tượng độc lập sẽ không mang lại những cải tiến đáng
kể đối với chất lượng cũng như hiệu quả của công việc phát triển phần mềm. Mẫu
được xem là cách tổ chức việc phát triển hướng đối tượng, cách đóng gói các kinh
nghiệm của những ngưịi đi trước và rất hiệu quả trong thực hành.
Năm 1994 tại hội nghị PloP (Pattern Language of Programming Design) đã
được tổ chức. Cũng trong năm này quyển sách Design patterns: Elements of
Reusable Object Oriented Software (Gamma, Johnson, Helm và Vhissdes, 1995) đã
được xuất bản đúng vào thời điểm diễn ra hội nghị OOPSLA’94. Đây là một tài liệu
cịn phơi thai trong việc làm nỗi bật ảnh hưởng của mẫu đối với việc phát triển
phần mềm.
Design pattern là thuật ngữ được đưa ra năm 1995 bởi Gang of Four (GoF)
và đã tạo nên một cuộc cách mạng trong phát triển phần mềm. Hiểu một cách phi
hình thức, một design pattern là một cặp vấn đề/giải pháp cho những bài toán thiết
kế được lặp đi lặp lại trong một ngữ cảnh nhất định. Một design pattern có bốn đặc
trưng cơ bản là: problem, context,solution và consequences làm nền tảng để cấu
trúc hóa các tài liệu đặc tả chúng. Sức mạnh của design pattern nằm ở chỗ nó là sự
kết tinh tri thức và kinh nghiệm của các chuyên gia trong lĩnh vực thiết kế: dùng
một design pattern, ta khơng chỉ dùng chính bản thân pattern đó mà thực chất ta đã
sử dụng chính tri thức và nhiều năm kinh nghiệm của các chuyên gia. Đồng thời,
việc phổ biến design pattern cũng tạo nên một ngôn ngữ chung về thiết kế, tạo
thuận lợi cho việc trao đổi giữa các chuyên gia trong lĩnh vực này. Sau khi ra đời,
design pattern đã tạo cảm hứng có các tác giả khác và kết quả là các khái niệm liên
quan đã ra đời như analysis patterns, specification patterns và security patterns.
2


Năm 2000, Evitts có tổng kết về cách các mẫu xâm nhập vào thế giới phần
mềm (sách của ông lúc bấy giờ chỉ nói về những mẫu có thể được sử dụng trong
UML chứ chưa đưa ra khái niệm những mẫu thiết kế một cách tổng qt). Ơng

cơng nhận Kent Beck và Ward Cunningham là những người phát triển những mẫu
đầu tiên với SmallTalk trong công việc của họ được báo cáo tại hội nghị
OOPSLA’87. Có năm mẫu mà Kent Beck và Ward Cunningham đã tìm ra trong
việc kết hợp các người dùng của một hệ thống mà họ đang thiết kế. Năm mẫu này
đều được áp dụng để thiết kế giao diện người dùng trong môi trường Windows.
1.2. Phân loại các mẫu thiết kế phần mềm
Hiện nay, Design pattern được chia thành 3 loại chính[3]:
 Mẫu thiết kế khởi tạo (Creational Pattern): Factory Method, Abstract
Factory, Builder, Prototype, Singleton. Những Design pattern loại này cung cấp
một giải pháp để tạo ra các object và che giấu được logic của việc tạo ra nó, thay vì
tạo ra object một cách trực tiếp bằng cách sử dụng method new. Điều này giúp cho
chương trình trở nên mềm dẻo hơn trong việc quyết định object nào cần được tạo ra
trong những tình huống được đưa ra.
 Mẫu thiết kế cấu trúc (Structural Pattern): Adapter, Bridge, Composite,
Decorator, Facade, Flyweight và Proxy. Những Design pattern loại này liên quan
tới class và các thành phần của object. Nó dùng để thiết lập, định nghĩa quan hệ
giữa các đối tượng.
 Mẫu thiết kế hành vi ( Behavioral Pattern): Interpreter, Template Method,
Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State,
Strategy và Visitor. Nhóm này dùng trong thực hiện các hành vi của đối tượng, sự
giao tiếp giữa các object với nhau.
Bảng 1.1: Bảng thống kê các mẫu thiết kế
ST
T
1

Tên

Abstract
Factory

Mục đích
Mẫu khởi tạo (Creational Pattern)
Cung cấp một interface cho việc tạo lập các đối tượng
(có liên hệ với nhau) mà không cần qui định lớp khi hay
xác định lớp cụ thể (concrete) tạo mỗi đối tượng.
Tần suất sử dụng: cao
3


2

Builder

3

Factory
Method

4

Prototype

5

Singleton

6

Adapter

7

Bridge

8

Composite

Tách rời việc xây dựng (construction) một đối tượng
phức tạp khỏi biểu diễn của nó sao cho cùng một tiến
trình xây dựng có thể tạo được các biểu diễn khác nhau.
Tần suất sử dụng: trung bình thấp
Định nghĩa Interface để sinh ra đối tượng nhưng để cho
lớp con quyết định lớp nào được dùng để sinh ra đối
tượng Factory method cho phép một lớp chuyển quá
trình khởi tạo đối tượng cho lớp con.
Tần suất sử dụng: cao
Quy định loại của các đối tượng cần tạo bằng cách dùng
một đối tượng mẫu, tạo mới nhờ vào sao chép đối tượng
mẫu này.
Tần suất sử dụng: trung bình
Đảm bảo 1 class chỉ có 1 instance và cung cấp 1 điểm
truy xuất toàn cục đến nó.
Tần suất sử dụng: cao trung bình
Mẫu thiết kế cấu trúc (Structural Pattern)
Do vấn đề tương thích, thay đổi interface của một lớp
thành một interface khác phù hợp với yêu cầu người sử
dụng lớp.
Tần suất sử dụng: cao trung bình

Tách rời ngữ nghĩa của một vấn đề khỏi việc cài đặt,
mục đích để cả hai bộ phận (ngữ nghĩa và cài đặt) có thể
thay đổi độc lập nhau.
Tần suất sử dụng: trung bình
Tổ chức các đối tượng theo cấu trúc phân cấp dạng cây.
Tất cả các đối tượng trong cấu trúc được thao tác theo
một cách thuần nhất như nhau.
Tạo quan hệ thứ bậc bao gộp giữa các đối tượng. Client
có thể xem đối tượng bao gộp và bị bao gộp như nhau ->
khả năng tổng quát hoá trong code của client -> dễ phát
triển, nâng cấp, bảo trì.
Tần suất sử dụng: cao trung bình
4


9

10

11

12

13

14

Decorator

Gán thêm trách nhiệm cho đối tượng (mở rộng chức

năng) vào lúc chạy (dynamically).
Tần suất sử dụng: trung bình
Facade
Cung cấp một interface thuần nhất cho một tập hợp các
interface trong một “hệ thống con” (subsystem). Nó định
nghĩa một interface cao hơn các interface có sẵn để làm
cho hệ thống con dễ sử dụng hơn.
Tần suất sử dụng: cao
Flyweight
Sử dụng việc chia sẻ để thao tác hiệu quả trên một số
lượng lớn đối tượng “cỡ nhỏ” (chẳng hạn paragraph,
dòng, cột, ký tự…).
Tần suất sử dụng: thấp
Proxy
Cung cấp đối tượng đại diện cho một đối tượng khác để
hỗ trợ hoặc kiểm soát q trình truy xuất đối tượng đó.
Đối tượng thay thế gọi là proxy.
Tần suất sử dụng: cao trung bình
Mẫu thiết kế hành vi (Behavioral Pattern)
Chain of
Khắc phục việc ghép cặp giữa bộ gửi và bộ nhận thông
Responsibilit điệp. Các đối tượng nhận thông điệp được kết nối thành
y
một chuỗi và thông điệp được chuyển dọc theo chuỗi
này đến khi gặp được đối tượng xử lý nó.Tránh việc gắn
kết cứng giữa phần tử gửi request với phần tử nhận và
xử lý request bằng cách cho phép hơn một đối tượng có
cơ hội xử lý request . Liên kết các đối tượng nhận
request thành 1 dây chuyền rồi “pass” request xuyên qua
từng đối tượng xử lý đến khi gặp đối tượng xử lý cụ thể.

Tần suất sử dụng: trung bình thấp
Command
Mỗi yêu cầu (thực hiện một thao tác nào đó) được bao
bọc thành một đối tượng. Các yêu cầu sẽ được lưu trữ và
gửi đi như các đối tượng. Đóng gói request vào trong
một Object , nhờ đó có thể thơng số hố chương trình
nhận request và thực hiện các thao tác trên request: sắp
xếp, log, undo…
5


15

Interpreter

16

Iterator

17

Mediator

18

Memento

19

Observer

20

State

21

Strategy

22

Visitor

23

Template

Tần suất sử dụng: cao trung bình
Hỗ trợ việc định nghĩa biểu diễn văn phạm và bộ thông
dịch cho một ngôn ngữ.
Tần suất sử dụng: thấp
Truy xuất các phần tử của đối tượng dạng tập hợp tuần
tự (list, array, …) mà không phụ thuộc vào biểu diễn bên
trong của các phần tử.
Tần suất sử dụng: cao
Định nghĩa một đối tượng để bao bọc việc giao tiếp giữa
một số đối tượng với nhau.
Tần suất sử dụng: trung bình thấp
Hiệu chỉnh và trả lại như cũ trạng thái bên trong của đối
tượng mà vẫn không vi phạm việc bao bọc dữ liệu.

Tần suất sử dụng: thấp
Định nghĩa sự phụ thuộc một - nhiều giữa các đối tượng
sao cho khi một đối tượng thay đổi trạng thái thì tất cả
các đối tượng phụ thuộc nó cũng thay đổi theo.
Tần suất sử dụng: cao
Cho phép một đối tượng thay đổi hành vi khi trạng thái
bên trong của nó thay đổi , ta có cảm giác như class của
đối tượng bị thay đổi.
Tần suất sử dụng: trung bình
Bao bọc một họ các thuật tốn bằng các lớp đối tượng để
thuật tốn có thể thay đổi độc lập đối với chương trình
sử dụng thuật tốn.Cung cấp một họ giải thuật cho phép
client chọn lựa linh động một giải thuật cụ thể khi sử
dụng.
Tần suất sử dụng: cao trung bình
Cho phép định nghĩa thêm phép tốn mới tác động lên
các phần tử của một cấu trúc đối tượng mà không cần
thay đổi các lớp định nghĩa cấu trúc đó.
Tần suất sử dụng: thấp
Định nghĩa phần khung của một thuật toán, tức là một
6


method

thuật toán tổng quát gọi đến một số phương thức chưa
được cài đặt trong lớp cơ sở; việc cài đặt các phương
thức được ủy nhiệm cho các lớp kế thừa.
Tần suất sử dụng: trung bình
1.3. Vai trị, lợi ích của các mẫu thiết kế phần mềm

1.3.1. Vai trò của các mẫu thiết kế phần mềm
Design pattern[2] là cách duy nhất để chuyển hóa một cách chính xác các
u cầu của khách hàng thành mơ hình thiết kế hệ thống phần mềm cuối cùng, làm
cơ sở cho việc triển khai chương trình phần mềm.
Mẫu thiết kế là cơng cụ giao tiếp giữa các nhóm cùng tham gia phát triển sản
phẩm, quản lý rủi ro, đạt được phần mềm hiệu quả.
Không những vậy, Design pattern còn là tài liệu cung cấp đầy đủ các thơng
tin cần thiết để bảo trì hệ thống. Nếu khơng có thiết kế thì hệ thống khơng tin cậy,
vì vậy có nguy cơ thất bại rất cao. Một thiết kế tốt là chìa khóa làm cho phần mềm
hữu hiệu.
1.3.2. Lợi ích của các mẫu thiết kế phần mềm
Design pattern giúp tăng tốc độ phát triển phần mềm bằng cách đưa ra các
mơ hình test, mơ hình phát triển đã qua kiểm nghiệm. Thiết kế phần mềm hiệu quả
đòi hỏi phải cân nhắc các vấn đề sẽ nảy sinh trong q trình hiện thực hóa. Dùng lại
các design pattern giúp tránh được các vấn đề tiềm ẩn có thể gây ra những lỗi lớn,
đồng thời giúp code dễ đọc hơn.
Thông thường, chúng ta chỉ biết áp dụng một kĩ thuật thiết kế nhất định để
giải quyết một bài toán nhất định. Các kĩ thuật này rất khó áp dụng với các vấn đề
trong phạm vi rộng hơn. Design pattern cung cấp giải pháp ở dạng tổng quát.
Hệ thống các mẫu design pattern hiện có 23 mẫu được định nghĩa trong
cuốn “Design patterns Elements of Reusable Object Oriented Software”. Hệ thống
các mẫu này có thể đủ và tối ưu cho việc giải quyết hết các vấn đề của bài toán
phân tích thiết kế và xây dựng phần mềm trong thời điểm hiện tại.

7


CHƯƠNG II: CÁC MẪU THIẾT KẾ PHẦN MỀM AN TOÀN
2.1. Quản lý định danh
Mục đích: cung cấp một số gợi ý về cách quản lý, thiết kế, tạo và sử dụng

mật khẩu. Nó dành cho ba nhóm người dùng khác nhau: quản trị viên, kỹ sư và
người dùng. Nó cung cấp cho các kỹ sư cách để thực hiện và bảo vệ các thiết kế và
sử dụng mật khẩu trong các dự án thương mại. Đối với quản trị viên, nó cung cấp
cách đặt giới hạn và nguyên tắc cho việc thiết kế và sử dụng mật khẩu trong môi
trường làm việc khác nhau, ví dụ như quản lý và vận hành các cơ chế mật khẩu.
8


Cuối cùng đối với người dùng cuối, nó cung cấp một số cách để người dùng có thể
xử lý mật khẩu và cải thiện bảo mật cho mật khẩu.
Vấn đề: Mật khẩu dùng để xác thực người dùng vào hệ thống. Mặc dù mật
khẩu dễ đốn thì kẻ giả mạo có thể truy cập vào hệ thống nhưng nếu mật khẩu
mạnh và khó nhớ thì người dùng có thể khó ghi nhớ được mật khẩu đó.
u cầu:
• Mặc dù mật khẩu phải khó đốn, nhưng cũng đủ để dễ nhớ. Trong một số
trường hợp, một chương trình quản lý mật khẩu có thể giúp ích cho việc ghi nhớ
những mật khẩu rất khó nhớ. Vì nếu một mật khẩu khơng nhớ được dễ dàng, thì
nguy cơ người dùng viết mật khẩu ra sẽ tăng lên. Đặc biệt nếu khơng có trình quản
lý mật khẩu nào được sử dụng thì mối đe dọa bảo mật sẽ tăng lên.
• Mật khẩu phải khó đốn đối với những kẻ giả mạo.
• Nên thường xuyên thay đổi mật khẩu và đủ độ phức tạp.
• Mỗi hệ thống riêng biệt phải có mật khẩu riêng của chúng, do đó, một mật
khẩu được sử dụng chỉ một lần.
• Giải pháp phải đạt được sự cân bằng giữa các rằng buộc khác nhau.
Giải pháp: Tại phần này một danh sách các câu hỏi mà quản trị việ hệ thống,
kỹ sư hoặc người dùng có thể tự trả lời. Các kỹ sư và quản trị viên hệ thống có thể
thực thi thiết kế và định nghĩa thích hợp, sử dụng và bảo vệ mật khẩu.
Thiết kế và xác định:
Những ký tự nào có thể được sử dụng và phải được sử dụng (ví dụ: tối thiểu
một ký tự, một ký hiệu và một số)?

• Độ dài tối thiểu và tối đa của mật khẩu?
• Ai có thể tạo mật khẩu (thực thể) nào?
Việc sử dụng mật khẩu:
• Độ dài tối đa của mật khẩu là bao nhiêu?
• Ai là những người được phép sử dụng mật khẩu?
• Làm thế nào để nhập mật khẩu vào hệ thống?
• Khoảng cách thời gian tối đa là bao lâu trước khi hệ thống yêu cầu xác thực
lại?
Sự bảo vệ:
9


• Những cách được chấp thuận để đưa mật khẩu mới tới người dùng và
những nơi được yêu cầu? Ví dụ, u cầu mã hóa và các kênh an tồn hoặc gửi một
mật khẩu mới với thư tiêu chuẩn.
• Các cơ chế chấp nhận được cách lưu trữ mật khẩu là gì? Ví dụ. mật khẩu
được lưu trữ trên một chuỗi băm, khơng bao giờ là mật khẩu của chính nó. Trên hệ
thống nào, cơ sở dữ liệu và bảng là mật khẩu được lưu trữ và cơ sở dữ liệu được
bảo vệ như thế nào?
• Cơ chế nào được chấp nhận để giao tiếp mật khẩu từ khi nhập đến khi được
bảo vệ.
Ví dụ: Thiết kế và Sử dụng Mật khẩu cho người dùng tại Dịch vụ Web. Điều
này không không bao gồm mật khẩu quản trị hoặc bảo trì được u cầu trong hệ
thống.
Thiết kế mật khẩu:
• Tối thiểu 8 chữ cái
• Tối đa 30 chữ cái
• Tối thiểu 1 chữ cái nhỏ, 1 chữ cái in hoa và 1 số
• Khi đăng mỗi người dùng tạo mật khẩu của riêng mình.
• Khi u cầu đặt lại mật khẩu, một chuỗi ngẫu nhiên phù hợp với các quy

tắc thiết kế được do hệ thống tạo ra và gửi đến người dùng. Khơng có giao diện, ví
dụ: dành cho quản trị viên, yêu cầu nhập mật khẩu thủ công cho người dùng khác.
Sử dụng mật khẩu:
• Mật khẩu có thời gian khơng thời hạn.
• Chỉ người sử dụng tài khoản mới được phép sử dụng mật khẩu. Ngoài ra
người dùng có trách nhiệm giữ và khơng cho người khác biết mật khẩu của mình.
• Có thể nhập mật khẩu vào màn hình đăng nhập bằng trình duyệt. Ngồi ra
ứng dụng điện thoại thơng minh có thể sử dụng API đăng nhập để nhập mật khẩu.
• Phiên bảo mật, được thiết lập việc xác thực tên người dùng-mật khẩu chính
xác có thời gian tồn tại tối đa là 20 phút. Sau khoảng thời gian này, xác thực lại là
bắt buộc.
Sự bảo vệ:

10


• Mật khẩu phải được chuyển qua KÊNH AN TOÀN. Trong trường hợp này,
Màn hình đăng nhập sử dụng mã hóa SSL qua HTTPS. API trên điện thoại thơng
minh phải sử dụng SSL.
• Mật khẩu phải được thêm salt và băm bằng SHA256. Mật khẩu chính thì
khơng được lưu trữ, chỉ mật khẩu-băm được lưu trữ. Mật khẩu được lưu trữ riêng
biệt trong cơ sở dữ liệu nơi một trường userID bổ sung trỏ đến mục nhập thông tin
của người dùng.
• Khi người dùng mới đăng ký, họ nhập mật khẩu của mình qua một kênh an
tồn. Khi mật khẩu được đặt lại, mật khẩu dùng một lần sẽ được gửi qua e-mail tới
người dùng. Với mật khẩu dùng một lần này, người dùng có thể nhập mật khẩu
mới.
Ưu điểm:
Khi áp dụng giải pháp này, cần xem xét các lợi ích sau:
• Tăng cường bảo vệ mật khẩu

• Độ chính xác cao hơn của nhận dạng và xác thực
• Tỷ lệ đốn mật khẩu giảm
Nhược điểm:
• Nó có thể dẫn đến việc quên sử dụng các kỹ thuật khác để nhận dạng và xác
thực. Sự kết hợp của các phương pháp khác nhau thường được coi là phương pháp
tốt nhất.
Một số chức năng khác của quản lý Định danh:
Có những khả năng nhận dạng và xác thực khác ngoài mật khẩu. Một trong
số đó rất phổ biến là sử dụng cơ sở hạ tầng khóa cơng khai (PKI), tại một hệ thống
mà mật khẩu được chia sẻ và được sử dụng để xác nhận vào hệ thống, quy trình
hoặc người dùng đối với một chủ thể. Những cái khác khả năng không được đề cập
thêm ở đây nhưng cũng nên xem xét.
2.2.

Quản lý truy cập

2.2.1. Xác thực
Mục đích: Mẫu thiết kế này là mẫu dùng để kiểm tra xem đối tượng đang
truy cập hệ thống là ai, có phải đối tượng thuộc hệ thống hay ko? Xác thực đối
tượng trước khi quyết định truy cập đối tượng
11


Hoàn cảnh sử dụng: Người dùng thường được xác thực bởi hệ thống khi
đăng nhập lần đầu tiên nhưng có thể yêu cầu xác thực bổ sung khi truy cập các tài
nguyên nhạy cảm. Đặc biệt là trong các hệ thống phân tán, có thể u cầu các quy
trình xác thực bổ sung để xác minh quyền truy cập vào các đối tượng được phân
phối trong nhiều cách truy cập
Vấn đề an tồn: Kẻ mạo danh có thể có được quyền truy cập vào các tài
nguyên của một người dùng hợp pháp, càng nguy hiểm hơn khi người dùng càng có

nhiều đặc quyền trong hệ thống. Đặc biệt đối với các dịch vụ phân tán, làm thế nào
có thể ngăn chặn kẻ mạo danh truy cập các tài nguyên này.
Nguyên tắc:
 Những người dùng khác nhau có thể có các quyền truy cập khác nhau. Trước
khi cấp quyền truy cập, hãy xác định người dùng được yêu cầu.
 Những người dùng khác nhau có thể sử dụng các cách xác thực khác nhau, do
đó cần phải có một cách tiếp cận chung, độc lập với các cách tiếp cận khác nhau.
 Quy trình xác thực phải đáng tin cậy vì các hệ thống khác tin tưởng trình xác
thực và dựa trên các quyết định truy cập của họ.
Giải pháp: Sử dụng điểm truy cập duy nhất, các tương tác của người dùng có
thể được giám sát và một giao thức có thể được áp dụng để xác minh danh tính của
người dùng.
Ưu điểm:
 Có thể xác thực phân tán.
 Có thể sử dụng nhiều thuật toán để đảm bảo xác thực. Tuy nhiên cần cân đối
chi phí triển khai.
 Mẫu XÁC THỰC có thể cấp nhiều quyền truy cập đồng thời cho các đối
tượng từ xa.
Nhược điểm:
 Mức độ bảo mật ngày càng tăng dẫn tới độ phức tạp và tốn kém khi triển


khai.
Trong các môi trường phân tán hiện có, XÁC THỰC có thể chồng chéo các

tính năng xác thực đã được cung cấp.

12

Hình 2.1. Mẫu xác thực
2.2.2. Phân quyền
Mục đích: Một hệ thống thơng tin có các tài ngun khác nhau mà người
dùng hoặc q trình (chủ thể) có thể truy cập được. Làm thế nào chúng ta có thể mơ
tả chủ thể nào được phép truy cập tài nguyên nào?
Hoàn cảnh sử dụng: Mọi hệ thống thông tin mà chúng ta muốn / cần kiểm
soát quyền truy cập vào tài nguyên.
Vấn đề an tồn: Khơng phải mọi tài ngun trong hệ thống thơng tin đều có
thể truy cập được đối với mọi đối tượng. Một chủ thể có thể là một người dùng
hoặc một quá trình. Một điều cần thiết là xác định trước cách các tài nguyên có thể
được truy cập. Nếu khơng, một chủ thể có thể dễ dàng phá vỡ các biện pháp ủy
quyền.
Điều kiện:
- Cơ chế kiểm soát truy cập cần phải độc lập với loại nguồn tái tạo.
- Việc quản lý các ủy quyền phải hiệu quả và phù hợp với người quản trị.
Giải pháp: Hiển thị cho mỗi thực thể (Chủ thể) có thể truy cập tài nguyên,
nếu và cách nó có thể truy cập tài nguyên. Điều này được thực hiện bởi một đối
tượng quyền bổ sung xác định quyền truy cập cho mỗi tài nguyên được bảo vệ.
Ưu điểm: Giải pháp này ko phụ thuộc loại tài nguyên.
- Đối tượng có thể thuộc nhiều loại khác nhau như người dùng đơn lẻ, vai trị
hoặc quy trình.
13


- Các quy tắc ủy quyền có thể được thêm vào, sửa đổi hoặc loại bỏ. Điều này
cho phép quản lý linh hoạt các quy tắc ủy quyền.
- Các chủ đề và đối tượng ngụ ý có thể được sử dụng để cải thiện tính linh
hoạt (tốn thêm thời gian xử lý).
Nhược điểm:
- Nếu có nhiều đối tượng, số lượng các quy luật có thể trở nên rất lớn và khó

duy trì
- Quản trị viên có thể khó nhận ra chủ đích của các luật mới
- Cần có một hệ thống hoặc phương pháp khác để thực thi các quy tắc ủy
quyền.
2.2.3. Giới hạn truy cập
Mục đích: Mẫu GIỚI HẠN TRUY CẬP trình bày một giải pháp thay thế cho
FULL ACCESS WITH ERRORS. Trong trường hợp quyền truy cập đầy đủ có lỗi
hiển thị tất cả các tùy chọn có thể có và chỉ kiểm tra quyền truy cập trước khi thực
hiện một tác vụ, mẫu giới hạn truy cập đã kiểm tra việc cấp quyền trước khi trả lại
User Interface. Nó sửa đổi chế độ xem, chỉ các tùy chọn được gán mà người dùng
có quyền truy cập thích hợp.
Hoàn cảnh sử dụng: Thiết kế giao diện của một hệ thống có giới hạn truy
cập vào các phần của giao diện. Thông thường, điều này áp dụng cho GUI nhưng
cũng có thể được sử dụng trong các giao diện hệ thống khác.
Vấn đề: Người dùng xem được họ được phép làm những gì khi họ truy cập
vào hệ thống và cách đối phó với họ khi họ muốn truy cập vào các tài ngun
khơng được phép.
u cầu:
• Các thao tác mà người dùng không thể thực hiện sẽ không được hiển thị
trong GUI.
• Dữ liệu mà người dùng khơng thể truy cập sẽ khơng được hiển thị.
• Tránh cho người dùng biết thơng báo (lỗi-) những gì họ được phép hoặc
khơng vì người dùng khơng muốn được u cầu phải làm gì.
• Việc hồn tồn khơng cung cấp quyền truy cập vào một số thao tác làm cho
việc xác thực đầu vào dễ dàng hơn vì giảm số lượng hoạt động phải được xác nhận.
14


• Các tùy chọn xuất hiện và biến mất, do các đặc quyền đã thay đổi, có thể
gây khó chịu cho người dùng

Hình 2.2. Mẫu giới hạn truy cập
Giải pháp:
Sử dụng các chế độ xem khác nhau được tối ưu hóa cho các tài nguyên sẵn
có của các mức độ tin cậy nhất định (hoặc các vai trò theo điều khiển truy cập dựa
trên vai trị).
Ngồi ra, quyền truy cập của người dùng có thể được lưu vào bộ nhớ đệm
trong đối tượng SECURE SESSION cho phép giảm chi phí hiệu suất cho các yêu
cầu trong tương lai.
Kết quả: Đối với thành phần mẫu này là kết quả của các mẫu đã sử dụng.
Có lẽ kết quả phù hợp nhất là nó cho phép một giao diện người dùng rất đơn
giản, nơi chỉ có sẵn các tài nguyên có thể truy cập được.
Người dùng sẽ không nhận được thông báo lỗi. Hạn chế lớn nhất là nó có thể
trở nên rất phức tạp và khó trang bị thêm mẫu này vào các ứng dụng hiện có.
Ưu điểm:
 Cung cấp giao diện đơn giản hóa cho người dùng vì họ khơng phải quan tâm
đến những gì họ được phép hay khơng.
 Bởi vì người dùng chỉ có thể truy cập các hoạt động được phép, các nhà phát
triển không cần quan tâm đến việc xác nhận từng hoạt động-quyền truy cập.
15


 Kiểm tra bảo mật có thể được đơn giản hóa vì tất cả chúng đều có thể được
thực hiện trước.
Hạn chế:
 Các trường rỗng, do không thể truy cập và do đó các tùy chọn khơng được
hiển thị có thể trơng xấu xí và cung cấp trải nghiệm người dùng khơng tốt. Ngồi
ra, việc sắp xếp lại các tùy chọn, chẳng hạn như menupoints có thể khiến người
dùng bối rối.
 Việc trang bị thêm mẫu này vào các hệ thống hiện có có thể trở nên rất khó

khăn.


Chỉ dựa vào kiểm tra cho phép từ trước, có thể nguy hiểm. Do đó, ngun tắc

Phịng thủ trong Chiều sâu cũng nên được áp dụng.
2.2.4. Điều khiển truy cập dựa trên vai trò cơ sở
Giới thiệu: Mẫu điều khiển truy cập trên vai trò cơ sở liên quan tới quyền của
người dùng dựa trên vài trò của họ với hệ thống. Mẫu này liên kết người dùng với
vai trò và vai trò với quyền hạn loại bỏ việc liên kết người dùng cá nhân với bộ
quyền hạn cá nhân. Mẫu này thích hợp khi có một số lượng lớn người dùng hoặc
một lượng lớn tài nguyên chia sẻ liên quan tới đặc quyền truy cập

Hình 2.3. Mẫu điều khiển truy cập dựa trên vai trò cơ sở
Mẫu điều khiển truy cập dựa trên cơ sở vai trị gồm có bốn thành phần: người
dùng, vai trò, quyền với vai trò, đối tượng dữ liệu. Người dùng là lớp biểu diễn
người dùng của hệ thống. Vai trò biễu diễn vai trò hiện tại của người dùng được giả
định. Đối tượng dữ liệu biểu diễn dữ liệu mà người dùng mong muốn truy cập. Chú
ý rằng người dùng có nhiều mối quan hệ với quyền và quyền có nhiều mối quan hệ
với đối tượng dữ liệu.
16


Mẫu này giúp giảm khối lượng công việc cho người quản lý người dùng và
đơn giản hóa mơ hình an ninh, vì có nhiều người sử dụng hơn so với vai trò của
người dùng làm cho các ứng dụng được sử dụng dễ dàng hơn.
Khi một người dùng muốn đăng nhập vào hệ thống dữ liệu, chỉ khi người
dùng đó có quyền hạn hoặc một vai trị nhất định đã được gán quyền, thì khi đó
class permissison sẽ cho phép người dùng được đăng nhập vào hệ thống dữ liệu. Vì
vậy, mơ hình được cho là an tồn khi áp dụng vào xây dựng một hệ thống.

Ưu điểm:
• Sử dụng cách tiếp cận này, các quyền vai trò được xác định theo nhiệm vụ
của chúng.
• Ngun tắc “đặc quyền ít nhất” được hỗ trợ trực tiếp.
• Cách tiếp cận này cho phép hệ thống độc lập.
• Dễ dàng duy trì hơn là chỉ định các đặc quyền cho từng người dùng riêng
biệt.
• Các vai trị làm giảm sự phức tạp của quyền truy cập quản trị.
Hạn chế:
• Nếu người dùng có các đặc quyền cá nhân, nó sẽ yêu cầu một vai trò cho
mỗi người dùng, điều này làm cho nó trở nên phức tạp và vơ ích..
• Cần phải có một cơ chế khác để thực thi nguyên tắc "tách biệt nhiệm vụ",
nếu khơng, xung đột có thể xảy ra như vậy người yêu cầu đặc quyền cũng là người
cấp đặc quyền. Ví dụ. ai đó u cầu ngân sách cũng là người quyết định ngân sách
trong công ty, bằng cách này anh ta có thể tự cấp thêm ngân sách hoặc mức lương
cao hơn mà không cần người khác kiểm sốt.
2.2.5. Phiên an tồn
Mục đích: Thay vì xác thực lại người dùng cho từng chức năng của hệ thống,
giải pháp này được thực hiện để theo dõi thông tin hoạt động của người dùng và
cung cấp cho hệ thống mà không cần chuyển các quyền truy cập hay xác thực lại
người dùng. Nó tạo một đối tượng phiên được liên kết với người dùng hoặc quy
trình khi người dùng truy cập vào hệ thống.
Vấn đề: Nhiều thành phần, hoạt động thay mặt cho người dùng hoặc quy
trình, yêu cầu quyền truy cập vào các giá trị bảo mật được chia sẻ của người dùng
này. Làm thế nào để tránh các xác thực lặp lại và những yêu cầu về các giá trị?
17


• Cung cấp quyền truy cập vào các biến toàn cục được phân biệt cho mọi cá
nhân người dùng.

• Các giá trị được chia sẻ có thể thay đổi theo thời gian.
• Nhiều ứng dụng có thể sử dụng các giá trị khác nhau và có thể thay đổi
chúng.
• Chuyển tất cả các giá trị vào có thể làm chậm hiệu suất.
• Việc hỏi người dùng liên tục về các giá trị gây khó chịu cho người dùng và
có thể giảm đáng kể mức độ chấp nhận hệ thống.
Giải pháp: Tạo một đối tượng phiên chứa dữ liệu liên quan đến người dùng
cần được chia sẻ bởi nhiều đối tượng. Đối tượng phiên này được liên kết với mọi
hành động của người dùng, hoặc ngầm hiểu bởi liên kết nó với các hành động qua
kết nối của người dùng, chẳng hạn như bên trong hoạt động hệ thống hoặc rõ ràng
với một số nhận dạng, ví dụ: một phiên cookie. Ngồi ra, phiên đối tượng có thể
được sử dụng để cung cấp bộ nhớ giới hạn cho các chức năng hệ thống khác, có thể
lưu trữ dữ liệu nhất định, ví dụ: giỏ hàng của một cửa hàng trực tuyến.
Hình 2.4 cho thấy một sơ đồ bối cảnh phác thảo việc sử dụng PHIÊN AN
TỒN

Hình 2.4. Sơ đồ phác thảo việc sử dụng PHIÊN AN TOÀN
Hậu quả khi áp dụng giải pháp này, cần xem xét các vấn đề sau:
18


• Đối tượng phiên cung cấp một nơi duy nhất với giao diện chung để giữ tất
cả dữ liệu người dùng liên quan đến bảo mật.
• Một đối tượng duy nhất có thể được truyền xung quanh thay vì nhiều giá trị
khác nhau.
• Thay đổi giá trị phiên có thể được phổ biến đơn giản vì chỉ có một nơi duy
nhất tất cả các đối tượng khác sẽ nhìn vào.
• Các biến chia sẻ mới có thể được lưu trữ dễ dàng bằng cách chuyển chúng
vào đối tượng phiên.
Các vấn đề cần giải quyết:

• Nếu các đối tượng phiên trở nên quá lớn và nhiều người dùng đồng thời sử
dụng hệ thống, hiệu suất hệ thống có thể bị giới hạn. Do đó, điều quan trọng là
khơng lưu trữ thơng tin khơng cần thiết trong đối tượng phiên. Ngồi ra, chúng ta
có thể cân nhắc thời gian chờ của phiên được thực hiện bởi Manager. Trong hệ
thống phân tán, số nhận dạng phiên có thể bị tấn cơng và bị sử dụng bởi những kẻ
mạo danh.
• Nếu đối tượng phiên được lưu trữ ở phía máy khách, cookie cần được mã
hóa và xác thực để tránh dữ liệu bị xâm phạm. Nếu hệ thống cho phép, lưu trữ đối
tượng phiên phía máy chủ và chỉ lưu trữ một số nhận dạng phiên trong cookie, có
thể là một giải pháp.
2.3. Secure logger
Mục đích: Một số cuộc tấn cơng sử dụng nhật ký hệ thống để tiết lộ thơng tin
hữu ích về hệ thống. Mẫu này ngăn những kẻ tấn công thu thập thông tin như vậy
hoặc che giấu hành động bằng cách chỉnh sửa nhật ký.
Bối cảnh: Mọi nơi sử dụng nhật ký hệ thống hoặc một hình thức ghi nhật ký
khác, ví dụ: cho kế tốn. Thơng tin trong nhật ký hệ thống có thể nguy hiểm nếu kẻ
tấn cơng truy cập vào nó. Ngồi ra ghi log an tồn rất hữu ích khi nhật ký được sử
dụng để phát hiện và chẩn đốn các cuộc tấn cơng vào hệ thống.
Vấn đề đặt ra: Để phát hiện các cuộc tấn cơng và chẩn đốn lỗi hệ thống,
thơng tin chi tiết là đã đăng nhập. Thơng tin này có thể hữu ích cho những kẻ tấn
cơng hoặc kẻ tấn cơng có thể muốn xóa một số thơng tin này để che giấu một cuộc
tấn công. Nhật ký hệ thống tĩnh được yêu cầu để phát hiện và điều tra về các cuộc
tấn công và để gỡ xử lý lỗi nếu xảy ra lỗi hệ thống.
19


Yêu cầu:
• Các bản ghi càng chi tiết, chúng càng hữu ích cho việc xử lý lỗi và điều tra
các cuộc xâm nhập, nhưng chúng cũng càng có giá trị đối với kẻ tấn cơng.
• Nhật ký chi tiết hơn có ảnh hưởng đến hiệu suất.

Giải pháp: Ghi log an tồn mơ tả một giải pháp trong đó ứng dụng và nhật
ký được tách biệt và cách ly với nhau. Việc ghi log phải được thực hiện trong quá
trình ứng dụng tạo ra dữ liệu. Dữ liệu này được chuyển đến ghi log an toàn. Hệ
thống ghi log an toàn xử lý thông tin ghi nhật ký theo cách mà nó thực hiện thì rất
khó, nếu khơng muốn nói là khơng thể để kẻ xâm nhập có thể truy cập vào thơng
tin ghi nhật ký. Ngồi ra, có một “Log-Reader”. Điều này là cần thiết vì dữ liệu ghi
nhật ký được lưu trữ được bảo vệ và việc đọc chỉ được phép đối với một cơ chế đọc
cụ thể. Đọc nhật ký cũng có thể là một phần của Secure logger.
Kết quả: Khi áp dụng giải pháp này, cần xem xét các lợi ích sau:
• Hệ thống ghi nhật ký, Secure logger có thể được đặt trên một máy chủ từ
xa, ngăn ngừa mất hiệu suất ở hệ thống ứng dụng và làm cho việc kẻ tấn cơng để có
quyền truy cập vào hệ thống ghi nhật ký.
• Sự cơ lập của hệ thống ghi nhật ký cho phép thêm một bước phòng thủ, sau
nguyên tắc "Phòng thủ theo chiều sâu".
• Kẻ xâm nhập có được quyền truy cập vào dữ liệu nhật ký chỉ có khả năng
hiển thị hạn chế đối với nội dung dữ liệu.
• Việc sửa đổi dữ liệu nhật ký có thể được phát hiện bởi người dùng được ủy
quyền.
2.4. An toàn Client-Server
2.4.1. Khu vực phi quân sự
Mục đích: Các ứng dụng dịch vụ web phải được dễ dàng truy cập đối với
khách hàng. Ngoài ra, mọi hệ thống truy cập qua internet đều có thể là mục tiêu của
các cuộc tấn công, xâm nhập hệ thống hoặc đánh cắp dữ liệu. Phương pháp tiếp cận
của KHU VỰC PHI QUÂN SỰ sẽ tách biệt máy chủ web với các máy nghiệp vụ
khác trong hệ thống bằng cách thiết lập một hệ thống hai vùng, được ngăn cách bởi
tường lửa.

20