Bài viết này là bài thứ ba trong loạt bài “Cách kiểm soát cơ sở hạ tầng mạng của bạn”. Nội dung của tất cả các bài viết trong chuỗi và các liên kết có thể được tìm thấy .
Không có ích gì khi nói về việc loại bỏ hoàn toàn các rủi ro bảo mật. Về nguyên tắc, chúng ta không thể giảm chúng về XNUMX. Chúng ta cũng cần hiểu rằng khi chúng ta cố gắng làm cho mạng ngày càng an toàn hơn thì các giải pháp của chúng ta ngày càng trở nên đắt đỏ hơn. Bạn cần tìm sự cân bằng giữa chi phí, độ phức tạp và tính bảo mật phù hợp với mạng của bạn.
Tất nhiên, thiết kế bảo mật được tích hợp một cách hữu cơ vào kiến trúc tổng thể và các giải pháp bảo mật được sử dụng sẽ ảnh hưởng đến khả năng mở rộng, độ tin cậy, khả năng quản lý, ... của cơ sở hạ tầng mạng, điều này cũng cần được tính đến.
Nhưng hãy để tôi nhắc bạn rằng bây giờ chúng ta không nói về việc tạo ra một mạng lưới. Theo chúng tôi chúng ta đã chọn thiết kế, chọn thiết bị, tạo cơ sở hạ tầng, ở giai đoạn này, nếu có thể, chúng ta nên “sống” và tìm giải pháp trong bối cảnh cách tiếp cận đã chọn trước đó.
Nhiệm vụ của chúng tôi bây giờ là xác định các rủi ro liên quan đến bảo mật ở cấp độ mạng và giảm chúng xuống mức hợp lý.
Kiểm toán an ninh mạng
Nếu tổ chức của bạn đã triển khai các quy trình ISO 27k thì việc kiểm tra bảo mật và thay đổi mạng sẽ hoàn toàn phù hợp với các quy trình tổng thể trong phương pháp này. Nhưng những tiêu chuẩn này vẫn không phải về các giải pháp cụ thể, không phải về cấu hình, không phải về thiết kế... Không có lời khuyên rõ ràng, không có tiêu chuẩn nào quy định chi tiết mạng của bạn phải như thế nào, đây chính là sự phức tạp và vẻ đẹp của nhiệm vụ này.
Tôi sẽ nêu bật một số cuộc kiểm tra an ninh mạng có thể thực hiện được:
- kiểm tra cấu hình thiết bị (làm cứng)
- kiểm toán thiết kế bảo mật
- kiểm tra truy cập
- Kiểm toán quá trình
Kiểm tra cấu hình thiết bị (tăng cường)
Có vẻ như trong hầu hết các trường hợp, đây là điểm khởi đầu tốt nhất để kiểm tra và cải thiện tính bảo mật cho mạng của bạn. IMHO, đây là một minh chứng tốt cho định luật Pareto (20% nỗ lực tạo ra 80% kết quả và 80% nỗ lực còn lại chỉ tạo ra 20% kết quả).
Điểm mấu chốt là chúng tôi thường nhận được đề xuất từ các nhà cung cấp về “các biện pháp thực hành tốt nhất” để bảo mật khi định cấu hình thiết bị. Điều này được gọi là “làm cứng”.
Bạn cũng có thể thường xuyên tìm thấy một bảng câu hỏi (hoặc tự tạo một bảng câu hỏi) dựa trên những đề xuất này. Bảng câu hỏi này sẽ giúp bạn xác định xem cấu hình thiết bị của bạn tuân thủ các “phương pháp hay nhất” này đến mức nào và thực hiện các thay đổi trong mạng của bạn theo kết quả . Điều này sẽ cho phép bạn giảm đáng kể rủi ro bảo mật khá dễ dàng mà hầu như không mất phí.
Một số ví dụ về một số hệ điều hành của Cisco.
Dựa trên các tài liệu này, có thể tạo ra danh sách các yêu cầu cấu hình cho từng loại thiết bị. Ví dụ: đối với Cisco N7K VDC, các yêu cầu này có thể giống như .
Bằng cách này, các tệp cấu hình có thể được tạo cho các loại thiết bị hoạt động khác nhau trong cơ sở hạ tầng mạng của bạn. Tiếp theo, bằng cách thủ công hoặc sử dụng tự động hóa, bạn có thể “tải” các tệp cấu hình này lên. Cách tự động hóa quy trình này sẽ được thảo luận chi tiết trong một loạt bài viết khác về điều phối và tự động hóa.
Kiểm toán thiết kế bảo mật
Thông thường, mạng doanh nghiệp chứa các phân đoạn sau ở dạng này hay dạng khác:
- DC (Trung tâm dữ liệu mạng nội bộ và DMZ dịch vụ công cộng)
- Truy cập internet
- VPN truy cập từ xa
- Biên mạng WAN
- Chi nhánh
- Khuôn viên (Văn phòng)
- Trung tâm
Tiêu đề được lấy từ mô hình, nhưng tất nhiên là không cần thiết phải gắn chính xác với những cái tên này và mô hình này. Tuy nhiên, tôi muốn nói về bản chất và không bị sa lầy vào hình thức.
Đối với mỗi phân khúc này, các yêu cầu bảo mật, rủi ro và theo đó, các giải pháp sẽ khác nhau.
Chúng ta hãy xem xét riêng từng vấn đề mà bạn có thể gặp phải từ quan điểm thiết kế bảo mật. Tất nhiên, tôi nhắc lại một lần nữa rằng bài viết này không hề giả vờ hoàn chỉnh, điều này không dễ (nếu không nói là không thể) đạt được trong chủ đề thực sự sâu sắc và nhiều mặt này, nhưng nó phản ánh kinh nghiệm cá nhân của tôi.
Không có giải pháp hoàn hảo (ít nhất là chưa). Nó luôn luôn là một sự thỏa hiệp. Nhưng điều quan trọng là quyết định sử dụng cách tiếp cận này hay cách tiếp cận khác phải được đưa ra một cách có ý thức, với sự hiểu biết về cả ưu và nhược điểm của nó.
Trung tâm dữ liệu
Phân khúc quan trọng nhất xét theo quan điểm an toàn.
Và, như thường lệ, cũng không có giải pháp chung nào ở đây. Tất cả phụ thuộc rất nhiều vào yêu cầu mạng.
Tường lửa có cần thiết hay không?
Có vẻ như câu trả lời là hiển nhiên, nhưng mọi thứ không hoàn toàn rõ ràng như người ta tưởng. Và sự lựa chọn của bạn có thể bị ảnh hưởng không chỉ giá.
Ví dụ 1. Sự chậm trễ.
Nếu độ trễ thấp là yêu cầu thiết yếu giữa một số phân đoạn mạng, chẳng hạn như đúng trong trường hợp trao đổi, thì chúng tôi sẽ không thể sử dụng tường lửa giữa các phân đoạn này. Thật khó để tìm thấy các nghiên cứu về độ trễ trong tường lửa, nhưng một số mô hình chuyển mạch có thể cung cấp độ trễ nhỏ hơn hoặc ở mức 1 mksec, vì vậy tôi nghĩ nếu micro giây là quan trọng đối với bạn thì tường lửa không dành cho bạn.
Ví dụ 2. Hiệu suất.
Thông lượng của các thiết bị chuyển mạch L3 hàng đầu thường cao hơn thông lượng của các tường lửa mạnh nhất. Do đó, trong trường hợp lưu lượng truy cập có cường độ cao, rất có thể bạn cũng sẽ phải cho phép lưu lượng truy cập này vượt qua tường lửa.
Ví dụ 3. Độ tin cậy.
Tường lửa, đặc biệt là NGFW (FW thế hệ tiếp theo) hiện đại là những thiết bị phức tạp. Chúng phức tạp hơn nhiều so với các switch L3/L2. Họ cung cấp một số lượng lớn các dịch vụ và tùy chọn cấu hình, vì vậy không có gì đáng ngạc nhiên khi độ tin cậy của chúng thấp hơn nhiều. Nếu tính liên tục của dịch vụ là quan trọng đối với mạng thì bạn có thể phải chọn điều gì sẽ dẫn đến tính sẵn sàng tốt hơn - bảo mật bằng tường lửa hoặc sự đơn giản của mạng được xây dựng trên bộ chuyển mạch (hoặc các loại kết cấu khác nhau) bằng cách sử dụng ACL thông thường.
Trong trường hợp của các ví dụ trên, rất có thể (như thường lệ) bạn sẽ phải tìm cách thỏa hiệp. Hướng tới các giải pháp sau:
- nếu bạn quyết định không sử dụng tường lửa bên trong trung tâm dữ liệu, thì bạn cần nghĩ đến cách hạn chế quyền truy cập xung quanh chu vi càng nhiều càng tốt. Ví dụ: bạn chỉ có thể mở các cổng cần thiết từ Internet (dành cho lưu lượng khách) và quyền truy cập quản trị vào trung tâm dữ liệu chỉ từ máy chủ nhảy. Trên máy chủ nhảy, thực hiện tất cả các kiểm tra cần thiết (xác thực/ủy quyền, chống vi-rút, ghi nhật ký, ...)
- bạn có thể sử dụng phân vùng logic của mạng trung tâm dữ liệu thành các phân đoạn, tương tự như sơ đồ được mô tả trong PSEFABRIC . Trong trường hợp này, việc định tuyến phải được cấu hình sao cho lưu lượng truy cập nhạy cảm với độ trễ hoặc cường độ cao đi “trong” một phân đoạn (trong trường hợp p002, VRF) và không đi qua tường lửa. Lưu lượng giữa các phân đoạn khác nhau sẽ tiếp tục đi qua tường lửa. Bạn cũng có thể sử dụng rò rỉ tuyến đường giữa các VRF để tránh chuyển hướng lưu lượng truy cập qua tường lửa
- Bạn cũng có thể sử dụng tường lửa ở chế độ trong suốt và chỉ dành cho những Vlan mà các yếu tố này (độ trễ/hiệu suất) không đáng kể. Nhưng bạn cần nghiên cứu kỹ các hạn chế liên quan đến việc sử dụng mod này đối với từng nhà cung cấp.
- bạn có thể muốn xem xét sử dụng kiến trúc chuỗi dịch vụ. Điều này sẽ chỉ cho phép lưu lượng truy cập cần thiết đi qua tường lửa. Về mặt lý thuyết thì có vẻ hay, nhưng tôi chưa bao giờ thấy giải pháp này trong sản xuất. Chúng tôi đã thử nghiệm chuỗi dịch vụ cho Cisco ACI/Juniper SRX/F5 LTM khoảng 3 năm trước, nhưng vào thời điểm đó, giải pháp này có vẻ “thô thiển” đối với chúng tôi.
Mức độ bảo vệ
Bây giờ bạn cần trả lời câu hỏi bạn muốn sử dụng công cụ nào để lọc lưu lượng truy cập. Dưới đây là một số tính năng thường có trong NGFW (ví dụ: ):
- tường lửa trạng thái (mặc định)
- tường lửa ứng dụng
- ngăn chặn mối đe dọa (chống vi-rút, chống phần mềm gián điệp và lỗ hổng)
- Lọc URL
- lọc dữ liệu (lọc nội dung)
- chặn tập tin (chặn loại tập tin)
- bảo vệ dos
Và không phải mọi thứ đều rõ ràng. Có vẻ như mức độ bảo vệ càng cao thì càng tốt. Nhưng bạn cũng cần cân nhắc điều đó
- Bạn càng sử dụng nhiều chức năng tường lửa ở trên thì đương nhiên giá thành sẽ càng đắt (giấy phép, mô-đun bổ sung)
- việc sử dụng một số thuật toán có thể làm giảm đáng kể thông lượng tường lửa và cũng làm tăng độ trễ, xem ví dụ
- Giống như bất kỳ giải pháp phức tạp nào, việc sử dụng các phương pháp bảo vệ phức tạp có thể làm giảm độ tin cậy của giải pháp của bạn, ví dụ: khi sử dụng tường lửa ứng dụng, tôi gặp phải tình trạng chặn một số ứng dụng hoạt động khá chuẩn (dns, smb)
Như mọi khi, bạn cần tìm giải pháp tốt nhất cho mạng của mình.
Không thể trả lời dứt khoát câu hỏi những chức năng bảo vệ nào có thể được yêu cầu. Thứ nhất, vì tất nhiên nó phụ thuộc vào dữ liệu bạn đang truyền hoặc lưu trữ và cố gắng bảo vệ. Thứ hai, trên thực tế, việc lựa chọn công cụ bảo mật thường là vấn đề niềm tin và sự tin tưởng vào nhà cung cấp. Bạn không biết các thuật toán, bạn không biết chúng hiệu quả như thế nào và bạn không thể kiểm tra chúng một cách đầy đủ.
Vì vậy, ở những phân khúc quan trọng, giải pháp tốt có thể là sử dụng các ưu đãi từ các công ty khác nhau. Ví dụ: bạn có thể bật tính năng chống vi-rút trên tường lửa nhưng cũng có thể sử dụng tính năng bảo vệ chống vi-rút (từ nhà sản xuất khác) cục bộ trên máy chủ.
Phân đoạn
Chúng ta đang nói về sự phân chia hợp lý của mạng trung tâm dữ liệu. Ví dụ: phân vùng thành Vlan và mạng con cũng là phân đoạn hợp lý, nhưng chúng tôi sẽ không xem xét nó do tính rõ ràng của nó. Phân đoạn thú vị có tính đến các thực thể như vùng bảo mật FW, VRF (và các chất tương tự của chúng liên quan đến các nhà cung cấp khác nhau), thiết bị logic (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Một ví dụ về phân đoạn logic như vậy và thiết kế trung tâm dữ liệu hiện đang có nhu cầu được đưa ra trong .
Sau khi xác định các phần logic của mạng, bạn có thể mô tả cách lưu lượng truy cập di chuyển giữa các phân đoạn khác nhau, bộ lọc sẽ được thực hiện trên thiết bị nào và bằng phương tiện gì.
Nếu mạng của bạn không có phân vùng logic rõ ràng và các quy tắc áp dụng chính sách bảo mật cho các luồng dữ liệu khác nhau không được chính thức hóa, điều này có nghĩa là khi bạn mở quyền truy cập này hoặc quyền truy cập kia, bạn buộc phải giải quyết vấn đề này và khả năng cao là bạn sẽ giải quyết nó mỗi lần một cách khác nhau.
Thông thường việc phân đoạn chỉ dựa trên các vùng bảo mật FW. Sau đó, bạn cần trả lời các câu hỏi sau:
- bạn cần khu vực bảo mật nào
- bạn muốn áp dụng mức độ bảo vệ nào cho từng vùng này
- Theo mặc định, lưu lượng truy cập trong khu vực có được phép không?
- nếu không thì chính sách lọc lưu lượng nào sẽ được áp dụng trong từng vùng
- chính sách lọc lưu lượng nào sẽ được áp dụng cho từng cặp vùng (nguồn/đích)
TCAM
Một vấn đề phổ biến là không đủ TCAM (Bộ nhớ có thể định địa chỉ nội dung thứ ba), cả để định tuyến và truy cập. IMHO, đây là một trong những vấn đề quan trọng nhất khi lựa chọn thiết bị, vì vậy bạn cần xử lý vấn đề này với mức độ quan tâm thích hợp.
Ví dụ 1. Bảng chuyển tiếp TCAM.
Hãy xem xét bức tường lửa
Chúng tôi thấy rằng kích thước bảng chuyển tiếp IPv4* = 32K
Hơn nữa, số lượng tuyến đường này là chung cho tất cả các VSYS.Giả sử rằng theo thiết kế của bạn, bạn quyết định sử dụng 4 VSYS.
Mỗi VSYS này được kết nối qua BGP với hai MPLS PE của đám mây mà bạn sử dụng làm BB. Do đó, 4 VSYS trao đổi tất cả các tuyến cụ thể với nhau và có một bảng chuyển tiếp với các bộ tuyến gần giống nhau (nhưng NH khác nhau). Bởi vì mỗi VSYS có 2 phiên BGP (có cùng cài đặt), sau đó mỗi tuyến nhận được qua MPLS có 2 NH và theo đó, 2 mục FIB trong Bảng chuyển tiếp. Nếu chúng tôi giả định rằng đây là tường lửa duy nhất trong trung tâm dữ liệu và nó phải biết về tất cả các tuyến, thì điều này có nghĩa là tổng số tuyến trong trung tâm dữ liệu của chúng tôi không thể nhiều hơn 32K/(4 * 2) = 4K.Bây giờ, nếu giả sử rằng chúng ta có 2 trung tâm dữ liệu (có cùng thiết kế) và chúng ta muốn sử dụng các Vlan “kéo dài” giữa các trung tâm dữ liệu (ví dụ: đối với vMotion), thì để giải quyết vấn đề định tuyến, chúng ta phải sử dụng các tuyến máy chủ . Nhưng điều này có nghĩa là đối với 2 trung tâm dữ liệu, chúng tôi sẽ có không quá 4096 máy chủ khả thi và tất nhiên, điều này có thể là không đủ.
Ví dụ 2. ACL TCAM.
Nếu bạn định lọc lưu lượng trên bộ chuyển mạch L3 (hoặc các giải pháp khác sử dụng bộ chuyển mạch L3, chẳng hạn như Cisco ACI), thì khi chọn thiết bị, bạn nên chú ý đến TCAM ACL.
Giả sử bạn muốn kiểm soát quyền truy cập trên giao diện SVI của Cisco Catalyst 4500. Sau đó, như có thể thấy từ , để kiểm soát lưu lượng đi (cũng như đến) trên các giao diện, bạn chỉ có thể sử dụng 4096 dòng TCAM. Mà khi sử dụng TCAM3 sẽ cho bạn khoảng 4000 nghìn ACE (dòng ACL).
Nếu bạn đang phải đối mặt với vấn đề TCAM không đủ, thì trước hết, tất nhiên, bạn cần xem xét khả năng tối ưu hóa. Vì vậy, trong trường hợp có vấn đề về kích thước của Bảng chuyển tiếp, bạn cần xem xét khả năng tổng hợp các tuyến đường. Trong trường hợp có vấn đề với kích thước TCAM đối với quyền truy cập, hãy kiểm tra quyền truy cập, xóa các bản ghi lỗi thời và chồng chéo, đồng thời có thể sửa đổi quy trình mở quyền truy cập (sẽ được thảo luận chi tiết trong chương về kiểm tra quyền truy cập).
Tính sẵn sàng cao
Câu hỏi đặt ra là: tôi nên sử dụng HA cho tường lửa hay cài đặt hai hộp độc lập “song song” và nếu một trong số chúng bị lỗi, hãy định tuyến lưu lượng truy cập qua hộp thứ hai?
Có vẻ như câu trả lời là hiển nhiên - hãy sử dụng HA. Lý do tại sao câu hỏi này vẫn được đặt ra là, thật không may, 99 về mặt lý thuyết và quảng cáo cũng như một số phần trăm thập phân về khả năng tiếp cận trong thực tế hóa ra lại không mấy khả quan như vậy. Về mặt logic, HA là một thứ khá phức tạp và trên các thiết bị khác nhau cũng như với các nhà cung cấp khác nhau (không có ngoại lệ), chúng tôi đã phát hiện ra các sự cố, lỗi và dịch vụ bị dừng.
Nếu bạn sử dụng HA, bạn sẽ có cơ hội tắt các nút riêng lẻ, chuyển đổi giữa chúng mà không dừng dịch vụ, điều này rất quan trọng, chẳng hạn như khi thực hiện nâng cấp, nhưng đồng thời bạn có xác suất rất xa là cả hai nút đồng thời sẽ bị hỏng và lần nâng cấp tiếp theo sẽ không diễn ra suôn sẻ như lời hứa của nhà cung cấp (vấn đề này có thể tránh được nếu bạn có cơ hội thử nghiệm bản nâng cấp trên thiết bị trong phòng thí nghiệm).
Nếu bạn không sử dụng HA, thì từ quan điểm thất bại kép, rủi ro của bạn sẽ thấp hơn nhiều (vì bạn có 2 tường lửa độc lập), nhưng vì... các phiên không được đồng bộ hóa thì mỗi lần chuyển đổi giữa các tường lửa này bạn sẽ mất lưu lượng truy cập. Tất nhiên, bạn có thể sử dụng tường lửa không trạng thái, nhưng khi đó mục đích của việc sử dụng tường lửa phần lớn sẽ bị mất đi.
Do đó, nếu qua quá trình kiểm tra, bạn phát hiện ra các tường lửa đơn lẻ và bạn đang nghĩ đến việc tăng độ tin cậy cho mạng của mình, thì HA tất nhiên là một trong những giải pháp được khuyến nghị, nhưng bạn cũng nên tính đến những nhược điểm liên quan. với cách tiếp cận này và có lẽ, đặc biệt đối với mạng của bạn, một giải pháp khác sẽ phù hợp hơn.
Khả năng quản lý
Về nguyên tắc, HA cũng liên quan đến khả năng kiểm soát. Thay vì cấu hình 2 hộp riêng biệt và giải quyết vấn đề giữ cấu hình đồng bộ, bạn quản lý chúng nhiều như thể bạn có một thiết bị.
Nhưng có lẽ bạn có nhiều trung tâm dữ liệu và nhiều tường lửa thì câu hỏi này lại đặt ra ở một cấp độ mới. Và câu hỏi không chỉ là về cấu hình mà còn về
- cấu hình dự phòng
- cập nhật
- nâng cấp
- giám sát
- khai thác gỗ
Và tất cả điều này có thể được giải quyết bằng hệ thống quản lý tập trung.
Vì vậy, ví dụ: nếu bạn đang sử dụng tường lửa Palo Alto thì là một giải pháp như vậy.
Tiếp tục.
Nguồn: www.habr.com