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