Trong chương này,các bạn sẽ

• Học cách triển khai phát triển ứng dụng an toàn
• Hiểu các khái niệm phát triển an toàn
• Khám phá việc bổ sung bảo mật cho các quy trình phát triển tự động / nhanh (automated/agile)

Phát triển phần mềm là một quá trình phức tạp với nhiều vấn đề khác nhau, từ thiết kế, mã hóa, đến kiểm tra và triển khai, cần được xem xét và quản lý để đạt được các mục tiêu mong muốn của phần mềm an toàn. Phát triển và sử dụng quy trình phát triển ứng dụng bao gồm bảo mật là điều cần thiết. Việc mở rộng quy trình đó để bao gồm các vấn đề về phân phối và sau triển khai là điều cần thiết và một trong những công cụ quan trọng để đạt được các mục tiêu này là sử dụng tự động hóa và viết kịch bản. Chương này bao gồm các vấn đề này liên quan đến mục tiêu kỳ thi Security+ Version 6.

Certification Objective Chương này bao gồm mục tiêu 2.3 của kỳ thi CompTIA Security+: Tóm tắt các khái niệm về phát triển, triển khai và tự động hóa ứng dụng an toàn

Environment

Hầu hết các tổ chức có nhiều môi trường máy tính riêng biệt được thiết kế để cung cấp sự cô lập giữa các chức năng phát triển, kiểm tra, dàn dựng và sản xuất. Mục đích chính của việc có các môi trường riêng biệt này là để ngăn chặn các sự cố bảo mật phát sinh từ mã chưa được kiểm tra kết thúc trong môi trường sản xuất. Phần cứng của các môi trường này được tách biệt và danh sách kiểm soát truy cập được sử dụng để ngăn người dùng truy cập vào nhiều môi trường cùng một lúc. Việc di chuyển mã giữa các môi trường yêu cầu một tài khoản đặc biệt có thể truy cập cả hai, giảm thiểu các vấn đề lây nhiễm chéo.

Development

Môi trường phát triển (development   environment) được định cỡ, cấu hình và thiết lập để phát triển các ứng dụng và hệ thống. Không giống như phần cứng sản xuất, phần cứng phát triển không nhất thiết phải có khả năng mở rộng và nó có thể không cần phải đáp ứng nhanh cho các giao dịch nhất định. Nền tảng phát triển cần phải sử dụng cùng một loại hệ điều hành và phiên bản như được sử dụng trong môi trường sản xuất, để phát triển trên Windows và triển khai lên Linux gặp rất nhiều khó khăn có thể tránh được bằng cách phù hợp với môi trường về loại hệ điều hành và phiên bản. Sau khi mã được phát triển thành công, nó được chuyển sang hệ thống thử nghiệm

Test

Môi trường thử nghiệm bắt chước khá chặt chẽ môi trường sản xuất — các phiên bản phần mềm giống nhau, đến mức vá lỗi, cùng bộ quyền, cùng cấu trúc tệp, v.v. Mục đích của môi trường thử nghiệm là kiểm tra toàn bộ hệ thống trước khi triển khai vào sản xuất để đảm bảo rằng nó không có lỗi và sẽ không làm gián đoạn môi trường sản xuất. Môi trường thử nghiệm có thể không quy mô như sản xuất, nhưng từ quan điểm của phần mềm / phần cứng, nó sẽ giống hệt như sản xuất. Điều này rất quan trọng để đảm bảo rằng các cài đặt dành riêng cho hệ thống được kiểm tra trong một môi trường giống hệt với môi trường mà chúng sẽ được chạy

Staging

Môi trường dàn dựng (staging environment) là một môi trường tùy chọn, nhưng nó thường được sử dụng khi một tổ chức có nhiều môi trường sản xuất. Sau khi vượt qua thử nghiệm, hệ thống chuyển sang giai đoạn dàn dựng, từ đó nó có thể được triển khai cho các hệ thống sản xuất khác nhau. Mục đích chính của dàn là để phục vụ như một hộp cát sau khi thử nghiệm, do đó, hệ thống thử nghiệm có thể kiểm tra tập tiếp theo trong khi tập hiện tại được triển khai trên toàn doanh nghiệp. Một phương pháp triển khai là triển khai theo giai đoạn, trong đó phần mềm được triển khai cho một phần của doanh nghiệp và sau đó tạm dừng xảy ra để theo dõi các vấn đề chưa thấy. Nếu không có gì xảy ra, việc triển khai tiếp tục, từng giai đoạn, cho đến khi tất cả các hệ thống sản xuất được thay đổi. Bằng cách di chuyển phần mềm theo cách này, bạn sẽ không bao giờ mất hệ thống sản xuất cũ cho đến khi kết thúc quá trình di chuyển, giúp bạn có thời gian theo dõi và nắm bắt mọi vấn đề không lường trước được. Điều này cũng ngăn chặn việc mất toàn bộ quá trình sản xuất đối với một bản cập nhật không thành công

Production

Môi trường sản xuất (production environment) là nơi các hệ thống làm việc với dữ liệu thực, thực hiện công việc kinh doanh mà hệ thống dự định thực hiện. Đây là môi trường mà theo thiết kế, rất ít thay đổi xảy ra và những thay đổi đó trước tiên phải được phê duyệt và kiểm tra thông qua quy trình quản lý thay đổi của hệ thống.

Exam Tip Hiểu cấu trúc và mục đích của các môi trường khác nhau để khi được đưa ra một kịch bản và được yêu cầu xác định môi trường nào phù hợp, bạn có thể chọn câu trả lời tốt nhất: phát triển, thử nghiệm, dàn dựng hoặc sản xuất (development, test, staging, production)

Quality          Assurance (QA)

Đảm bảo chất lượng (QA – Quality assurance) là một bước phổ biến trong bất kỳ quy trình sản xuất nào và phần mềm cũng không ngoại lệ. Đảm bảo rằng chất lượng trong một sản phẩm là một vấn đề quy trình, không phải là một vấn đề kiểm tra. Đúng vậy, vẫn cần phải kiểm tra, nhưng hiện đại của nghệ thuật là thúc đẩy các vấn đề về bảo mật và chất lượng thông qua quá trình xây dựng phần mềm thực tế, chứ không phải có hàng loạt người kiểm tra sau khi nó được xây dựng. Điều này đang được nói, vẫn còn vai trò của những người tập trung vào các vấn đề chất lượng và bảo mật trong việc duy trì sổ đăng ký lỗi (danh sách tất cả các lỗi) và giúp những người chính xác trong nhóm nhận được thông tin chính xác liên quan đến việc xây dựng phần mềm an toàn.

Provisioning and Deprovisioning

Cấp phép (Provisioning) là quá trình gán quyền hoặc quyền hạn cho các đối tượng. Người dùng có thể được cấp phép thành các nhóm và các quy trình hoặc luồng máy tính có thể được cấp cho các cấp quyền cao hơn khi thực thi. Hủy cấp phép là loại bỏ các quyền hoặc thẩm quyền. Trong mã hóa an toàn, thực tiễn là chỉ cung cấp một luồng lên cấp độ thực thi nâng cao (ví dụ: root) trong thời gian cần có quyền quản trị. Sau khi các bước đó trôi qua, chuỗi có thể được đã hủy cấp phép trở lại cấp truy cập thấp hơn. Sự kết hợp này làm giảm khoảng thời gian ứng dụng ở cấp độ thẩm quyền cao hơn, do đó giảm nguy cơ rủi ro nếu chương trình bị tấn công hoặc bị tấn công.

Integrity Measurement

Tính toàn vẹn (Integrity) được định nghĩa trong lĩnh vực bảo mật là xác định rằng dữ liệu không có thay đổi trái phép. Trong môi trường phát triển và triển khai phần mềm, đây là một vấn đề rất quan trọng vì ngay cả những thay đổi nhỏ cũng có thể gây ra những vấn đề lớn và khó phát hiện. Duy trì quyền kiểm soát đối với cơ sở mã có nghĩa là hai điều đang xảy ra. Đầu tiên, bạn có quyền kiểm soát các bản sao theo cách mà mọi người chỉ đang làm việc trên một cơ sở mã hợp pháp. Không gì làm hỏng một ngày nhanh hơn việc học phiên lập trình cả ngày của bạn được thực hiện trên một bộ mã chưa được cập nhật — nói cách khác, bạn đã làm việc trên một bản sao sai. Mặc dù không thảm hại bằng việc sơn nhầm nhà (bạn không cần phải sơn lại), nhưng về bản chất công trình đã bị mất. Khi mã được thay đổi liên tục từ nhiều tác giả, điều này không đơn giản như bạn tưởng tượng và cần phải có một số hình thức kiểm soát phiên bản. Thứ hai, bạn duy trì nhật ký các thay đổi và phương pháp xác định các phiên bản. Hệ thống kiểm soát phiên bản bạn sử dụng nên theo dõi các phiên bản, nhưng để xác định rõ ràng một bộ mã thì cần một công cụ khác. Thuật toán hash tạo ra một giá trị hash duy nhất cho mỗi mục duy nhất mà nó hoạt động và cơ sở mã là các đối tượng kỹ thuật số. Duy trì một thư mục các giá trị hash biểu thị các phiên bản khác nhau của cơ sở mã là cách các kiểm soát tính toàn vẹn được chú thích trong mã. Nếu bạn có một phiên bản của mã, bạn có thể hash nó và tra cứu trong bảng phiên bản để xem bạn có phiên bản nào. Điều này vượt trội hơn so với việc gắn nhãn trong mã với siêu dữ liệu vì các nhãn có thể được thay đổi, nhưng hàm hash được gắn với mã. Khi mã được phát hành để triển khai, nó thường được ký kỹ thuật số và một lần nữa các giá trị băm đảm bảo người dùng rằng mã không bị thay đổi.

Secure           Coding           Techniques

Bảo mật phần mềm bắt đầu với mã an toàn và không có lỗ hổng. Thật không may, tất cả mã đều có điểm yếu và lỗ hổng, vì vậy việc khởi tạo mã theo cách có khả năng bảo vệ hiệu quả để ngăn chặn việc khai thác các lỗ hổng có thể giúp duy trì mức độ bảo mật mong muốn. Việc xử lý các cấu hình, lỗi và ngoại lệ và đầu vào đúng cách có thể hỗ trợ việc tạo một ứng dụng an toàn. Kiểm tra ứng dụng trong suốt vòng đời hệ thống có thể xác định hồ sơ rủi ro bảo mật thực tế của hệ thống.

Có nhiều yếu tố riêng lẻ trong vòng đời phát triển an toàn (SDL – secure development lifecycle) có thể hỗ trợ một nhóm phát triển mã bảo mật. Các quy trình SDL chính xác, chẳng hạn như xác thực đầu vào, xử lý lỗi và ngoại lệ thích hợp, cũng như giảm thiểu giả mạo yêu cầu chéo trang web và yêu cầu chéo trang web, có thể cải thiện tính bảo mật của mã. Các yếu tố quy trình như kiểm tra bảo mật, quản lý mờ và vá lỗi cũng giúp đảm bảo các ứng dụng đáp ứng được hồ sơ rủi ro mong muốn.

Normalization

Chuẩn hóa (Normalization) là bước đầu tiên trong quá trình xác nhận đầu vào. Cụ thể, đó là quá trình tạo biểu mẫu chuẩn, hoặc biểu mẫu đơn giản nhất, của một chuỗi trước khi xử lý. Các chuỗi có thể được mã hóa bằng Unicode và các phương pháp mã hóa khác. Điều này làm cho việc so sánh từng byte trở nên vô nghĩa khi cố gắng sàng lọc đầu vào của người dùng đối với các chuỗi. Việc kiểm tra xem chuỗi có phải là “rose” hay không có thể khó khăn khi “A Rose is a rose is a r%6fse”. Quá trình chuẩn hóa chuyển đổi tất cả những thứ này thành ” rose “, nơi chúng có thể được sàng lọc như là đầu vào hợp lệ

Các thư viện khác nhau tồn tại để hỗ trợ các nhà phát triển thực hiện phần xác thực đầu vào này. Các nhà phát triển phải luôn chuẩn hóa đầu vào của họ trước khi thực hiện các bước xác thực để loại bỏ Unicode và các vấn đề mã hóa khác. Theo tiêu chuẩn Unicode, “Khi triển khai giữ các chuỗi ở dạng chuẩn hóa, họ có thể yên tâm rằng các chuỗi tương đương có một biểu diễn nhị phân duy nhất.”

A Rose          is a rose is a r%6fse Dạng chuẩn đề cập đến dạng đơn giản nhất và do có nhiều lược đồ mã hóa được sử dụng, có thể là một vấn đề phức tạp. Các ký tự có thể được mã hóa bằng ASCII, Unicode, hex, UTF-8, và thậm chí cả sự kết hợp của những ký tự này. Vì vậy, nếu kẻ tấn công muốn làm xáo trộn một phản hồi, thì một số điều có thể xảy ra.   Bằng các chuỗi URL mã hóa URL, có thể vượt qua hệ thống bảo mật bộ lọc và hệ thống phát hiện xâm nhập. Ví dụ: URL http://www.myweb.com/cgi?file=/etc/passwd có thể trở thành như sau: Mã hóa kép (Double-encoding) có thể làm phức tạp thêm vấn đề. Như vậy, giải mã vòng 1 scripts/..%255c../winnt trở thành như sau: Và giải mã vòng 2 scripts/..%5c../winnt trở thành như sau: scripts/..\../winnt Điểm mấu chốt rất đơn giản: biết rằng mã hóa có thể được sử dụng và lập kế hoạch cho nó khi thiết kế cơ chế xác minh đầu vào. Mong đợi việc truyền được mã hóa sẽ được sử dụng để cố gắng vượt qua các cơ chế bảo mật.

Stored           Procedures

Các thủ tục lưu trữ (Stored procedures) là các phương pháp giao tiếp với các công cụ cơ sở dữ liệu. Các thủ tục được lưu trữ là các phương pháp truy cập dữ liệu được biên dịch sẵn theo kịch bản mang lại nhiều ưu điểm. Đầu tiên là tốc độ. Bởi vì chúng được biên dịch trước, chúng có thể chạy hiệu quả hơn nhiều trong môi trường sản xuất. Nhưng vì chúng được viết kịch bản trước, chúng cung cấp ít tính linh hoạt hơn nhiều so với các phương pháp khác, chẳng hạn như sử dụng các truy vấn được tham số hóa hoặc xây dựng và thực thi các câu lệnh SQL trong một chương trình ứng dụng.

Exam Tip Thủ tục được lưu trữ  (stored procedure) là một nhóm gồm một hoặc nhiều câu lệnh được lưu trữ trong cơ sở dữ liệu. Các thủ tục được lưu trữ được sử dụng trong các ngôn ngữ lập trình như SQL, Java, C ++ và C.

Obfuscation/Camouflage

Sự ngụy tạo (Obfuscation) hay ngụy trang (Camouflage) là sự che giấu ý nghĩa hiển nhiên khỏi sự quan sát. Mặc dù tính che đậy không được coi là bảo mật đầy đủ trong hầu hết các trường hợp, nhưng việc thêm tính năng che khuất hoặc ngụy trang vào hệ thống để khiến kẻ tấn công khó hiểu và khai thác hơn là một điều tốt. Đánh số các máy chủ e-mail của bạn email1, email2, email3 ,. . . cho kẻ tấn công biết không gian tên nào cần khám phá. Loại bỏ hoặc ẩn những gợi ý này làm cho công việc khó khăn hơn và cung cấp một lớp bảo vệ khác.

Điều này hoạt động tốt đối với tên dữ liệu và các phần tử tiếp xúc khác phải tiếp xúc với bên ngoài. Trường hợp điều này không hoạt động tốt là trong việc xây dựng mã. Mã bị xáo trộn, hoặc mã khó hoặc thậm chí gần như không thể đọc được, là một quả bom hẹn giờ tích cực. Sẽ đến ngày ai đó cần đọc mã, tìm ra cách hoạt động của nó để có thể sửa đổi hoặc xác định lý do tại sao nó không hoạt động. Nếu các lập trình viên gặp vấn đề khi đọc và hiểu mã, bao gồm cả cách nó hoạt động và những gì nó phải làm, thì làm thế nào họ có thể đóng góp vào việc bảo trì mã?

Code Reuse and Dead Code

Phát triển phần mềm hiện đại bao gồm việc tái sử dụng rộng rãi các thành phần. Từ các thư viện thành phần đến các chức năng chung trên nhiều thành phần, có cơ hội đáng kể để giảm chi phí phát triển thông qua việc tái sử dụng. Điều này cũng có thể đơn giản hóa một hệ thống thông qua việc tái sử dụng các phần tử đã biết. Mặt trái của việc tái sử dụng ồ ạt có liên quan đến môi trường độc canh (monoculture environment), đó là nơi mà sự thất bại có dấu ấn lớn hơn vì tất cả những nơi nó liên quan

Trong giai đoạn thiết kế, cần đưa ra các quyết định về mức độ tái sử dụng thích hợp. Đối với một số chức năng phức tạp, chẳng hạn như trong mật mã, sử dụng lại là cách ưu tiên. Trong các trường hợp khác, khi không thể thiết lập được dòng của một thành phần, rủi ro khi sử dụng có thể lớn hơn lợi ích. Ngoài ra, việc bao gồm mã trước đó, đôi khi được gọi là mã kế thừa (legacy code), có thể làm giảm các nỗ lực phát triển và rủi ro.

Exam Tip Việc sử dụng mã kế thừa trong các dự án hiện tại không loại trừ mã đó khỏi các đánh giá bảo mật. Tất cả mã phải nhận được sự giám sát giống nhau, đặc biệt là mã kế thừa có thể đã được phát triển trước khi áp dụng các quy trình vòng đời phát triển phần mềm (SDLC – software development lifecycle)

Xem bản đầy đủ trong sách in Comptia Security+ Tiếng Việt, kèm full mp3 bài trình bày và video eCourseware Comptia Security + bản quốc tế.

Thực hành với hướng dẫn chi tiếp step by step trên Comptia CertMaster Lab