이 기사는 "네트워크 인프라를 제어하는 ​​방법" 기사 시리즈 중 세 번째입니다. 시리즈의 모든 기사 내용과 링크를 확인할 수 있습니다. 여기에.

보안 위험을 완전히 제거한다고 말하는 것은 의미가 없습니다. 원칙적으로 이를 XNUMX으로 줄일 수는 없습니다. 또한 우리는 네트워크를 더욱 안전하게 만들기 위해 노력함에 따라 솔루션 비용도 점점 더 비싸지고 있다는 점을 이해해야 합니다. 네트워크에 적합한 비용, 복잡성 및 보안 간의 절충점을 찾아야 합니다.

물론 보안 설계는 전체 아키텍처에 유기적으로 통합되며, 사용되는 보안 솔루션은 네트워크 인프라의 확장성, 신뢰성, 관리 효율성 등에 영향을 미치며, 이 점도 고려해야 합니다.

하지만 지금 우리는 네트워크 생성에 대해 이야기하고 있지 않다는 점을 상기시켜 드리겠습니다. 우리에 따르면 초기 조건 우리는 이미 설계를 선택하고, 장비를 선택하고, 인프라를 구축했습니다. 이 단계에서는 가능하다면 이전에 선택한 접근 방식의 맥락에서 "살아서" 솔루션을 찾아야 합니다.

이제 우리의 임무는 네트워크 수준에서 보안과 관련된 위험을 식별하고 이를 합리적인 수준으로 줄이는 것입니다.

네트워크 보안 감사

조직에서 ISO 27k 프로세스를 구현한 경우 보안 감사 및 네트워크 변경 사항이 이 접근 방식의 전체 프로세스에 원활하게 들어맞아야 합니다. 그러나 이러한 표준은 여전히 ​​특정 솔루션, 구성, 디자인에 관한 것이 아닙니다. 네트워크가 어떤 모습이어야 하는지를 자세히 지시하는 명확한 조언이나 표준이 없습니다. 이것이 이 작업의 복잡성과 아름다움입니다.

가능한 몇 가지 네트워크 보안 감사를 강조하겠습니다.

• 장비 구성 감사(강화)
• 보안 설계 감사
• 액세스 감사
• 프로세스 감사

장비 구성 감사(강화)

대부분의 경우 이는 네트워크 보안을 감사하고 개선하기 위한 가장 좋은 출발점인 것 같습니다. IMHO, 이것은 파레토의 법칙(20%의 노력은 결과의 80%를 생성하고 나머지 80%의 노력은 결과의 20%만 생성함)을 잘 보여줍니다.

요점은 일반적으로 장비 구성 시 보안에 대한 "모범 사례"와 관련하여 공급업체로부터 권장 사항을 받는다는 것입니다. 이것을 "경화"라고 합니다.

또한 이러한 권장 사항을 바탕으로 설문지를 찾거나 직접 만들 수도 있습니다. 이 설문지는 장비 구성이 이러한 "모범 사례"를 얼마나 잘 준수하는지 확인하고 결과에 따라 네트워크를 변경하는 데 도움이 됩니다. . 이를 통해 사실상 무료로 보안 위험을 아주 쉽게 크게 줄일 수 있습니다.

일부 Cisco 운영 체제에 대한 몇 가지 예입니다.

Cisco IOS 구성 강화
Cisco IOS-XR 구성 강화
Cisco NX-OS 구성 강화
Cisco 기본 보안 체크리스트

이러한 문서를 기반으로 각 장비 유형에 대한 구성 요구 사항 목록을 만들 수 있습니다. 예를 들어 Cisco N7K VDC의 경우 이러한 요구 사항은 다음과 같습니다. 그래서.

이러한 방식으로 네트워크 인프라의 다양한 유형의 활성 장비에 대한 구성 파일을 생성할 수 있습니다. 그런 다음 수동으로 또는 자동화를 사용하여 이러한 구성 파일을 "업로드"할 수 있습니다. 이 프로세스를 자동화하는 방법은 오케스트레이션 및 자동화에 대한 다른 기사 시리즈에서 자세히 논의됩니다.

보안 설계 감사

일반적으로 엔터프라이즈 네트워크에는 다음과 같은 세그먼트가 어떤 형태로든 포함되어 있습니다.

• DC(공공서비스 DMZ 및 인트라넷 데이터센터)
• 인터넷 액세스
• 원격 액세스 VPN
• WAN 에지
• 지사
• 캠퍼스(사무실)
• 핵심

다음에서 가져온 제목 시스코 안전 모델이지만, 물론 이러한 이름과 이 모델에 정확하게 붙일 필요는 없습니다. 그래도 나는 형식에 얽매이지 않고 본질을 이야기하고 싶다.

이러한 각 부문마다 보안 요구 사항, 위험 및 이에 따른 솔루션이 다릅니다.

보안 설계 관점에서 직면할 수 있는 문제에 대해 각각 개별적으로 살펴보겠습니다. 물론, 이 기사가 완전한 척하는 것은 결코 아니며, 진정으로 깊고 다각적인 주제에서 달성하기가 쉽지는 않지만 (불가능하지는 않지만) 내 개인적인 경험을 반영한다는 점을 다시 한 번 반복합니다.

완벽한 해결책은 없습니다(적어도 아직은 아닙니다). 항상 타협입니다. 그러나 하나의 접근법을 사용하기로 한 결정은 그 장단점을 모두 이해하면서 의식적으로 내리는 것이 중요합니다.

데이터 센터

안전 관점에서 가장 중요한 부분입니다.
그리고 늘 그렇듯이 여기에도 보편적인 해결책은 없습니다. 이는 모두 네트워크 요구 사항에 따라 크게 달라집니다.

방화벽이 필요한가요, 아니면 필요하지 않나요?

대답은 분명한 것처럼 보이지만 모든 것이 보이는 것만 큼 명확하지는 않습니다. 그리고 당신의 선택은 뿐만 아니라 영향을 받을 수 있습니다 가격.

예 1. 지연.

예를 들어 교환의 경우와 같이 일부 네트워크 세그먼트 간에 낮은 대기 시간이 필수 요구 사항인 경우 이러한 세그먼트 간에 방화벽을 사용할 수 없습니다. 방화벽의 대기 시간에 대한 연구를 찾기는 어렵지만 1mksec 이하의 대기 시간을 제공할 수 있는 스위치 모델은 거의 없습니다. 따라서 마이크로초가 중요하다면 방화벽은 적합하지 않다고 생각합니다.

예 2. 성능.

상위 L3 스위치의 처리량은 일반적으로 가장 강력한 방화벽의 처리량보다 훨씬 높습니다. 따라서 강도가 높은 트래픽의 경우 이 트래픽이 방화벽을 우회하도록 허용해야 할 가능성이 높습니다.

예 3. 신뢰성.

방화벽, 특히 최신 NGFW(차세대 FW)는 복잡한 장치입니다. L3/L2 스위치보다 훨씬 더 복잡합니다. 그들은 많은 서비스와 구성 옵션을 제공하므로 신뢰성이 훨씬 낮다는 것은 놀라운 일이 아닙니다. 서비스 연속성이 네트워크에 중요한 경우 방화벽을 사용한 보안 또는 일반 ACL을 사용하여 스위치(또는 다양한 종류의 패브릭)에 구축된 네트워크의 단순성 중 가용성을 향상시킬 수 있는 방법을 선택해야 할 수도 있습니다.

위 예의 경우 (평소와 같이) 타협점을 찾아야 할 가능성이 높습니다. 다음 솔루션을 살펴보세요.

• 데이터 센터 내부에서 방화벽을 사용하지 않기로 결정했다면 경계 주변의 액세스를 최대한 제한하는 방법을 고려해야 합니다. 예를 들어 인터넷에서 필요한 포트(클라이언트 트래픽용)만 열 수 있고 점프 호스트에서만 데이터 센터에 대한 관리 액세스를 열 수 있습니다. 점프 호스트에서 필요한 모든 검사(인증/권한 부여, 바이러스 백신, 로깅 등)를 수행합니다.
• PSEFABRIC에 설명된 구성표와 유사하게 데이터 센터 네트워크의 논리적 파티션을 세그먼트로 사용할 수 있습니다. 예 p002. 이 경우 지연에 민감하거나 강도가 높은 트래픽이 하나의 세그먼트(p002, VRF의 경우) "내부"로 이동하고 방화벽을 통과하지 않는 방식으로 라우팅을 구성해야 합니다. 서로 다른 세그먼트 간의 트래픽은 계속해서 방화벽을 통과합니다. 방화벽을 통해 트래픽이 리디렉션되는 것을 방지하기 위해 VRF 간 경로 누출을 사용할 수도 있습니다.
• 투명 모드에서 이러한 요소(대기 시간/성능)가 중요하지 않은 VLAN에 대해서만 방화벽을 사용할 수도 있습니다. 하지만 각 공급업체에 대해 이 모드 사용과 관련된 제한 사항을 주의 깊게 연구해야 합니다.
• 서비스 체인 아키텍처 사용을 고려할 수도 있습니다. 이렇게 하면 필요한 트래픽만 방화벽을 통과할 수 있습니다. 이론상으로는 좋아 보이지만 프로덕션에서는 이 솔루션을 본 적이 없습니다. 우리는 약 5년 전에 Cisco ACI/Juniper SRX/F3 LTM에 대한 서비스 체인을 테스트했지만 당시에는 이 솔루션이 "조잡해" 보였습니다.

보호 수준

이제 트래픽을 필터링하는 데 어떤 도구를 사용할 것인지에 대한 질문에 답해야 합니다. 다음은 NGFW에 일반적으로 존재하는 일부 기능입니다(예: 여기에):

• 상태 저장 방화벽(기본값)
• 애플리케이션 방화벽
• 위협 방지(바이러스 백신, 스파이웨어 방지 및 취약성)
• URL 필터링
• 데이터 필터링(컨텐츠 필터링)
• 파일 차단(파일 형식 차단)
• 도스 보호

그리고 모든 것이 명확하지는 않습니다. 보호 수준이 높을수록 더 나은 것 같습니다. 하지만 그것도 고려해야 해요

• 위의 방화벽 기능을 많이 사용할수록 당연히 비용이 더 많이 듭니다(라이센스, 추가 모듈).
• 일부 알고리즘을 사용하면 방화벽 처리량이 크게 감소하고 지연도 증가할 수 있습니다. 예를 참조하세요. 여기에
• 다른 복잡한 솔루션과 마찬가지로 복잡한 보호 방법을 사용하면 솔루션의 신뢰성이 저하될 수 있습니다. 예를 들어 애플리케이션 방화벽을 사용할 때 상당히 표준적으로 작동하는 일부 애플리케이션(dns, smb)이 차단되는 현상이 발생했습니다.

언제나 그렇듯이 네트워크에 가장 적합한 솔루션을 찾아야 합니다.

어떤 보호 기능이 필요할 수 있는지에 대한 질문에 명확하게 대답하는 것은 불가능합니다. 첫째, 전송하거나 저장하고 보호하려는 데이터에 따라 달라지기 때문입니다. 둘째, 실제로 보안 도구 선택은 공급업체에 대한 믿음과 신뢰의 문제인 경우가 많습니다. 당신은 알고리즘을 모르고, 그것이 얼마나 효과적인지 모르고, 완전히 테스트할 수도 없습니다.

따라서 중요한 부문에서는 다른 회사의 제안을 사용하는 것이 좋은 해결책이 될 수 있습니다. 예를 들어, 방화벽에서 바이러스 백신을 활성화할 수 있지만 호스트에서 로컬로 다른 제조업체의 바이러스 백신 보호를 사용할 수도 있습니다.

분할

우리는 데이터 센터 네트워크의 논리적 분할에 대해 이야기하고 있습니다. 예를 들어 VLAN과 서브넷으로 분할하는 것도 논리적 분할이지만 명확성 때문에 고려하지 않습니다. FW 보안 영역, VRF(및 다양한 공급업체와 관련된 유사 항목), 논리 장치(PA VSYS, Cisco N7K VDC, Cisco ACI 테넌트 등) 등의 엔터티를 고려한 흥미로운 세분화

이러한 논리적 분할과 현재 수요가 있는 데이터 센터 설계의 예는 다음과 같습니다. PSEFABRIC 프로젝트의 p002.

네트워크의 논리적 부분을 정의한 후에는 서로 다른 세그먼트 간에 트래픽이 이동하는 방식, 필터링이 수행될 장치 및 수단을 설명할 수 있습니다.

네트워크에 명확한 논리적 파티션이 없고 다양한 데이터 흐름에 대한 보안 정책을 적용하는 규칙이 공식화되지 않은 경우 이는 특정 액세스를 열 때 이 문제를 해결해야 하며 높은 확률로 매번 다르게 해결해 드립니다.

세분화는 FW 보안 영역에만 기반을 두는 경우가 많습니다. 그런 다음 다음 질문에 답해야 합니다.

• 어떤 보안 영역이 필요합니까?
• 각 영역에 어떤 수준의 보호를 적용하시겠습니까?
• 영역 내 트래픽은 기본적으로 허용됩니까?
• 그렇지 않은 경우 각 영역 내에 어떤 트래픽 필터링 정책이 적용될지
• 각 영역 쌍(소스/대상)에 어떤 트래픽 필터링 정책이 적용될지

TCAM

일반적인 문제는 라우팅과 액세스 모두에 TCAM(Ternary Content Addressable Memory)이 부족하다는 것입니다. IMHO, 이는 장비를 선택할 때 가장 중요한 문제 중 하나이므로 적절한 수준의 주의를 기울여 이 문제를 처리해야 합니다.

예 1. 포워딩 테이블 TCAM.

살펴 보자 팔로알토 7k 방화벽
IPv4 전달 테이블 크기* = 32K임을 확인합니다.
게다가 이 경로 수는 모든 VSYS에 공통입니다.

귀하의 설계에 따라 4개의 VSYS를 사용하기로 결정했다고 가정해 보겠습니다.
이러한 각 VSYS는 BGP를 통해 BB로 사용하는 클라우드의 MPLS PE 4개에 연결됩니다. 따라서 2개의 VSYS는 모든 특정 경로를 서로 교환하고 대략 동일한 경로 집합(그러나 다른 NH)을 포함하는 전달 테이블을 갖습니다. 왜냐하면 각 VSYS에는 2개의 BGP 세션(동일한 설정 포함)이 있고 MPLS를 통해 수신된 각 경로에는 2개의 NH가 있으므로 전달 테이블에 32개의 FIB 항목이 있습니다. 이것이 데이터 센터의 유일한 방화벽이고 모든 경로에 대해 알아야 한다고 가정하면 이는 데이터 센터의 총 경로 수가 4K/(2 * 4) = XNUMXK를 초과할 수 없음을 의미합니다.

이제 동일한 설계를 가진 2개의 데이터 센터가 있고 데이터 센터 간에 "확장된" VLAN(예: vMotion)을 사용하려는 경우 라우팅 문제를 해결하려면 호스트 경로를 사용해야 합니다. . 그러나 이는 2개의 데이터 센터에 대해 가능한 호스트가 4096개를 넘지 않는다는 것을 의미하며 물론 충분하지 않을 수도 있습니다.

예 2. ACL TCAM.

L3 스위치(또는 L3 스위치를 사용하는 다른 솔루션(예: Cisco ACI))에서 트래픽을 필터링하려는 경우 장비를 선택할 때 TCAM ACL에 주의해야 합니다.

Cisco Catalyst 4500의 SVI 인터페이스에 대한 액세스를 제어한다고 가정해 보겠습니다. 그러면 다음에서 볼 수 있듯이 이 기사, 인터페이스에서 나가는(들어오는 것 포함) 트래픽을 제어하려면 4096개의 TCAM 회선만 사용할 수 있습니다. TCAM3을 사용하면 약 4000개의 ACE(ACL 라인)가 제공됩니다.

TCAM이 부족하다는 문제에 직면했다면 무엇보다 먼저 최적화 가능성을 고려해야 합니다. 따라서 Forwarding Table의 크기에 문제가 있는 경우에는 Route Aggregation 가능성을 고려해야 합니다. 액세스에 대한 TCAM 크기에 문제가 있는 경우, 액세스를 감사하고, 오래되고 중복되는 기록을 제거하고, 액세스 열기 절차를 수정할 수도 있습니다(자세한 내용은 액세스 감사 장에서 논의됩니다).

고 가용성

문제는 방화벽에 HA를 사용해야 하는가, 아니면 두 개의 독립적인 상자를 "병렬로" 설치하고 둘 중 하나가 실패할 경우 두 번째 상자를 통해 트래픽을 라우팅해야 하는가입니다.

대답은 분명한 것 같습니다. HA를 사용하십시오. 이 질문이 여전히 발생하는 이유는 불행히도 이론적이고 광고적인 99와 실제로 접근성의 소수점 이하 비율이 그다지 장밋빛이 아닌 것으로 판명되기 때문입니다. HA는 논리적으로 상당히 복잡한 일이며, 서로 다른 장비와 서로 다른 공급업체(예외는 없음)에서 문제와 버그를 발견하고 서비스가 중단되었습니다.

HA를 사용하는 경우 개별 노드를 끄고 서비스를 중지하지 않고 노드 간을 전환할 수 있습니다. 이는 예를 들어 업그레이드할 때 중요하지만 동시에 두 노드가 모두 실패할 확률은 XNUMX이 아닙니다. 동시에 중단되고 다음 업그레이드가 공급업체가 약속한 대로 원활하게 진행되지 않을 수도 있습니다(실험실 장비에서 업그레이드를 테스트할 기회가 있으면 이 문제를 피할 수 있습니다).

HA를 사용하지 않는 경우 이중 실패의 관점에서 볼 때 위험은 훨씬 낮습니다(2개의 독립 방화벽이 있으므로). 세션이 동기화되지 않으면 이러한 방화벽 사이를 전환할 때마다 트래픽이 손실됩니다. 물론 상태 비저장 방화벽을 사용할 수 있지만 그렇게 하면 방화벽 사용의 의미가 크게 상실됩니다.

따라서 감사 결과 외로운 방화벽을 발견하고 네트워크의 안정성을 높이려는 경우 HA는 물론 권장되는 솔루션 중 하나이지만 이와 관련된 단점도 고려해야 합니다. 이 접근 방식을 사용하면 특히 네트워크의 경우 다른 솔루션이 더 적합할 수 있습니다.

관리성

원칙적으로 HA는 제어 가능성에 관한 것이기도 합니다. 2개의 상자를 별도로 구성하고 구성을 동기화 상태로 유지하는 문제를 처리하는 대신 마치 하나의 장치가 있는 것처럼 관리할 수 있습니다.

하지만 데이터 센터와 방화벽이 많을 경우 이 질문은 새로운 차원에서 제기됩니다. 문제는 구성뿐만 아니라

• 백업 구성
• 업데이트
• 업그레이드
• 모니터링
• 벌채 반출

그리고 이 모든 것은 중앙 집중식 관리 시스템으로 해결될 수 있습니다.

예를 들어 Palo Alto 방화벽을 사용하는 경우 파노라마 그런 솔루션입니다.

계속 될거야.

출처 : habr.com