Lưu ý
Cần có ủy quyền mới truy nhập được vào trang này. Bạn có thể thử đăng nhập hoặc thay đổi thư mục.
Cần có ủy quyền mới truy nhập được vào trang này. Bạn có thể thử thay đổi thư mục.
Áp dụng cho khuyến nghị về danh sách kiểm tra bảo mật được thiết kế tốt này: Power Platform
| SE:09 | Thiết lập chế độ thử nghiệm toàn diện kết hợp các phương pháp để ngăn ngừa các vấn đề bảo mật, xác thực việc triển khai phòng ngừa mối đe dọa và thử nghiệm các cơ chế phát hiện mối đe dọa. |
|---|
Kiểm tra nghiêm ngặt là nền tảng của thiết kế bảo mật tốt. Kiểm tra là một hình thức xác thực chiến thuật để đảm bảo các biện pháp kiểm soát hoạt động như mong muốn. Kiểm tra cũng là một cách chủ động để phát hiện lỗ hổng trong hệ thống.
Thiết lập tính nghiêm ngặt của thử nghiệm thông qua nhịp độ và xác minh từ nhiều góc độ. Bạn nên đưa vào các quan điểm từ trong ra ngoài để kiểm tra nền tảng và cơ sở hạ tầng cũng như các đánh giá từ ngoài vào trong để kiểm tra hệ thống như một kẻ tấn công bên ngoài.
Hướng dẫn này cung cấp các khuyến nghị để kiểm tra tình trạng bảo mật của khối lượng công việc của bạn. Triển khai các phương pháp thử nghiệm này để cải thiện khả năng chống lại các cuộc tấn công của khối lượng công việc và duy trì tính bảo mật, tính toàn vẹn và tính khả dụng của tài nguyên.
Định nghĩa
| Thuật ngữ | Định nghĩa |
|---|---|
| Kiểm tra bảo mật ứng dụng (AST) | Kỹ thuật Vòng đời phát triển bảo mật (SDL) của Microsoft sử dụng phương pháp thử nghiệm hộp trắng và hộp đen để kiểm tra lỗ hổng bảo mật trong mã. |
| Kiểm thử hộp đen | Một phương pháp thử nghiệm xác thực hành vi ứng dụng có thể nhìn thấy từ bên ngoài mà không cần biết đến các thành phần bên trong của hệ thống. |
| Đội xanh | Một đội phòng thủ chống lại các cuộc tấn công của đội đỏ trong một cuộc tập trận chiến tranh. |
| Kiểm tra thâm nhập | Một phương pháp thử nghiệm sử dụng các kỹ thuật hack có đạo đức để xác thực khả năng bảo mật của một hệ thống. |
| Đội đỏ | Một đội đóng vai kẻ thù và cố gắng hack hệ thống trong một cuộc tập trận chiến tranh. |
| Vòng đời phát triển bảo mật (SDL) | Một bộ thực hành do Microsoft cung cấp để hỗ trợ đảm bảo an ninh và các yêu cầu tuân thủ. |
| Vòng đời phát triển phần mềm (SDLC) | Một quy trình có hệ thống, nhiều giai đoạn để phát triển hệ thống phần mềm. |
| Kiểm thử hộp trắng | Một phương pháp thử nghiệm trong đó người thực hành biết được cấu trúc của mã. |
Các chiến lược thiết kế chính
Kiểm tra là một chiến lược không thể thương lượng, đặc biệt là về mặt bảo mật. Nó cho phép bạn chủ động phát hiện và giải quyết các vấn đề bảo mật trước khi chúng có thể bị khai thác và xác minh rằng các biện pháp kiểm soát bảo mật mà bạn triển khai đang hoạt động như thiết kế.
Phạm vi thử nghiệm phải bao gồm ứng dụng, cơ sở hạ tầng, quy trình tự động và quy trình của con người.
Lưu ý
Hướng dẫn này phân biệt giữa thử nghiệm và ứng phó sự cố. Mặc dù thử nghiệm là cơ chế phát hiện lý tưởng để khắc phục sự cố trước khi đưa vào sản xuất, nhưng không nên nhầm lẫn với hoạt động khắc phục hoặc điều tra được thực hiện như một phần của phản ứng sự cố. Góc độ phục hồi sau sự cố bảo mật được mô tả trong Khuyến nghị về ứng phó sự cố bảo mật.
Tham gia vào quá trình lập kế hoạch thử nghiệm. Nhóm quản lý khối lượng công việc có thể không thiết kế các trường hợp thử nghiệm. Nhiệm vụ đó thường được tập trung trong doanh nghiệp hoặc được thực hiện bởi các chuyên gia bảo mật bên ngoài. Nhóm khối lượng công việc phải tham gia vào quá trình thiết kế đó để đảm bảo rằng các đảm bảo bảo mật được tích hợp với chức năng của ứng dụng.
Hãy suy nghĩ như một kẻ tấn công. Thiết kế các trường hợp thử nghiệm với giả định rằng hệ thống đã bị tấn công. Bằng cách đó, bạn có thể phát hiện ra các lỗ hổng tiềm ẩn và ưu tiên các bài kiểm tra cho phù hợp.
Tiến hành thử nghiệm theo cách có cấu trúc và theo quy trình có thể lặp lại. Xây dựng mức độ nghiêm ngặt trong thử nghiệm dựa trên nhịp độ, loại thử nghiệm, yếu tố thúc đẩy và kết quả mong muốn.
Sử dụng đúng công cụ cho công việc. Sử dụng các công cụ được cấu hình để làm việc với khối lượng công việc. Nếu bạn không có dụng cụ, hãy mua dụng cụ đó. Đừng xây nó. Các công cụ bảo mật có tính chuyên môn cao và việc tự xây dựng công cụ có thể gây ra rủi ro. Tận dụng chuyên môn và công cụ do nhóm SecOps trung tâm cung cấp hoặc thông qua các phương tiện bên ngoài nếu nhóm xử lý khối lượng công việc không có chuyên môn đó.
Thiết lập các môi trường riêng biệt. Các bài kiểm tra có thể được phân loại thành bài kiểm tra phá hủy hoặc bài kiểm tra không phá hủy. Các xét nghiệm không phá hủy không xâm lấn. Chúng chỉ ra rằng có vấn đề, nhưng không thay đổi chức năng để khắc phục vấn đề. Các thử nghiệm phá hủy mang tính xâm lấn và có thể làm hỏng chức năng bằng cách xóa dữ liệu khỏi cơ sở dữ liệu.
Kiểm thử trong môi trường sản xuất cung cấp cho bạn thông tin tốt nhất nhưng cũng gây ra nhiều gián đoạn nhất. Bạn có xu hướng chỉ thực hiện các thử nghiệm không phá hủy trong môi trường sản xuất. Việc thử nghiệm trong môi trường không phải môi trường sản xuất thường ít gây gián đoạn hơn nhưng có thể không thể hiện chính xác cấu hình của môi trường sản xuất theo cách quan trọng đối với bảo mật.
Bạn có thể tạo bản sao riêng biệt của môi trường sản xuất bằng cách sử dụng tính năng sao chép môi trường . Nếu bạn đã thiết lập quy trình triển khai, bạn cũng có thể triển khai các giải pháp của mình vào môi trường thử nghiệm chuyên dụng.
Luôn đánh giá kết quả thử nghiệm. Kiểm tra sẽ là một nỗ lực lãng phí nếu kết quả không được sử dụng để ưu tiên hành động và cải thiện trước đó. Ghi lại các hướng dẫn bảo mật, bao gồm các biện pháp tốt nhất mà bạn khám phá được. Tài liệu ghi lại kết quả và kế hoạch khắc phục sẽ giúp nhóm hiểu rõ hơn về những cách mà kẻ tấn công có thể sử dụng để xâm phạm bảo mật. Tiến hành đào tạo bảo mật thường xuyên cho các nhà phát triển, quản trị viên và người thử nghiệm.
Khi thiết kế kế hoạch kiểm tra, hãy nghĩ đến những câu hỏi sau:
- Bạn dự kiến thử nghiệm sẽ diễn ra thường xuyên như thế nào và nó ảnh hưởng đến môi trường của bạn như thế nào?
- Có những loại thử nghiệm nào mà bạn nên chạy?
Bạn mong đợi các bài kiểm tra sẽ được thực hiện thường xuyên như thế nào?
Kiểm tra khối lượng công việc thường xuyên để đảm bảo những thay đổi không gây ra rủi ro bảo mật và không có bất kỳ sự thoái triển nào. Nhóm cũng phải sẵn sàng phản hồi các xác thực bảo mật của tổ chức có thể được thực hiện bất cứ lúc nào. Ngoài ra còn có các bài kiểm tra mà bạn có thể chạy để ứng phó với sự cố bảo mật. Các phần sau đây đưa ra khuyến nghị về tần suất kiểm tra.
Xét nghiệm thường quy
Các xét nghiệm thường quy được tiến hành theo nhịp độ đều đặn, như một phần trong quy trình vận hành tiêu chuẩn của bạn và để đáp ứng các yêu cầu tuân thủ. Nhiều bài kiểm tra có thể được tiến hành ở các tần suất khác nhau, nhưng điều quan trọng là chúng phải được tiến hành định kỳ và theo lịch trình.
Bạn nên tích hợp các bài kiểm tra này vào SDLC của mình vì chúng cung cấp biện pháp phòng thủ chuyên sâu ở từng giai đoạn. Đa dạng hóa bộ kiểm tra để xác minh các đảm bảo về danh tính, lưu trữ và truyền dữ liệu cũng như kênh truyền thông. Tiến hành các thử nghiệm giống nhau tại các thời điểm khác nhau trong vòng đời để đảm bảo không có bất kỳ sự thoái triển nào. Các xét nghiệm thường quy giúp thiết lập chuẩn mực ban đầu. Tuy nhiên đó chỉ là điểm khởi đầu. Khi bạn phát hiện ra các vấn đề mới tại cùng một thời điểm trong vòng đời, bạn sẽ thêm các trường hợp thử nghiệm mới. Các bài kiểm tra cũng được cải thiện khi lặp lại nhiều lần.
Ở mỗi giai đoạn, các thử nghiệm này sẽ xác thực mã được thêm vào hoặc xóa đi hoặc các thiết lập cấu hình đã thay đổi để phát hiện tác động bảo mật của những thay đổi đó. Bạn nên cải thiện hiệu quả của các bài kiểm tra bằng cách tự động hóa, cân bằng với đánh giá ngang hàng.
Hãy cân nhắc việc chạy thử nghiệm bảo mật như một phần của quy trình tự động hoặc chạy thử nghiệm theo lịch trình. Bạn phát hiện ra các vấn đề bảo mật càng sớm thì việc tìm ra mã hoặc thay đổi cấu hình gây ra chúng càng dễ dàng.
Đừng chỉ dựa vào các bài kiểm tra tự động. Sử dụng thử nghiệm thủ công để phát hiện các lỗ hổng mà chỉ có chuyên môn của con người mới có thể phát hiện được. Kiểm thử thủ công có hiệu quả trong các trường hợp sử dụng mang tính khám phá và tìm ra những rủi ro chưa biết.
Bài kiểm tra ứng biến
Các bài kiểm tra ngẫu hứng cung cấp khả năng xác thực tại thời điểm cụ thể về biện pháp phòng thủ an ninh. Các cảnh báo bảo mật có thể ảnh hưởng đến khối lượng công việc tại thời điểm đó sẽ kích hoạt các thử nghiệm này. Nhiệm vụ của tổ chức có thể yêu cầu tư duy tạm dừng và thử nghiệm để xác minh tính hiệu quả của các chiến lược phòng thủ nếu cảnh báo trở thành trường hợp khẩn cấp.
Lợi ích của các bài kiểm tra ứng biến là sự chuẩn bị cho một sự cố thực sự. Những thử nghiệm này có thể là chức năng bắt buộc để thực hiện thử nghiệm chấp nhận của người dùng (UAT).
Nhóm bảo mật có thể kiểm tra tất cả khối lượng công việc và chạy các thử nghiệm này khi cần thiết. Là người quản lý khối lượng công việc, bạn cần tạo điều kiện thuận lợi và cộng tác với các nhóm bảo mật. Đàm phán về thời gian chuẩn bị với nhóm an ninh để bạn có thể chuẩn bị. Xác nhận và truyền đạt cho nhóm và các bên liên quan của bạn rằng những gián đoạn này là cần thiết.
Trong những trường hợp khác, bạn có thể được yêu cầu chạy thử nghiệm và báo cáo trạng thái bảo mật của hệ thống trước mối đe dọa tiềm ẩn.
Đánh đổi: Vì các bài kiểm tra ngẫu hứng là những sự kiện gây gián đoạn, nên cần phải sắp xếp lại thứ tự ưu tiên các nhiệm vụ, điều này có thể làm chậm trễ các công việc đã lên kế hoạch khác.
Rủi ro: Có rủi ro từ những điều chưa biết. Các bài kiểm tra ngẫu hứng có thể là những nỗ lực thực hiện một lần mà không có quy trình hoặc công cụ đã được thiết lập. Nhưng rủi ro lớn nhất là khả năng gián đoạn nhịp độ kinh doanh. Bạn cần đánh giá những rủi ro đó so với lợi ích.
Kiểm tra sự cố bảo mật
Có những bài kiểm tra có thể phát hiện nguyên nhân của sự cố bảo mật ngay từ gốc rễ. Những lỗ hổng bảo mật này phải được giải quyết để đảm bảo sự cố không tái diễn.
Các sự cố cũng cải thiện các trường hợp thử nghiệm theo thời gian bằng cách phát hiện ra những lỗ hổng hiện có. Nhóm nên áp dụng những bài học kinh nghiệm từ sự cố này và thường xuyên đưa ra những cải tiến.
Có những loại xét nghiệm nào?
Các bài kiểm tra có thể được phân loại theo công nghệ và theo phương pháp kiểm tra. Kết hợp các danh mục và phương pháp đó trong các danh mục đó để có được phạm vi bao phủ toàn diện.
Bằng cách thêm nhiều bài kiểm tra và loại bài kiểm tra, bạn có thể khám phá ra:
- Khoảng trống trong các biện pháp kiểm soát an ninh hoặc biện pháp kiểm soát bù trừ.
- Cấu hình sai.
- Khoảng cách trong phương pháp quan sát và phát hiện.
Bài tập mô hình hóa mối đe dọa tốt có thể chỉ ra các lĩnh vực chính để đảm bảo phạm vi và tần suất thử nghiệm. Để biết các khuyến nghị về mô hình hóa mối đe dọa, hãy xem Khuyến nghị để bảo mật vòng đời phát triển.
Hầu hết các thử nghiệm được mô tả trong các phần này có thể được thực hiện như các thử nghiệm thường quy. Tuy nhiên, khả năng lặp lại có thể gây ra chi phí trong một số trường hợp và gây gián đoạn. Hãy cân nhắc kỹ lưỡng những sự đánh đổi đó.
Các bài kiểm tra xác thực công nghệ
Sau đây là một số ví dụ về các loại bài kiểm tra và lĩnh vực trọng tâm của chúng. Danh sách này không đầy đủ. Kiểm tra toàn bộ ngăn xếp, bao gồm ngăn xếp ứng dụng, giao diện người dùng, giao diện quản trị, API, cơ sở dữ liệu và mọi tích hợp bên ngoài.
- Bảo mật dữ liệu: Kiểm tra hiệu quả của mã hóa dữ liệu và kiểm soát truy cập để đảm bảo dữ liệu được bảo vệ đúng cách khỏi truy cập trái phép và giả mạo.
- Mạng và kết nối: Kiểm tra tường lửa của bạn để đảm bảo chúng chỉ cho phép lưu lượng truy cập mong đợi, được phép và an toàn vào khối lượng công việc.
- Ứng dụng: Kiểm tra mã nguồn thông qua các kỹ thuật kiểm tra bảo mật ứng dụng (AST) để đảm bảo rằng bạn tuân theo các thông lệ mã hóa an toàn và phát hiện các lỗi thời gian chạy như lỗi bộ nhớ và các vấn đề về đặc quyền.
- Nhận dạng: Đánh giá xem các nhiệm vụ vai trò và kiểm tra có điều kiện có hoạt động như mong đợi hay không.
Phương pháp thử nghiệm
Có nhiều quan điểm về phương pháp thử nghiệm. Chúng tôi khuyên bạn nên thử nghiệm để có thể săn tìm mối đe dọa bằng cách mô phỏng các cuộc tấn công trong thế giới thực. Họ có thể xác định những tác nhân đe dọa tiềm ẩn, kỹ thuật của chúng và các hành vi khai thác gây ra mối đe dọa cho khối lượng công việc. Làm cho các cuộc tấn công trở nên chân thực nhất có thể. Sử dụng tất cả các vectơ đe dọa tiềm ẩn mà bạn xác định được trong quá trình lập mô hình đe dọa.
Sau đây là một số lợi ích của việc thử nghiệm thông qua các cuộc tấn công thực tế:
- Khi bạn thực hiện các cuộc tấn công này như một phần của quá trình thử nghiệm thường xuyên, bạn sử dụng góc nhìn từ ngoài vào trong để kiểm tra khối lượng công việc và đảm bảo rằng hệ thống phòng thủ có thể chống lại được cuộc tấn công.
- Dựa trên những bài học đã học được, nhóm sẽ nâng cao kiến thức và kỹ năng của mình. Nhóm cải thiện nhận thức tình huống và có thể tự đánh giá mức độ sẵn sàng ứng phó với các sự cố.
Một số ví dụ về thử nghiệm mô phỏng bao gồm thử nghiệm hộp đen và hộp trắng, thử nghiệm xâm nhập và bài tập mô phỏng chiến tranh.
Kiểm thử hộp đen và hộp trắng
Các loại bài kiểm tra này cung cấp hai góc nhìn khác nhau. Trong các thử nghiệm hộp đen, các thành phần bên trong của hệ thống không thể nhìn thấy được. Trong các thử nghiệm hộp trắng, người thử nghiệm có hiểu biết tốt về ứng dụng và thậm chí có quyền truy cập vào mã, nhật ký, cấu trúc tài nguyên và cấu hình để tiến hành thử nghiệm.
Các bài kiểm tra mô phỏng các cuộc tấn công thông qua thử nghiệm thâm nhập
Các chuyên gia bảo mật không thuộc nhóm CNTT hoặc nhóm ứng dụng của tổ chức sẽ tiến hành thử nghiệm xâm nhập hoặc kiểm tra thâm nhập. Họ xem xét hệ thống theo cách mà kẻ xấu xác định phạm vi bề mặt tấn công. Mục tiêu của họ là tìm ra lỗ hổng bảo mật bằng cách thu thập thông tin, phân tích lỗ hổng và báo cáo kết quả.
Các học viên có thể cần truy cập vào dữ liệu nhạy cảm trong toàn bộ tổ chức. Thực hiện theo các quy tắc tương tác để đảm bảo quyền truy cập không bị sử dụng sai mục đích. Xem các tài nguyên được liệt kê trong Thông tin liên quan.
Các bài kiểm tra mô phỏng các cuộc tấn công thông qua các bài tập trò chơi chiến tranh
Trong phương pháp tấn công mô phỏng này, có hai đội:
- Các màu đỏ đội là đối thủ đang cố gắng mô phỏng các cuộc tấn công trong thế giới thực. Nếu thành công, bạn sẽ tìm ra lỗ hổng trong thiết kế bảo mật và đánh giá phạm vi bao phủ của vụ nổ tại các điểm vi phạm.
- Các màu xanh da trời nhóm là nhóm chịu trách nhiệm bảo vệ chống lại các cuộc tấn công. Họ kiểm tra khả năng phát hiện, phản ứng và khắc phục các cuộc tấn công. Họ xác thực các biện pháp phòng thủ đã được triển khai để bảo vệ tài nguyên khối lượng công việc.
Nếu được tiến hành như các cuộc thử nghiệm thường lệ, các cuộc tập trận chiến tranh có thể cung cấp khả năng quan sát liên tục và đảm bảo rằng hệ thống phòng thủ của bạn hoạt động đúng như thiết kế. Các bài tập chiến tranh có khả năng kiểm tra nhiều cấp độ trong khối lượng công việc của bạn.
Một lựa chọn phổ biến để mô phỏng các tình huống tấn công thực tế là Microsoft Defender để đào tạo mô phỏng tấn công Office 365 .
Để biết thêm thông tin, hãy xem Thông tin chi tiết và báo cáo về đào tạo mô phỏng tấn công.
Để biết thông tin về thiết lập nhóm đỏ và nhóm xanh, hãy xem Microsoft Cloud Red Teaming.
Power Platform sự tạo điều kiện thuận lợi
Giải pháp Microsoft Sentinel cho phép khách hàng phát hiện nhiều hoạt động đáng ngờ, chẳng hạn như: Microsoft Power Platform
- Power Apps thực hiện từ các địa lý trái phép
- Việc phá hủy dữ liệu đáng ngờ bởi Power Apps
- Xóa hàng loạt Power Apps
- Các cuộc tấn công lừa đảo được thực hiện thông qua Power Apps
- Power Automate hoạt động dòng chảy của nhân viên rời đi
- Microsoft Power Platform các kết nối được thêm vào môi trường
- Cập nhật hoặc xóa chính sách dữ liệu Microsoft Power Platform
Để biết thêm thông tin, hãy xem giải pháp Microsoft Sentinel để biết Microsoft Power Platform tổng quan.
Để biết tài liệu về sản phẩm, hãy xem Khả năng săn tìm trong Microsoft Sentinel.
Microsoft Defender for Cloud cung cấp tính năng quét lỗ hổng cho nhiều lĩnh vực công nghệ khác nhau. Để biết thêm thông tin, hãy xem Bật chức năng quét lỗ hổng bảo mật bằng Microsoft Defender Vulnerability Management.
Thực hành DevSecOps tích hợp thử nghiệm bảo mật như một phần của tư duy cải tiến liên tục và liên tục. Các bài tập chiến tranh là hoạt động thường xuyên được lồng ghép vào nhịp độ kinh doanh tại Microsoft. Để biết thêm thông tin, hãy xem Bảo mật trong DevOps (DevSecOps).
Azure DevOps hỗ trợ các công cụ của bên thứ ba có thể được tự động hóa như một phần của quy trình tích hợp liên tục/triển khai liên tục (CI/CD). Để biết thêm thông tin, hãy xem Bật DevSecOps với Azure và GitHub.
Thông tin liên quan
Bạn có thể tìm thấy các bài kiểm thử xâm nhập và đánh giá hoạt động bảo mật mới nhất trên Microsoft Service Trust Portal.
Microsoft thực hiện thử nghiệm rộng rãi các dịch vụ Microsoft Cloud. Kiểm tra này bao gồm kiểm tra thâm nhập, với kết quả được công bố trên Cổng thông tin Service Trust cho tổ chức của bạn. Tổ chức của bạn có thể tự thực hiện thử nghiệm thâm nhập trên Microsoft Power Platform và Microsoft Dynamics các dịch vụ 365. Mọi hoạt động kiểm tra thâm nhập phải tuân theo Quy tắc tham gia kiểm tra thâm nhập đám mây của Microsoft. Điều quan trọng cần nhớ là trong nhiều trường hợp, Microsoft Cloud sử dụng cơ sở hạ tầng dùng chung để lưu trữ tài sản của bạn và tài sản thuộc về khách hàng khác. Bạn phải giới hạn mọi cuộc kiểm tra thâm nhập vào tài sản của mình và tránh những hậu quả không mong muốn cho những khách hàng khác xung quanh bạn.
Thực hiện theo các quy tắc tương tác để đảm bảo quyền truy cập không bị sử dụng sai mục đích. Tìm hiểu thêm về cách lập kế hoạch và thực hiện các cuộc tấn công mô phỏng:
Bạn có thể mô phỏng các cuộc tấn công từ chối dịch vụ (DoS) trong Azure. Hãy đảm bảo tuân thủ các chính sách được nêu trong thử nghiệm mô phỏng Azure DDoS Protection.
Danh sách kiểm tra an ninh
Tham khảo bộ khuyến nghị đầy đủ.