그동안 우리의 네트워크 보안은 매우 정적(Static)이었습니다.
출발지 IP주소와 목적지 IP주소, 그리고 포트로 보안 정책을 만들어 트래픽을 제어하고 보안을 강화했습니다.
하지만, 이제 시대가 바뀌었습니다.
IP 주소도 DHCP 환경으로 변화하고 있고, 사용자의 단말도 개인 단말을 포함하여 IT팀이 통제하기 어려워지고 있습니다.
이러한 환경에서 기존의 보안 방식으로는 네트워크 보안을 완벽하게 이뤄낼 수 없습니다.
최근에 여기저기 크고 작은 많은 보안 사고가 발생하고 있습니다. 보안 침해사고로 금전적 피해와 함께 서비스 중단까지 일어납니다.
그러면서 많이 얘기하는 것이 바로 “제로 트러스트 보안”입니다.
하지만, IP주소 기반의 레거시 보안 방식은 제로 트러스트를 구현하기 매우 어렵습니다.
그래서 HPE Aruba Networking은 예전부터 역할 기반의 보안 정책을 추진해왔습니다.
WLAN 솔루션으로 시작한 회사였던 Aruba Networks 시절부터 역할 기반의 접근제어(RBAC) 및 정책 구성을 제공했습니다.
역할(Role)?
그럼 역할이라는 것이 뭘까요?
단말이 네트워크에 붙을 때 수많은 Attribute(속성)값을 갖게 됩니다.
누가, 언제, 어디서, 어떤 방식으로, 어떤 단말로 등등…
이러한 여러 속성 값을 조합하여 역할을 만들게 됩니다.
업무시간에 회사 자산을 이용해 접속한 외주 직원, 또는 휴일에 원격으로 개인 PC로 접속한 임직원과 같이 말이죠.
아니면, 직원의 R&R을 활용해서 회사의 업무에 맞는 역할(웹개발자, QA테스터, 구매팀 등)을 부여할 수도 있습니다.
그리고 이 역할을 활용해서 여러 정책을 적용할 수 있게 됩니다.
방화벽 정책을 적용할 수도 있을 것이고, 역할별 QoS 정책을 적용할 수도 있을 것입니다.
왜 역할을 사용할까요?
역할 기반의 정책을 적용하면, 보안과 운영적 관점에서 이점을 가질 수 있습니다.
레거시 환경에서 IP주소 기반으로 관리하던 ACL 정책을 생각해보세요.
수많은 IP주소를 일일이 관리하기도 어렵고, 더 이상 사용하지 않는 정책이나 IP주소를 정리하는 것도 놓치기 마련입니다.
또한, 이 ACL 정책을 무슨 목적으로 언제 만들었는지 알 수 없어 계속 방치되는 경우도 있게 됩니다.
이러한 것들이 결국 보안 구멍을 만들어 최소 권한의 원칙에 맞지 않는 인프라 운영을 하게 될 수 있습니다.
access-list 110 permit udp host 10.191.40.56 gt 1023 host 192.168.12.81 eq snmp
access-list 110 permit udp host 10.128.117.156 gt 1023 host 192.168.12.81 eq snmp
access-list 110 permit udp host 10.191.40.56 gt 1023 host 192.168.12.82 eq snmp
access-list 110 permit udp host 10.128.117.156 gt 1023 host 192.168.12.82 eq snmp
access-list 110 deny ip 10.195.138.0 0.56.113.255 host 192.168.12.81
access-list 110 deny ip 10.195.140.0 0.56.112.255 host 192.168.12.81
access-list 110 deny ip 10.194.0.0 0.1.255.255 host 192.168.12.81
access-list 110 deny ip 10.196.0.0 0.3.255.255 host 192.168.12.81
access-list 110 permit ip 10.192.0.0 0.63.255.255 host 192.168.12.81
access-list 110 permit ip 172.16.254.0 0.0.1.255 host 192.168.12.81
access-list 110 deny ip 10.195.138.0 0.56.113.255 host 192.168.12.82
access-list 110 deny ip 10.195.140.0 0.56.112.255 host 192.168.12.82
...
< snipped – can be a very long list of Access Entries >
...
access-list 110 permit tcp 192.168.11.0 0.0.0.255 gt 1023 192.168.111.0 0.0.0.255 eq www
access-list 110 permit tcp 192.168.11.0 0.0.0.255 gt 1023 192.168.111.0 0.0.0.255 eq 443
access-list 110 permit tcp 192.168.52.0 0.0.0.255 gt 1023 192.168.111.0 0.0.0.255 eq www
access-list 110 permit tcp 192.168.52.0 0.0.0.255 gt 1023 192.168.111.0 0.0.0.255 eq 443
access-list 110 permit tcp 192.168.35.0 0.0.0.255 gt 1023 192.168.111.0 0.0.0.255 eq www
access-list 110 permit tcp 192.168.35.0 0.0.0.255 gt 1023 192.168.111.0 0.0.0.255 eq 443
access-list 110 permit tcp host 10.58.136.112 range ftp-data ftp host 192.168.111.202
access-list 110 permit tcp host 10.58.136.112 host 192.168.111.202 established
access-list 110 permit tcp host 10.58.136.112 range ftp-data ftp host 192.168.111.203
access-list 110 permit tcp host 10.58.136.112 host 192.168.111.203 established
access-list 110 permit tcp host 10.128.15.132 host 192.168.111.202
access-list 110 permit tcp host 10.128.15.132 host 192.168.111.203
access-list 110 permit tcp host 10.128.14.19 host 192.168.111.202
access-list 110 permit tcp host 10.128.14.19 host 192.168.111.203
access-list 110 permit tcp host 10.128.56.58 eq 1521 host 192.168.111.202
access-list 110 deny ip any any하지만, 802.1x 인증이나 MAC 인증을 사용하고, IP주소 대신 역할명을 사용하면 정책 관리가 쉬워집니다.
AOS-CX 스위치에는 GBP(Group based Policy)라는 이름과 함께 역할 기반의 정책을 구성할 수 있습니다.
class gbp-ip employee-permit
10 match any admin employee
20 match ip employee employee
30 ignore icmp student employe
40 match icmp any employee
50 match udp contractor employee range 3478 3481
60 match tcp contractor employee range 3478 3481
class gbp-ip employee-deny
10 match any student employee
20 match any printer employee거기에 Appliaction Regonition 기능까지 활용한다면, 위의 UDP 포트에 대한 설정을 Application으로 지정할 수도 있습니다.
50 match udp contractor employee app-category instant-messaging app ms-teams결과적으로 긴 ACL 대신에 간략한 GBP 덕분에, 스위치 자체의 부하도 줄이고 불필요하게 큰 TCAM이 필요하지 않게 됩니다.
Colorless Port
우리는 그 동안 유선 스위치의 각 포트별로 직접 VLAN과 ACL, QoS 설정 등 을 할당해왔습니다.
이러한 설정은 매우 정적(Static)입니다. 따라서 포트에 연결된 단말이 변경될 때마다 매번 설정을 바꿔야 했습니다.
하지만, AOS-CX 스위치는 ClearPass와 같은 정책 관리자가 내려주는 역할에 따라 VLAN과 관련된 정책을 이어 받게 됩니다.
프린터와 CCTV, VoIP 전화기 등 각 역할을 동적(Dynamic)으로 내려 받기 때문에 자동으로 설정이 바뀌게 됩니다.
즉, 포트별로 특정한 정책이 정적으로 할당되지 않았기 때문에 색깔이 없다(Colorless)라고 얘기합니다.
AOS-CX 사용자 역할 종류
ClearPass(CPPM)을 활용하면 사용자 역할을 쉽게 할당할 수 있게 됩니다.
이 때 “Aruba-User-Role” VSA를 활용하여 역할을 할당합니다.
먼저, 인증이 되기 전에 최소한의 연결을 보장합니다.
예를 들면, Captive Portal과 같은 페이지 연결을 위해 DHCP와 DNS를 허용합니다.
이후 인증 프로세스에 따라 해당 인터페이스는 아래 중 하나의 역할을 할당 받게 됩니다.
- Post-auth role: 인증 성공 후 그에 맞는 여러 인가(권한 허가) 정책이 포함된 역할 할당
- reject role: 인증 실패
- critical role: 인증서버(RADIUS)와 연결 실패 한 경우
- critical voice role: 인증서버와 연결이 실패했으면서 VoIP 전화기인 경우
- cached critical role: 인증서버와 연결이 실패했을 때, cache에 저장된 이전 역할을 그대로 다시 할당 (MAC주소 기반)
- fallback-role: 기기 등록 실패했으면서 해당 기기에 할당 가능한 파생 역할이 없는 경우
- UBT-fallback-role: UBT 영역에 접근 불가한 경우. 포트 수준에서 구성 가능
interface 1/1/1
description colorless
no shutdown
no routing
vlan access 1
rate-limit broadcast 60000 kbps
rate-limit multicast 60000 kbps
spanning-tree bpdu-guard
spanning-tree port-type admin-edge
spanning-tree tcn-guard
aaa authentication port-access allow-cdp-bpdu
aaa authentication port-access allow-lldp-auth mac source-mac
aaa authentication port-access allow-lldp-bpdu
aaa authentication port-access client-limit 2
aaa authentication port-access critical-role Critical
aaa authentication port-access critical-voice-role V-Critical
aaa authentication port-access reject-role Reject
aaa authentication port-access preauth-role Preauth
aaa authentication port-access auth-role Auth
aaa authentication port-access radius-override enable
port-access security violation action shutdown
port-access allow-flood-traffic enable
port-access fallback-role Fallback
port-access ubt-fallback-role UBT-Fallback
aaa authentication port-access dot1x authenticator
initial-auth-response-timeout 3
max-eapol-requests 1
max-retries 1
enable
aaa authentication port-access mac-auth
enable
client track ip enable
client track ip update-interval 120
loop-protect
ip flow monitor MON4-1 in
ipv6 flow monitor MON6-1 inGroup Based Policy (GBP): Role-to-Role policy
앞서 얘기했듯이 IP 주소와 서비스 포트로 보안 정책, 접근제어 정책을 관리하는 것은 구시대적 발상입니다.
그래서 IP 주소와 서비스 포트를 묶어서 역할로 지정했습니다.
그리고 이 역할을 토대로 출발지 역할(Source Role)과 목적지 역할(Destination Role)로 정책을 구성할 수 있게 됩니다.
하지만, 같은 스위치 내에서 역할 기반의 정책은 유효할 수 있겠지만, 다른 스위치로 넘어가면 어떨까요?
A 스위치에서 만들어진 역할(Role)이 B 스위치에서도 동일한 역할을 이해할 수 있을까요?
IP 네트워크상 패킷에는 Role에 대한 정보를 담을 수 있는 공간이 없습니다.
그래서 AOS-CX 스위치는 VXLAN 헤더에 Source Role에 대한 매핑 정보를 담아서 전달하도록 합니다.
내가 생성한 역할(Role)에 대한 정보를 GBP Tag를 담아 매핑하도록 합니다.
switch(config)# gbp enable
switch(config)# gbp role Employee 100
switch(config)# gbp role Monitor 200
switch(config)# gbp role IOT 300
. . .이렇게 생성한 GBP Tag를 통해 서로 떨어진 네트워크 환경에서도 동일한 보안 정책을 구성할 수 있게 됩니다.
switch(config)# show gbp role-mapping
GBP status : Enabled
GBP_ROLE GBP_ROLE_ID
------------- ---------------
default 0
infra 2
internet 3
intranet 4
Employee 100
Monitor 200
IOT 101
. . .Local User Role(LUR) vs Downloadable User Role (DUR)
각 역할에 맞는 ACL과 QoS 등 여러 보안 정책을 스위치에 설정할 수 있습니다.
CLI로 위의 예제처럼 매번 역할별 정책을 하나하나 설정한다고 생각해볼까요?
한 두개의 스위치는 관리할 수 있겠지만, 내가 관리할 스위치가 100대, 1000대라면? 제대로 관리하기가 어려울 것입니다.
처음 프로비저닝할 때는 가능하겠지만, 향후 역할 기반의 정책을 추가한다거나 업데이트해야 한다면 놓치는 일이 발생하게 됩니다.
이는 휴먼에러로 장애나 보안 위협으로 이어질 수 있습니다.
그래서 HPE Aruba Networking은 ClearPass를 활용하여 역할과 역할 기반의 정책을 중앙에서 관리하도록 합니다.
CPPM의 Enforcement Profile에서 “Aruba-CPPM-Role”의 속성 값을 구성하면 각 포트로 해당 역할과 정책을 내려줍니다.
DUR은 포트 액세스 정책(PAP)와 애플리케이션 기반 정책(ABP) 모두 지원합니다.
포트 액세스 정책 (PAP)
포트 액세스 정책은 크게 3가지로 나뉘어 있습니다.
- Class
- Policy
- Role
Class는 여러 ACL 정책과 규칙을 구성하기에 앞서 IP주소와 포트를 정의합니다.
정의할 때는 프로토콜(ICMP, IGMP, IP, TCP, UDP 등) → 출발지 IP주소(서브넷) → 목적지 IP주소(서브넷)으로 구성합니다.
class ip dns
10 match udp any any eq dns
class ip dhcp
10 match udp any any eq dhcp-server
class ip internal-subnets
10 match any any 192.168.0.0/255.255.0.0
20 match any any 172.16.0.0/255.240.0.0
30 match any any 10.0.0.0/255.0.0.0
class ip anyanyclass
10 match any any anyPolicy는 위에서 정의한 Class들을 모아서 하나의 정책으로 만든 것입니다.
특정 역할을 할당 받은 포트에 보안 정책을 내리고 싶을 때 구성합니다.
port-access policy outgoingonly
10 class ip dns
20 class ip dhcp
30 class ip internal-subnets action drop
40 class ip anyanyclass마지막으로 Role은 위에서 지정한 보안 정책(Policy)을 내려 받을 역할을 지정합니다.
포트에 해당 역할이 할당되면 지정된 보안 정책과 함께 역할에 맞는 구성들이 설정됩니다.
port-access role outgoingrole
associate policy outgoingonly
vlan access 552애플리케이션 기반 정책(ABP)
이전 포스팅에서 CX 스위치의 기능을 활용해서 애플리케이션을 식별하는 방법을 소개했습니다.
이 식별된 애플리케이션 정보를 갖고 보안 정책이나 QoS 정책을 구성할 수 있습니다.
- L4 (TCP/UDP) 및 L7 트래픽에 대한 제어
- DUR 지원하며, 역할별 정책 구성
- 인입(Ingress) 트래픽에 대한 제어
- Access 계층(또는 VTEP) 대상 정책
- Advanced Feature Pack 필요
ABP의 동작 방식은 아래와 같습니다.
- 최초 7개의 패킷은 허용
- 분류가 완료되면, ABP 정책 시행 (TCAM, Ternary Content Addressable Memory)
- 암시적 거부(Implicit deny): 앞선 규칙에서 명시적으로 허용하지 않은 모든 트래픽을 거부
- 지원되는 동작: permit/drop/mirror/priority/remark
ABP 구성 방법 (LUR)
1. app-recognition 활성화
switch(config)# app-recognition
switch(config-app-recognition)# enable
switch(config-app-recognition)# abp-session-limit-exceed-action log-only2. ABP 클래스 생성
switch(config)# class abp-ip social-v4
switch(config-class-abp-ip)# 10 match any any any app-category any app twitter
switch(config-class-abp-ip)# 20 match any any any app-category any app facebook
switch(config-class-abp-ip)# 30 match any any any app-category any app instagram
switch(config)# class abp-ipv6 social-v6
switch(config-class-abp-ipv6)# 10 match any any any app-category any app twitter
switch(config-class-abp-ipv6)# 20 match any any any app-category any app facebook
switch(config-class-abp-ipv6)# 30 match any any any app-category any app instagram
switch(config)# class abp-ip catchall-v4
switch(config-class-abp-ip)# 10 match any any any app-category any app any
switch(config)# class abp-ipv6 catchall-v6
switch(config-class-abp-ipv6)# 10 match any any any app-category any app any3. ABP 정책 생성
switch(config)# port-access abp nosocial-lur
switch(config-pa-abp)# 10 class abp-ip social-v4 action drop
switch(config-pa-abp)# 20 class abp-ipv6 social-v6 action drop
switch(config-pa-abp)# 30 class abp-ip catchall-v4
switch(config-pa-abp)# 40 class abp-ipv6 catchall-v64. PAP 정책 및 역할 할당
switch(config)# port-access role ABP_LUR
switch(config-pa-role)# app-recognition enable
switch(config-pa-role)# associate abp nosocial-lur
switch(config-pa-role)# exitABP 구성 방법 (DUR)
1. 스위치에 app-recognition 활성화
switch(config)# app-recognition
switch(config-app-recognition)# enable
switch(config-app-recognition)# abp-session-limit-exceed-action log-only2. CPPM에서 Enforcement Profile로 DUR 생성
애플리케이션 기반의 Role-to-Role Policy
AOS-CX 10.14 버전부터는 ABP와 GBP가 한 단계 업그레이드 됩니다.
만약 MS Teams 애플리케이션에 대해서만 허용하고 나머지 App을 차단하고 싶은 경우를 생각해볼까요?
기존 GBP 방식으로 구성하려면 MS Teams 애플리케이션만 별도로 차단하기 어렵다보니 다수의 IP주소와 포트를 열어야 했습니다.
class gbp-ip ms-teams
10 match tcp employee admin eq 443
20 match udp employee admin range 3478 3481
exit하지만, 이럴 경우 관리가 어렵고 보안상 완벽하지 못합니다.
그래서 CX 10.14 부터는 GBP 구성시에 application-recognition을 통해 식별된 App 기반으로 class 설정이 가능합니다.
class gbp-ip ms-teams
10 match any employee admin app-category instant-messaging app ms-teams
exitEmployee라는 역할이 Admin 역할과의 보안 정책을 Teams 애플리케이션만 허용하고자 한다면, 아래와 같이 구성할 수 있습니다.
port-access gbp-policy employee2admin
10 class gbp-ip ms-teams
20 class gbp-ip non-arc
30 class gbp-ip deny-other-apps drop
40 class gbp-ip explicit-allow-for-arc
50 class gbp-mac allow-arp
exit
port-access role admin
associate gbp-policy employee2admin
app-recognition enable
exit애플리케이션 기반의 Role-to-Role(GBP) 정책을 구성하기 위해서 4가지 사항을 기억해야 합니다.
- 허용할 App에 대한 Class 정의:
10 class gbp-ip ms-teams - 인식할 수 없는 애플리케이션(ICMP) 같은 non-app 항목 목록 허용:
20 class gbp-ip non-arc - 그 외 모든 애플리케이션 차단:
30 class gbp-ip deny-other-apps drop - App-ID가 아직 할당되지 않은 트래픽에 대한 App 식별 허용:
40 class gbp-ip explicit-allow-for-arc
DHCP 환경과 다양한 단말이 혼재되고 있는 요즘의 네트워크 환경을 생각했을 때, IP주소 기반의 보안은 완벽하지 못합니다.
이제는 각 단말의 유형과 기타 속성 값에 의해 역할을 부여하고 그 역할별 보안 정책을 내려줘야 합니다.
역할 기반의 보안 정책을 중앙에서 생성하고 관리하여 모든 사이트에 내려줄 수 있게 된다면, 위치에 관계 없이 일관된 정책을 받을 수 있을 것입니다. 분산된 업무 환경, 하이브리드 업무 환경, 복잡한 인프라에 관계 없이 제로 트러스트 환경을 쉽게 구현할 수 있게 됩니다.
