PDF:

Căn bản về kiến trúc cơ sở hạ tầng, Phần 6: Tự động kiểm
thử (Automated testing)
Kiểm tra cơ sở hạ tầng máy chủ phục vụ của bạn
Sean-Philip Oriyano
Giảng viên
Greater Detroit
16 10 2009
Khám phá một vài mối đe dọa máy chủ Web chung cũng như các công cụ và kỹ thuật mà bạn
có thể sử dụng để xác định và triệt tiêu chúng.
Xem thêm bài trong loạt bài này
Với cơ sở hạ tầng lớn và phức tạp, việc tìm ra các nguy cơ và vấn đề khác đã trở thành thách thức
hơn. Trước đây, việc tìm thấy các vấn đề sẽ tiêu tốn một lượng thời gian và nỗ lực đáng kể, bởi vì
bạn vừa phải truy tìm các vấn đề vừa tìm giải pháp cho từng vấn đề. Trong các môi trường cơ sở hạ
tầng ngày nay, kiểm thử tự động đã trở thành một giải pháp phổ biến, khi nó cho phép việc kiểm tra
và phục hồi chính xác với đội ngũ nhỏ hơn và số chu kỳ ngắn hơn.
Các từ viết tắt hay dùng
•
•
•
•
•
CSV: Các giá trị được phân cách bởi dấu phẩy (Comma-separated values)
ISP: Nhà cung cấp dịch vụ Internet
IT: Công nghệ thông tin
LAN: Mạng cục bộ
RAID: Mảng dự phòng các đĩa độc lập
Tiếp tục loạt bài Căn bản về kiến trúc cơ sở hạ tầng, bài viết thứ sáu này tập trung vào phía máy
chủ phục vụ (hosting side). Tuy nhiên, các khái niệm ở đây có thể thích nghi được với bất cứ môi
trường nào.
Các mối đe dọa máy chủ Web
Trước khi xem các công cụ và kỹ thuật mà bạn có thể sử dụng để kiểm tra và bảo mật một máy chủ
Web, hãy xem một số vấn đề chung mà các máy chủ Web phải đối mặt. Khi xem xét các mối đe
dọa an ninh sau, hãy nhớ rằng có những nguy cơ bảo mật cố hữu trong các máy chủ Web, mạng
LAN mà phục vụ những máy chủ này, và thậm chí những người dùng điển hình các trình duyệt
Web. Đầu tiên, hãy xem một mối đe dọa từ quan điểm của các nhà quản lý Web, người quản trị
mạng, và người dùng.
© Copyright IBM Corporation 2009
Căn bản về kiến trúc cơ sở hạ tầng, Phần 6: Tự động kiểm thử
(Automated testing)
Nhẫn hiệu đăng ký
Trang 1 của 10
developerWorks®
ibm.com/developerWorks/vn/
Từ quan điểm của người quản lý Web, mối quan tâm lớn nhất về bảo mật là những thứ được đưa
vào mạng của doanh nghiệp một cách đơn giản như một kết quả của việc được kết nối tới Internet.
Tất cả các loại đe dọa có thể được đưa vào bằng cách này, bao gồm các loại mã độc khác nhau
như là virut, trojan, sâu, và thậm chí các khiếm khuyết trong nội tại ứng dụng Web. Trong thực tế,
trong tình huống mà một tổ chức xây dựng ứng dụng Web cho một chức năng cụ thể hoặc việc
kiểm tra cần thiết có thể không bao giờ được thực hiện.
Từ quan điểm của người quản trị mạng, một máy chủ Web được cấu hình nhầm có thể dẫn đến vô
số các lỗ hổng trong bảo mật của một mạng LAN. Cấu hình của một máy chủ Web sắp đặt một cách
truyền thống một điều gì đó của một vấn đề, khi các nhà quản trị mạng và nhà quản lý Web bước
trên một ranh giới không rõ ràng giữa việc cấu hình một máy chủ Web để tối ưu bảo mật hoặc tối
ưu tính khả dụng. Thêm nữa, nó không lạ khi một người quản trị mạng hoặc người quản lý Web bỏ
qua các lựa chọn khác nhau bởi vì nhu cầu của của họ chỉ "làm cho mọi thứ hoạt động" nhanh nhất
có thể.
Cuối cùng, từ quan điểm của một khách hàng, các mối đe dọa lớn nhất dường như là những thứ
mà có thể gây hại nhiều nhất ở nền tảng. Nội dung như là các điều khiển Microsoft® ActiveX, các
Java™ applet, và những thứ mà có thể dẫn tới những đe dọa như là virut, sâu, và thậm chí phần
mềm gián điệp đối với hệ thống của người dùng. Mặc dù những mối đe dọa này không thể ảnh
hưởng trực tiếp tới doanh nghiệp, bởi vì chúng có thể nằm ở hệ thống của khách hàng, ảnh hưởng
trên danh tiếng của công ty có thể rất lớn. Nếu khách hàng sử dụng máy chủ Web hoặc ứng dụng
trên mạng cục bộ, sự nguy hiểm của các lỗ thủng mà mã độc hoặc kẻ tấn công có thể thâm nhập có
thể còn tệ hơn.
Sự rủi ro mạo hiểm trên nền Web
Bạn có thể phân mục một cách điển hình các rủi ro mà các máy chủ Web và các ứng dụng đối mặt
thành ba khu vực, mỗi khu vực đại diện cho một kiểu rủi ro rời rạc:
• Lỗi/cấu hình sai máy chủ Web cho phép người dùng trái phép từ xa:
• Lấy cắp bí mật hoặc thông tin nhạy cảm.
• Thực thi các lệnh hoặc mã lệnh trên máy chủ mà được thiết kế để thay đổi hoặc điều
khiển hệ thống theo một cách nào đó — ví dụ, cài rootkit và các cổng sau khác.
• Giả lập các dịch vụ trên máy chủ mà cho phép người dùng có thể gây tổn hại đến hệ
thống.
• Khởi động các cuộc tấn công từ chối dịch vụ (DoS) được thiết kế để ngăn máy chủ thực
hiện nhiệm vụ thông thường của nó.
• Rủi ro phía trình trình duyệt:
• Nội dung chủ động (active content) mà làm đổ vỡ trình duyệt, gây hại hệ thống của người
dùng, vi phạm sự riêng tư của người dùng, hoặc chỉ đơn thuần tạo ra sự phân tâm
• Sự sử dụng sai mục đích thông tin cá nhân mà người dùng cung cấp
• Chụp bắt dữ liệu mạng được truyền giữa trình duyệt và máy chủ bằng cách nghe lén (sniffing).
Những kẻ nghe lén có thể thao tác từ bất cứ điểm nào trên đường giữa trình duyệt và máy chủ,
bao gồm::
• Kết nối mạng phía trình duyệt.
• Kết nối mạng phía máy chủ cùng với mạng intranet.
Căn bản về kiến trúc cơ sở hạ tầng, Phần 6: Tự động kiểm thử
(Automated testing)
Trang 2 của 10
ibm.com/developerWorks/vn/
developerWorks®
• ISP của người dùng.
• ISP của máy chủ hoặc nhà cung cấp truy cập địa phương.
Kẻ tấn công có thể làm những gì với những công cụ và lựa chọn này với sự sắp xếp của chúng?
Thực sự thì rất nhiều, bao gồm việc thực hiện các cuộc tấn công như:
• Tiêm nhiễm Ngôn ngữ truy vấn có cấu trúc (Structured Query Language (SQL) injection):
Kẻ tấn công có thể sử dụng kiểu tấn công này để vận hành một cơ sở dữ liệu với mục đích thay
đổi hoặc chiết tách dữ liệu theo các cách mà không có trong thiết kế gốc.
• Thay đổi diện mạo (Defacement): Kẻ tấn công có thể thay đổi nội dung của một trang Web
thành một nội dung nào đó, như là đẩy lên một chương trình nghị sự chính trị.
• Tạo một cổng sau: Kiểu tấn công này có thể được sử dụng để "thả" một trình tiện ích hoặc
một phần khác của phần mềm với mục đích sử dụng nó sau này để thực hiện những hành
động như là khởi động một cuộc tấn công hoặc do thám.
Bây giờ, tôi không thể liệt kê tất cả các kiểu tấn công, nhưng nó rất quan trọng để nhận ra rằng một
kẻ tấn công có thể thực hiện bất kỳ việc gì để làm hại hoặc thay đổi một trang Web hoặc máy chủ
bằng cách sử dụng phương thức từ đơn giản đến phức tạp. Việc của nhà quản trị Web là chống lại
mối đe dọa này bằng cách sử dụng các công cụ tùy theo sử dụng của bạn. Trong trường hợp này,
bạn có thể sử dụng kiểm tra tự động để giúp bảo mật máy chủ Web của bạn.
Kỹ năng và khả năng: kiểm tra tự động
Trên thị trường ngày nay, có khá nhiều lựa chọn kiểm tra tự động sẵn sàng, mỗi lựa chọn đưa ra
những tính năng và lợi ích của riêng nó. Trước khi tôi đi vào cụ thể những lựa chọn này, chúng ta
hãy khám phá một số lý do mà bạn muốn sử dụng kiểm tra tự động.
Kiểm tra tự động đưa ra rất nhiều lợi ích cho những ai đang tìm cách phân tích cơ sở hạ tầng của họ
— ví dụ:
•
•
•
•
•
Kiểm tra tính nhất quán cấu trúc của các máy chủ và các trang Web.
Kiểm tra nhanh cùng lúc nhiều máy chủ và trang Web cũng như các ứng dụng.
Cấu hình đơn giản của các bộ kiểm tra.
Đa số các bộ kiểm tra được thiết kế để nắm bắt các vấn đề thông thường.
Một số bộ kiểm tra có thể được nâng cấp dễ dàng để khắc phục được những mối đe dọa và
nguy cơ mà xuất hiện sau khi bộ kiểm tra được tạo.
Ngoài các tùy chọn — cả nguồn mở và bản quyền — mà bạn có thể sử dụng để thực hiện việc quét
tự động, bạn phải hiểu tiến trình chung liên quan. Bạn có thể chỉnh sửa tiến trình ở đây để phù hợp
với môi trường doanh nghiệp bất kỳ.
Các công cụ và kỹ thuật: quét dò trong tổ chức của bạn
Khi thiết kế và xây dựng một chương trình quét dò doanh nghiệp, nó rất quan trọng để nhận ra rằng
bạn không thể áp dụng một giải pháp chuẩn. Nói chung, quá trình thiết kế và xây dựng yêu cầu một
khối lượng kế hoạch chắc chắn để thành công và sản sinh các kết quả hữu ích cho tổ chức. Tiến
trình lập kế hoạch ban đầu phải giải quyết các vấn đề kỹ thuật, chính trị, văn hóa và các quy định
mà áp dụng ở doanh nghiệp. Hãy nhớ rằng thông tin được thu thập trong quá trình thiết kế và xây
dựng sẽ thay đổi một cách rộng lớn tùy theo tổ chức mà việc quét thực hiện.
Căn bản về kiến trúc cơ sở hạ tầng, Phần 6: Tự động kiểm thử
(Automated testing)
Trang 3 của 10
developerWorks®
ibm.com/developerWorks/vn/
Bởi vì mỗi tổ chức có mục đích và môi trường độc nhất mà là đích của việc quét dò, một số lời
khuyên chung chung áp dụng cho tiến trình phân tích và xây dựng:
• Thực hành: Đừng giả sử rằng bạn biết chi tiết mọi thứ về môi trường của bạn: Bạn có thể
không biết mọi thành phần then chốt bên trong tổ chức (đặc biệt trong một môi trường doanh
nghiệp). Hơn cả thường xuyên, tôi đã thấy các nhân viên bảo mật hoặc các cá nhân có trách
nhiệm cho phép cái tôi của họ tham gia và giả định rằng họ biết tuốt, điều mà thường là không
biết. Đừng sợ khi đặt câu hỏi với phòng IT và bất cứ phòng khác có liên quan sao cho bạn có
thể nắm bắt nhiều hơn về tình trạng, nhu cầu của họ và các chi tiết cụ thể chung và riêng khác
của họ.
• Tính bí mật: Bởi vì bạn đang thực hiện việc quét tìm nguy cơ bảo mật mà sẽ mở "lỗ hổng"
trong máy chủ hiện tại và các phần khác của cơ sở hạ tầng, những cám dỗ chắc chắn là có để
giữ những điều bí mật. Trong một vài tình huống, nó thực sự đáng giá để giữ kín tiến trình quét
tìm — nhưng nói chung, đây không phải là trường hợp đó. Việc giữ kín quá trình quét dò nguy
cơ bảo mật có thể dẫn đến một số vấn đề, như gây ra báo động khi ai đó phát hiện ra quá trình
quét dò. Thực vậy, để có được các kết quả tốt nhất, việc quét dò liên quan trực tiếp đến không
chỉ những ai chịu trách nhiệm cho bảo mật mà còn những nhà quản trị IT, các nhà phát triển,
và những người khác mà môi trường của họ sẽ bị quét dò. Hãy nhớ rằng kết quả của việc quét
dò là để sinh ra một kết quả mà bạn có thể sử dụng để cải thiện bảo mật và trợ giúp mọi người
giải quyết các vấn đề. Nhắc nhở mọi người có liên quan rằng mục đích của việc quét dò là để
cải thiện sự hiểu biến, chứ không phải là để giám sát cách mà mọi người thực hiện công việc
của họ.
• Việc quét dò là nỗ lực nhóm: Điểm này là sự mở rộng của điểm trước. Để việc quét dò càng
thành công càng tốt và tạo ra các kết quả tốt nhất, mọi người trong tổ chức cả những người có
vai trò nhỏ trong các hệ thống bị ảnh hưởng bởi việc quét dò nên tham gia vào việc quét dò.
Trong mục trước, bạn thu thập thông tin từ mọi người mà có thể có liên quan với các hệ thống
bị quét dò; trong mục này, bạn đang đảm bảo rằng họ được thông báo về nguồn gốc của việc
quét dò và thời gian quét. Nó quan trọng để nhận ra rằng thiếu bước này, hiệu quả của việc
quét dò có thể thảm kịch, làm cho mọi thứ từ hiệu năng giảm sút đến, trong một vài trường
hợp, đổ vỡ hệ thống. Việc thông báo với toàn bộ nhân viên người mà quản lý và điều khiển các
hệ thống đang bị quét dò đầu tiên là đảm bảo rằng họ biết và thứ hai là đảm bảo rằng họ sẵn
sàng trong trường hợp hệ thống đổ vỡ hoặc hoạt động bất thường. Hãy nhớ: mục đích của việc
quét dò của bạn là để tăng hiểu biết và bảo mật cho máy chủ và cơ sở hạ tầng khác của bạn.
Làm cho cơ sở hạ tầng của bạn ngưng hoạt động hoặc hoạt động chậm là đi ngược lại với mục
đích.
• Sự rủi ro mạo hiểm và phần thưởng: Bởi vì cách hoạt động của việc quét tìm, nó hoàn toàn có
thể rằng việc quét tìm tạo ra những kết quả không chỉ không mong muốn mà còn hoàn toàn
không thể đoán trước được. Khi trong quá trình, việc quét tìm được biết đến như một sự kiện
DoS nhỏ của chính nó hoặc gây đổ vỡ hệ thống. Đây là điểm mà bạn phải đưa ra quyết định:
Có phải lợi ích của việc biết những gì có thể xảy ra nếu đổ vỡ hệ thống hoặc tấn công từ chối
dịch vụ xảy ra có lợi hơn sự rủi ro của việc gây đổ vỡ hệ thống hoặc tạo ra sự kiện DoS trong
quá trình kiểm tra? Hơn nữa, có phải việc tạo ra những kết quả này sẽ cho phép bạn đặt biện
pháp đối phó để giảm hoặc triệt tiêu nguy cơ mạo hiểm? Tại điểm này, nó cũng đáng giá để lưu
ý rằng nhiều phần mềm quét dò mà bạn chọn để dùng không phải chỉ có bạn dùng được mà cả
những kẻ tấn công cũng dùng được. Thêm vào nữa, nhiều sản phẩm quét dò cung cấp lựa chọn
Căn bản về kiến trúc cơ sở hạ tầng, Phần 6: Tự động kiểm thử
(Automated testing)
Trang 4 của 10
ibm.com/developerWorks/vn/
developerWorks®
thực hiện việc quét hung hãn nhiều hoặc ít tùy theo nhu cầu của bạn, với kiểu quét hung hãn
thì có nguy cơ làm ngưng hệ thống.
• Quét dò theo từng giai đoạn: Đôi khi, việc thực hiện quét dò theo từng giai đoạn có lợi hơn
là thực hiện việc tất cả việc quét tìm trong một lần. Thêm vào nữa, việc cho phép từng người
quản trị hoặc nhà phát triển thực hiện với lịch biểu của chính họ để tránh việc quét dò vào thời
điểm không lý tưởng (như là khi đang thực hiện một dự án quan trọng) có lợi hơn. Nói chung,
việc thực hiện quét tìm theo giai đoạn tạo ra kết quả tốt hoặc kết quả tương tự với những gì mà
được tạo ra nếu một cuộc quét tìm trên toàn bộ tổ chức được thực hiện một lần. Hãy cân nhắc
việc loại trừ tạm thời các hệ thống ra khỏi việc quét tìm và thực hiện quét từng cái trong giai
đoạn khác: Rủi ro của việc làm ngưng trệ một hệ thống có thể có nhiều ảnh hưởng hơn so với
lợi ích của việc quét tìm. Cũng vậy, bằng cách cho phép mỗi phòng ban thực hiện việc quét tìm
của chính họ với lịch biểu của chính họ, những phòng ban đó có thể thực hiện các cuộc quét
tìm nhỏ mà có thể nắm được các vấn đề nhanh hơn và giải quyết tạm các vấn đề.
Bắt tay vào việc
Bây giờ, quá trình lập kế hoạch cho việc quét dò xảy ra thế nào? Cũng như những thứ khác, bạn
phải có các công cụ để giải quyết việc. Trong trường hợp này, tôi khuyên bạn dùng phần mềm bảng
tính ưa thích của bạn để hỗ trợ bạn trong quá trình thu thập dữ liệu.
Giai đoạn 1: Thu thập thông tin thống kê
Trong giai đoạn này, bạn đang cố gắng đạt được đầy đủ (hoặc càng đầy đủ càng tốt) bức tranh của
các hệ thống mà sẽ là phần của việc quét. Những hệ thống này nên bao gồm một cách lý tưởng tất
cả các hệ thống chịu trách nhiệm cho việc phục vụ ứng dụng của bạn cũng như bất cứ hệ thống hỗ
trợ nào.
Cách bạn thu thập thông tin này thực sự phụ thuộc vào những gì bạn có thể có hiện tại. Ví dụ, một
số tổ chức có phần mềm quản lý các hệ thống cấp doanh nghiệp mà đã thu thập thông tin về tất cả
các phần cứng và phần mềm có trong tổ chức. Nếu tổ chức của bạn không phải vậy, việc tạo các
báo cáo theo định dạng CSV hoặc tương thích với bảng tính có thể tương đối dễ đối với bạn. Nếu
bạn không đủ may mắn để có những công cụ đó trong tay, bạn có thể phải cầu đến phương cách
cũ, cách mà xác định và thống kê mỗi hệ thống một cách thủ công.
Lưu ý: Hãy chắc rằng bạn có bức tranh đầy đủ nhất có thể để thực hiện việc quét tìm tốt nhất và
thành công nhất. Sau khi bạn có thông tin và đã xác định được các hệ thống cơ sở hạ tầng máy
chủ, bạn có thể chuyển sang giai đoạn tiếp theo: phân loại các hệ thống.
Giai đoạn 2: Phân loại các hệ thống
Bây giờ, bạn có thể sử dụng thông tin mà bạn thu thập được trong giai đoạn 1 để phân chia thông
tin thành các phân mục hữu dụng hơn. Hãy cân nhắc nó như một tổ chức cỡ doanh nghiệp, bạn có
lẽ có các môi trường máy chủ phục vụ trong rất nhiều vị trí địa lý cũng như xuyên qua các kiểu hệ
thống khác nhau. Mục đích của giai đoạn này là chia các môi trường mục tiêu thành càng nhiều
nhóm rời rạc càng tốt để làm cho việc quét dò đã định càng hiệu quả càng tốt.
Có nhiều cách để phân chia một hệ thống: cái nào bạn dùng là tùy thuộc và các nhu cầu cụ thể của
bạn. Nói chung, bạn nên chia các hệ thống vào các phân mục bằng cách sử dụng các nhân tố như:
Căn bản về kiến trúc cơ sở hạ tầng, Phần 6: Tự động kiểm thử
(Automated testing)
Trang 5 của 10
developerWorks®
ibm.com/developerWorks/vn/
• Hệ điều hành và phiên bản: Có ích trong việc xác định việc quét tìm, thông hiểu các kết quả,
và lưu vết các vấn đề với các phiên bản hệ điều hành cụ thể
• Máy chủ và sản phẩm kiểm tra: Máy chủ nào đang chạy ứng dụng nào
• Sự quan trọng và tính nghiêm trọng: Giúp cho việc xác định những hệ thống nào cần được
xử lý cẩn thận hơn (nói cách khác, quét hung bạo nhiều hay ít) và hệ thống nào nên được theo
dõi kỹ hơn chỉ trong trường hợp việc quét tìm gây ra kết quả không mong muốn (như gây đổ
vỡ hệ điều hành chẳng hạn).
Bạn cũng có thể chọn để phân loại hệ thống dựa trên khu vực, người quản lý hệ thống, hoặc bất kỳ
tổ hợp các nhân tố trên nào.
Giai đoạn 3: Quét tìm
Sau khi bạn đã hoàn tất việc tính toán cho tất cả các hệ thống đích, bạn có thể chuyển đến giai
đoạn quét tìm. Khi chuẩn bị quét các hệ thống, bạn nên thu thập các địa chỉ IP cụ thể và các tên
máy chủ của các hệ thống sẽ được quét (bất cứ cái gì mà công cụ quét tìm của bạn yêu cầu). Thông
tin này phải nằm trong bản báo cáo hoặc bảng tính của bạn.
Khi tạo một danh sách các hệ thống được quét, hãy cân nhắc việc phân chia chúng thành các
nhóm tương tự để quét, như là tất cả các hệ thống Linux® hoặc UNIX®, để đảm bảo rằng việt quét
được thực hiện đúng. Thêm nữa, việc gộp nhóm các hệ thống theo kiểu làm tăng hiệu suất, khi bạn
có thể chỉ tải những trình tiện ích cắm-chạy được yêu cầu để quét hệ điều hành và môi trường máy
chủ theo yêu cầu.
Bước tiếp theo trong việc quét tìm là tạo ra các đầu việc quét tìm bao gồm từng nhóm của các hệ
thống sẽ được quét. Hãy cân nhắc việc gán tên có ý nghĩa cho các đầu việc quét tìm của bạn, như
là Các máy chủ kiểm tra ở Las Vegas, các máy chủ ở Napa, hoặc Máy chủ phát triển ở Placerville,
để giúp xác định các kết quả và kiểu của từng việc quét tìm sau này. Một cách lý tưởng, các tên của
đầu việc quét tương ứng với các nhóm máy chủ khác nhau mà bạn đã thu thập từ trước; nhưng dù
gì đi nữa, hãy chắc rằng chúng được đặt tên gì đó mà bạn có thể hiểu và xác định được sau này.
Tại điểm này, bạn có thể bắt đầu với quá trình quét tìm thực sự. Tùy theo phần mềm quét tìm của
bạn, quá trình cho việc khởi tạo quét tìm sẽ biến đổi rất nhiều mà bài viết này không thể viết chi tiết
cho từng cái.
Giai đoạn 4: Thông hiểu các kết quả
Trong giai đoạn này, bạn lấy các báo cáo được tạo ra trong giai đoạn trước và tìm các vấn đề cần
giải quyết. Khi phân tích dữ liệu, hãy tìm các vấn đề mà chưa được khám phá, và phân loại chúng
bởi tính nguy hiểm hoặc nghiêm trọng của chúng — ví dụ:
• Cao: Các vấn đề mà có mức độ rủi ro mạo hiểu nghiêm trọng gắn liền với chúng và có khả
năng gây tổn hại nghiêm trọng tới doanh nghiệp
• Vừa: Các vấn đề mà là có khả năng nguy hiểm nhưng có mức độ rủi ro mà làm cho chúng
dường như không (nhưng vẫn có thể) làm ngưng trệ sự sản xuất nếu bị khai thác
• Thấp: Các vấn đề mà có độ rủi ro thấp và không có khả năng làm ngưng trệ quá trình sản xuất
hoặc ngăn cản hệ thống hoạt động
Căn bản về kiến trúc cơ sở hạ tầng, Phần 6: Tự động kiểm thử
(Automated testing)
Trang 6 của 10
ibm.com/developerWorks/vn/
developerWorks®
Bởi vì các vấn đề bạn sẽ gặp sẽ là duy nhất cho môi trường của bạn, bạn sẽ cần đánh giá từng vấn
đề theo nhu cầu và môi trường của chính bạn. Để ưu tiên một cách đúng đắn các vấn đề đã xác
định được, hãy cân nhắc việc lôi kéo các chuyên gia từ từng phòng ban hoặc tổ chức tham gia với
giải pháp phục vụ và tìm kiếm đầu vào của từng cái đối với mức độ nguy hiểm của các vấn đề. Nếu
bạn tìm kiếm sự phản hồi thuần khiết, không bị sàng lọc, hãy cân nhắc sử dụng phương pháp phản
hồi Delphic, cách mà mỗi nhóm nộp những phản hồi của họ một cách nặc danh.
Các kỹ năng và khả năng: Các bất biến trong quá trình quét tìm
Các kỹ năng và khả năng liên quan đến quá trình quét tìm này có thể biến đổi — đôi khi rất rộng.
Tuy nhiên, vẫn có một số thứ bất biến:
• Quản lý: Sự quản lý đúng đắn các kết nối và ứng dụng có thể giảm rất lớn nguy cơ của các mối
đe dọa mà một cơ sở hạ tầng phục vụ đối mặt.
• Máy chủ: Nắm rõ môi trường phần cứng và mềm mà chịu trách nhiệm phục vụ các ứng dụng
và dịch vụ trong môi trường.
• Quản lý bản vá lỗi: Bạn cần khả năng để định vị nhanh chóng và áp dụng các bản vá lỗi và các
bản cập nhật khác để đảm bảo rằng cơ sở hạ tầng phục vụ của bạn không bị tổn thương bởi
các kiểu tấn công mới.
• Sao lưu: Sử dụng bất cứ công nghệ sao lưu nào để ngăn chặn việc mất dữ liệu và thông tin về
môi trường khi có thảm họa thiên nhiên hoặc bị tấn công.
Các công cụ và kỹ thuật: Quá trình quét dò
Các công cụ liên quan đến trá trình quét dò nhiều vô số. Đây chỉ là một vài công cụ phổ biến được
chọn:
• Các trình quét lỗ hổng: Phần mềm này được thiết kế để phát hiện các lỗ hổng phổ biến và ít
phổ biến trong hệ thống và, trong một số trường hợp, gợi ý cách sửa chữa.
• Kiểm tra: Kiểm tra ứng dụng là một kỹ thuật vô giá mà bạn có thể làm để bảo vệ tổ chức của
bạn. Một cách lý tưởng, việc kiểm tra toàn diện này sẽ được hoàn tất trong một môi trường thí
nghiệm được cô lập với mục đích mô phỏng càng giống các điều kiện trong môi trường thực
càng tốt để nắm được các vấn đề sớm.
• Lập kế hoạch cấu hình: Việc lập kế hoạch đúng đắn cho cấu hình của bạn có thể dẫn đến một
tiêu chuẩn đánh giá mạnh mẽ của việc bảo vệ chống lại việc cấu hình sai sau này. Mặc dù nó
rất khó để đưa ra con số chính xác, nhưng ta có thể nói rằng một số lớn —thực tế là cực kỳ lớn
— các vấn đề là kết quả từ việc cấu hình sai hoặc việc cấu hình tùy tiện của các hệ thống.
• Tính sẵn sàng cao: Việc lập kế hoạch cho tính sẵn sang cao có thể là sự phòng ngự tuyệt vời
trong doanh nghiệp khi bảo vệ an toàn chống lại các hỏng hóc. Các công nghệ như là phân
cụm, RAID, và các kiểu dự phòng và phòng chống lỗi khác có thể cung cấp một hàng rào
hùng mạnh chống lại các vấn đề tiềm năng và đảm bảo rằng các dữ liệu có giá trị và các ứng
dụng không bị xâm hại. Hãy nhớ rằng các giải pháp cho tính sẵn sàng cao có thể là phần cứng,
phần mềm hoặc một giải pháp lai bao gồm cả hai.
Kết luận
Bài viết này xem xét một vài đe doạ thông dụng mà các máy chủ Web đối mặt và các kỹ thuật mà
bạn có thể sử dụng để xác định và triệt tiêu chúng. Việc lập kế hoạch một cách cẩn thận cho quá
Căn bản về kiến trúc cơ sở hạ tầng, Phần 6: Tự động kiểm thử
(Automated testing)
Trang 7 của 10
developerWorks®
ibm.com/developerWorks/vn/
trình quét tìm sẽ sinh ra các kết quả tốt nhất và hữu dụng nhất và cho phép sửa chữa các vấn đề
một cách đúng đắn.
Căn bản về kiến trúc cơ sở hạ tầng, Phần 6: Tự động kiểm thử
(Automated testing)
Trang 8 của 10
ibm.com/developerWorks/vn/
developerWorks®
Tài nguyên
Học tập
• Duyệt kho sách công nghệ để tìm sách về chủ đề này và các các chủ đề kỹ thuật khác.
• "Developing secure Web applications: An introduction to IBM Rational AppScan Developer
Edition"> (developerWorks (Sep, 2008) tập trung vào vai trò mà nhà phát triển cần thực hiện
trong việc cải thiện bảo mật của ứng dụng Web, và các chi tiết cách IBM Rational AppScan
Developer Edition giúp họ làm điều đó.
Lấy sản phẩm và công nghệ
• Tải phiên bản thử nghiệm miễn phí của IBM Rational AppScan V7.7, trước kia là Watchfire
AppScan, một công cụ kiểm tra bảo mật ứng dụng Web mà tự động đánh giá và quét lỗ hổng
và kiểm tra toàn bộ các lỗ hổng ứng dụng Web phổ biến bao gồm SQL-injection, cross-site
scripting và tràn bộ đệm.
• Xem Top 10 trình quét lỗ hổng được lập bởi insecure.org.
Thảo luận
• Tham khảo developerWorks blogs và tham gia vào cộng đồng developerWorks.
Căn bản về kiến trúc cơ sở hạ tầng, Phần 6: Tự động kiểm thử
(Automated testing)
Trang 9 của 10
developerWorks®
ibm.com/developerWorks/vn/
Đôi nét về tác giả
Sean-Philip Oriyano
Sean-Philip Oriyano đã và đang làm việc một cách tích cực trong lĩnh vực công nghệ
thông tin từ năm 1990. Trong suốt sự nghiệp, ông đã nắm giữ các vị trí như chuyên gia
hỗ trợ cho các nhà tư vấn và trợ giảng cao cấp. Hiện nay, ông là một trợ giảng công
nghệ thông tin chuyên về các chủ đề bảo mật và cơ sở hạ tầng cho hàng loạt các đơn
vị công và tư. Sean đã dạy cho lực lượng không quân Mỹ, hải quân Mỹ, và quân đội
Mỹ ở cả Bắc Mỹ và quốc tế. Sean được chứng nhận là một CISSP, CHFI, CEH, CEI,
CNDA, SCNP, SCPI, MCT, MCSE, và MCITP, và ông ấy là thành viên của EC-Council,
ISSA, Elearning Guild, và Infragard
© Copyright IBM Corporation 2009
(www.ibm.com/legal/copytrade.shtml)
Nhẫn hiệu đăng ký
(www.ibm.com/developerworks/vn/ibm/trademarks/)
Căn bản về kiến trúc cơ sở hạ tầng, Phần 6: Tự động kiểm thử
(Automated testing)
Trang 10 của 10